Opened 16 years ago

Closed 15 years ago

Last modified 15 years ago

#1643 closed defect (fixed)

FT: Crash on music change

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


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 15 years ago.
Patch against a June 17 CVS snapshot

Download all attachments as: .zip

Change History (9)

comment:1 by eriktorbjorn, 16 years ago

Owner: set to aquadran

comment:2 by aquadran, 16 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, 16 years ago

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

comment:4 by SF/niobium41, 15 years ago

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

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

Attachment: dimuse-idea.diff added

Patch against a June 17 CVS snapshot

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

Status: newclosed

comment:8 by aquadran, 15 years ago

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