Opened 15 years ago

Closed 15 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
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)

soundkludge-kludge.diff (1.9 KB ) - added by eriktorbjorn 15 years ago.
Possible (but ugly) workaround
nicer-workaround.diff (1.1 KB ) - added by eriktorbjorn 15 years ago.
Another possible, and much nicer, workaround

Download all attachments as: .zip

Change History (13)

comment:1 by joostp, 15 years ago

Owner: set to joostp
Summary: Crash on MI3 PSP JAN 2 CVS BuildPSP: Crash on MI3 JAN 2 CVS Build

comment:2 by fingolfin, 15 years ago

Status: newpending

comment:3 by fingolfin, 15 years ago

What is the status of this item?

comment:4 by joostp, 15 years ago

Status: pendingnew

comment:5 by joostp, 15 years ago

I can reproduce it here (although not consistently :-/) with the CVS build in question.

Investigating...

comment:6 by joostp, 15 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 eriktorbjorn, 15 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...

by eriktorbjorn, 15 years ago

Attachment: soundkludge-kludge.diff added

Possible (but ugly) workaround

comment:8 by joostp, 15 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 eriktorbjorn, 15 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 eriktorbjorn, 15 years ago

Attachment: nicer-workaround.diff added

Another possible, and much nicer, workaround

comment:10 by joostp, 15 years ago

Resolution: fixed
Status: newclosed

comment:11 by joostp, 15 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.

Note: See TracTickets for help on using tickets.