#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)
Change History (9)
comment:1 by , 20 years ago
| Owner: | set to |
|---|
comment:2 by , 20 years ago
comment:5 by , 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.
comment:6 by , 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 , 20 years ago
| Status: | new → closed |
|---|
comment:8 by , 20 years ago
| Resolution: | → fixed |
|---|
please test with latest cvs, i added better fix for sound resource locking but i think it's not 100% good enough