Opened 20 years ago

Closed 20 years ago

Last modified 20 years ago

#1643 closed defect (fixed)

FT: Crash on music change

Reported by: eriktorbjorn Owned by: aquadran
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Full Throttle

Description

Full Throttle, English version Latest ScummVM CVS snapshot

This may be a duplicate of bug #957640 ("FT: Frequent crashing"), but if so the problem has gotten a lot worse in the past few days. (Possibly since the recent changes to reduce the mutex usage.)

It seems like anything I do that forces the music to change from one track to another, also causes ScummVM to crash. The very first example of this is when getting the keys from the bartender.

Since it happens so early, I'm not attaching a savegame. I cut-and-pasted a gdb backtrace in a comment to bug #957640 earlier.

Ticket imported from: #962666. Ticket imported from: bugs/1643.

Attachments (1)

dimuse-idea.diff (3.1 KB ) - added by eriktorbjorn 20 years ago.
Patch against a June 17 CVS snapshot

Download all attachments as: .zip

Change History (9)

comment:1 by eriktorbjorn, 20 years ago

Owner: set to aquadran

comment:2 by aquadran, 20 years ago

please test with latest cvs, i added better fix for sound resource locking but i think it's not 100% good enough

comment:3 by eriktorbjorn, 20 years ago

It still crashes for me when I try to get the keys from the bartender.

comment:4 by SF/niobium41, 20 years ago

Still happening as of June 12, 2004 CVS release..

comment:5 by eriktorbjorn, 20 years ago

I think I see what's happening, but I'm not sure how to fix it.

When the music changes, the bar music (id 622) is briefly being used by two sound handles: the original, and a "cloned" fade-out track.

When the original is closed, its resource is unlocked. Since the resource is no longer locked, and it's not considered to be in use, the SCUMM resource system expires it. The fade-out track continues to play, but now it's tring to read data from an invalid pointer. (Apparently it's this reading, not the writing, that triggers the crash.)

I guess that either ScummEngine::isResourceInUse() needs to be more clever about Digital iMUSE, or ImuseDigiSndMgr::closeSound() needs to be more clever about when the unlock resources, or the whole "clone to fade-out track" bit needs to be reconsidered. Couldn't it simply fade out the original track instead?

Changing closeSound() to not unlock the resource if it's used by another sound handle is certainly a simple workaround, and it does fix this particular bug... but I don't know if it's the right solution.

by eriktorbjorn, 20 years ago

Attachment: dimuse-idea.diff added

Patch against a June 17 CVS snapshot

comment:6 by eriktorbjorn, 20 years ago

I've attached a patch here, not because I necessarily think it's the correct one, but demonstrate the alternative way of locking resources that I tried to explain yesterday.

The idea is that instead of locking/unlocking the resource, just make sure that isResourceInUse() knows that the resource is being used by Digital iMUSE. As far as expireResources() is concerned, there is no difference between a locked resource and one that's in use -- they're both off-limits.

I don't know if my IMuseDigital::isSoundInUse() function really needs to be guarded by a mutex or not. Actually, I don't know if it works at all. Since I'm having trouble getting past the first biker fight, I don't really have much to test with.

But it does fix this particular crash.

comment:7 by aquadran, 20 years ago

Status: newclosed

comment:8 by aquadran, 20 years ago

Resolution: fixed
Note: See TracTickets for help on using tickets.