Opened 19 years ago
Closed 19 years ago
#2438 closed defect (fixed)
PSP: Crash on MI3 JAN 2 CVS Build
| Reported by: | SF/sfaok | Owned by: | joostp |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
Using Jan 2nd CVS Build on 1.50FW PSP. Monkey Island 3 (CD) English version with no compression and full speech and music.
Bug near the beginning of the game where you encounter Murray on the plank of wood and fish the skeleton arm and sword from the sea. Game will randomnly lock the PSP up forcing a hard reset. No specific action seems to trigger the bug. You can by- pass the crash if you quickly retrieve the skeleton arm and exit the screen. Though, the game locked up on 3 attempts; first time whilst talking to Murray, second time crashed a couple seconds after loading a save on that particular screen and lastly, whilst fishing the skeleton arm out of the water.
Ticket imported from: #1398195. Ticket imported from: bugs/2438.
Attachments (2)
Change History (13)
comment:1 by , 19 years ago
| Owner: | set to |
|---|---|
| Summary: | Crash on MI3 PSP JAN 2 CVS Build → PSP: Crash on MI3 JAN 2 CVS Build |
comment:2 by , 19 years ago
| Status: | new → pending |
|---|
comment:3 by , 19 years ago
comment:4 by , 19 years ago
| Status: | pending → new |
|---|
comment:5 by , 19 years ago
I can reproduce it here (although not consistently :-/) with the CVS build in question.
Investigating...
comment:6 by , 19 years ago
After some debugging, it seems bug #993803 ( http://sourceforge.net/tracker/index.php?func=detail&aid=993803&group_id=37116&atid=418822 ) isn't completely fixed yet.
It's spot-on what happens here.
comment:7 by , 19 years ago
You mentioned on IRC that threading on the PSP is cooperative. That patch depends on the sound thread being able to finish playing the sound, even though the script is busy-waiting.
The elegant solution would be if we could automagically insert a breakHere() opcode into the loop. Indeed, this is how the loop earlier in the script does it.
I'm attaching a possible, but rather ugly, workaround. It tries to detect if one script is calling soundKludge() an unusual number of times. I don't know if it will work, though. It could cause false positives, and even if it doesn't it may still be too ugly to live...
comment:8 by , 19 years ago
I don't know about the implications of this patch, but it atleast seems to solve the problem for me. Maybe the workaround is a bit safer if it's bound to the room and script number?
comment:9 by , 19 years ago
Here's an alternative workaround that isn't as ugly as the first one. Instead of using a counter to try and detect a hang, it looks for a soundKludge opcode that is immediately followed by a jump. And only in this particular CMI script.
by , 19 years ago
| Attachment: | nicer-workaround.diff added |
|---|
Another possible, and much nicer, workaround
comment:10 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:11 by , 19 years ago
Indeed, eriktorbjorn's analysis was correct. The PSP uses a cooperative threading model, and due to the main thread busy-waiting for the sound to finish (which won't happen since the audio thread isn't given the chance to run) it'll get into this endless loop.
Adding a sceKernelRotateThreadReadyQueue() in IMuseDigital::getSoundStatus() is a dirty PSP-specific workaround which gives the (higher priority) audio thread a chance to run, making the behaviour identical to PC (i.e. a short animation hiccup once in a while, but no hang).
Since this is really an iMuse bug, the generic 'workaround' is preferred, since all platforms benefit from it.
Conclusion:
eriktorbjorn's alternative workaround is in CVS now (thanks!) and fixes the problem for me.
Closing this report.
What is the status of this item?