Opened 15 years ago

Closed 15 years ago

#1763 closed defect (worksforme)

COMI: talking to Bartender about Dead Aunt (German)

Reported by: SF/juggy Owned by: aquadran
Priority: high Component: Engine: SCUMM
Keywords: Cc:
Game: Monkey Island 3

Description

COMI crashes in Act 5 when trying to talk to the
bartender on Blood Island about why you didn't wake up
in his aunt's grave. This occurs in the German version.
Using -d3 as Option it shows the following output when
I try to continue with a previous savegame:
---------------
WARNING: SO_VERB_LINE_SPACING 24: not yet implemented!
[...]
State loaded from 'comi.s09'
WARNING: o8_kernelSetFunctions: clearTextQueue()!
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
/usr/games/scummvm: line 13: 17825 Segmentation Fault
/usr/lib/scummvm/scummvm "$@"
---------------
I am using IA32 linux version 0.61b, standard debian
package. I also tried recompiling it and the CVS
version (2004-09-12), but using the first one the error
persisted, and the latter cannot be used since it
crashes when loading the savegame:
---------------
File font....
[...]
File musdisk1.bun not found
WARNING: BundleMgr::openFile() Can't open bundle file:
musdisk1.bun!
File musdisk2.bun not found
WARNING: BundleMgr::openFile() Can't open bundle file:
musdisk2.bun!
scummvm: scumm/imuse_digi/dimuse.cpp:146: void
Scumm::IMuseDigital::saveOrLoad(Scumm::Serializer*):
Assertion `track->soundHandle' failed.
---------------
It apparently doesn't find files which are located in
the resource folder. I copied/linked them, then it
would resume the savegame. However, when trying to talk
about the topic outlined above, it crashes displaying
the following error:
---------------
State loaded from 'comi.s09'
(61:2023:0x10AEB): Invalid opcode '36' at 10aeb
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
---------------

I hope this helps with this issue - after all I'd like
to continue playing ;-)

Keep up the good work!

Ticket imported from: #1026913. Ticket imported from: bugs/1763.

Attachments (1)

comi.s09 (63.2 KB ) - added by SF/juggy 15 years ago.
Savegame right before talking to the bartender

Download all attachments as: .zip

Change History (25)

comment:1 by SF/juggy, 15 years ago

Priority: normalblocker

comment:2 by aquadran, 15 years ago

please play game and use save/load games with all needed
files first, it's quite possible, that something goes wrong
for some combinations. that "Assertion `track->soundHandle'
failed." error happen for save game which is created with
all files and loaded later without all files.

comment:3 by SF/juggy, 15 years ago

I did play it with all files outlined in the README, which
is proven by the fact that it played fine with version
0.6.1b (that is, until the crash situation, of course). It
was only when I tried the exact same game with the exact
same options using the CVS version when the follow up
situation occurred. This I solved by linking/copying (as I
stated above) all required files, and then the savegame
wouldn't continue using the CVS version.
Btw., trying with the standard 0.6.1b version it now
produces the following message:
----------------------
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
(61:65:0x295): Invalid opcode '37' at 295
----------------------
Now, if you want me to check something out, please tell me
specifically what you want me to do; I don't understand what
I should have done differently.

comment:4 by aquadran, 15 years ago

i don't understand you: "I did play it with all files
outlined in the README,", ok, so why you do that
"linking/copying (as I
stated above) all required files" ?

by SF/juggy, 15 years ago

Attachment: comi.s09 added

Savegame right before talking to the bartender

comment:5 by SF/juggy, 15 years ago

The standard version requires a different path setup than
the CVS version it seems. For example, the Readme states to
copy the resource folder and some other files, enther that
directory and call "scummvm comi". Using the version
*0.6.1b* this works correctly (I *was* able to play the game
until that point where it crashes).
But when I try the CVS version, it suddenly requires all
files to not be in the resource folder as the 0.6.1b version
requires, but to be (flatly) copied and be present in the
same folder where "scummvm comi" is called. Is that clear
enough?
One more time: I did copy all the necessary files. I was
able to play for more than 6 hours and made it very far in
the game. My setup is correct. But the program crashes due
to some segmentation fault, it does not say anything about
missing files etc. And I cannot check if the same problem
occurs with the cvs version since it crashes using the
savegame from the 0.6.1b version.

I attach the savegame to this message, maybe this helps.

comment:6 by SF/juggy, 15 years ago

Ah, sorry, I just saw I made a mistake in my last post:
After lnking/copying the files into a flat folder structure,
it doesn't crash anymore upon loading the savegame, it only
crashes when trying to talking to bartender about the
infamous topic.

My bad, but the rest of the post is correct.

comment:7 by aquadran, 15 years ago

"The standard version requires a different path setup than
the CVS version it seems." that is odd, it should never
happen. hmm. i'm using the same structure as on the CD with
cvs version and it's fine with finding files. anyway i'll
try your savegame.

comment:8 by fingolfin, 15 years ago

I also have the files just like they were on the CD (i.e. with
subdirectories). Strange that it doesn't work for you, juggy. Maybe you
can attach your ScummVM config file for us to have a look at?

Other than that, I can't reproduce anything in this bug report. Using your
savegame, talking to the bartender works just fine, both with 0.6.1b and
latest CVS... and both with the english and the german version of COMI.

comment:9 by fingolfin, 15 years ago

Priority: blockerhigh
Resolution: worksforme
Summary: COMI crashes: talking to Bartender about Dead Aunt (German)COMI: talking to Bartender about Dead Aunt (German)

comment:10 by SF/juggy, 15 years ago

I attached my config file, though I didn't really configure
anything but basically went with the setup as provided by
the debian package.

BTW did you try talking about "I thought I'd be in your
aunt's tomb"? Because every other topic works fine, it only
crashes with this. And the crash is invariably a
segmentation fault, so it might just be that you don't run
into it in your setup. It also differs whether you are
testing on Linux or some other system; for instance, Windows
doesn't do as rigorous a checking as Linux on memory bounds.

comment:11 by SF/juggy, 15 years ago

BTW, I just - for the heck of it - tried to run scummvm
using the electric fence library (which checks for memory
bounds violations), and I couldn't even start COMI because
of this:
----------------
ElectricFence Aborting: Allocating 0 bytes, probably a bug.
Illegal instruction
----------------
This occurs using both the CVS and the 0.6.1b version. Now,
I don't know whether allocating 0 bytes is actually what you
want to do with malloc at some point of time, but in case it
isn't, it might be worthwhile testing scummvm using this
library to find illegal memory accesses (which are the most
common cause for segmentation fault).

Just an idea...

comment:12 by fingolfin, 15 years ago

Yes, I did follow your instructions and accordingly talked to the bartender
about the aunt's tomb etc -- worked fine anyway.
I'll give it a try with libgmalloc later today.

comment:13 by fingolfin, 15 years ago

I run it with libgmalloc (a special memory debugging lib part of Mac OS X
10.3), and found no issues.

A "malloc(0)" would indeed be a bug, but I can't find anything indicating
that this is actually happening. Can you tell us where exactly EF thinks
that is occuring?

comment:14 by fingolfin, 15 years ago

Owner: set to fingolfin
Status: newclosed

comment:15 by SF/juggy, 15 years ago

I finally got the time to run some checks on that 0-size
allocation bug electric fence found. I wrote a simple
wrapper function which checks for allocation sizes <=0 and
prints a message in case this happens. When running COMI
with my previously attached savegame I get (repeatedly) the
following results:
-------------------------
Error: 0 bytes are being allocated in file
scumm/imuse_digi/dimuse_sndmgr.cpp:161 !
Error: 0 bytes are being allocated in file
scumm/imuse_digi/dimuse_sndmgr.cpp:160 !
Error: 0 bytes are being allocated in file
scumm/imuse_digi/dimuse_sndmgr.cpp:161 !
Error: 0 bytes are being allocated in file
scumm/imuse_digi/dimuse_sndmgr.cpp:160 !
Error: 0 bytes are being allocated in file
scumm/imuse_digi/dimuse_sndmgr.cpp:161 !
Error: 0 bytes are being allocated in file
scumm/imuse_digi/dimuse_sndmgr.cpp:160 !
...
-------------------------
This happens even with the most recent (today's) cvs version.
I tried disabling the sound by using the --music-driver=null
switch, but somehow it doesn't work and sound is played anyway.
I also took a look at the file in question and it turns out
there are quite a few instances where "sound->sync[..]" and
"sound->jump[...]" are accessed and values are stored
without checking if their size is greater than zero, so I
believe this is a bug.
If I find the time I'll try to work on it and see if these
accesses are what causes scummvm to crash on my machine. If
you're interested, I can upload the scripts and my code
which was used to find this (possible) culprit.

Reopening the bug, hope that's OK.

Greetings, and keep up the good work! :)

comment:16 by SF/juggy, 15 years ago

Status: closednew

comment:17 by fingolfin, 15 years ago

Owner: changed from fingolfin to aquadran
Resolution: worksforme

comment:18 by fingolfin, 15 years ago

Assigning to aquadran, this is iMuseDigital issue, it appears

Music drivers do not affect the digital iMuse, which is not MIDI based.

Finally, please check if you can reproduce the problems by starting a new
game, too. After all, your save game might be corrupt.

comment:19 by aquadran, 15 years ago

"0 bytes are being allocated" that is not bug.

comment:20 by fingolfin, 15 years ago

That's debatable, aquadran... While indeed the POSIX spec allows 0 as a
param to malloc, the behaviour is platform dependant: either a NULL
pointer may be returned, or a unique pointer to a 0-byte memory block.

In any case, I'd be wary of any code which actually performs 0 byte
allocations. It smells like a problem if such things occur...

comment:21 by aquadran, 15 years ago

"there are quite a few instances where "sound->sync[..]" and
"sound->jump[...]" are accessed and values are stored
without checking if their size is greater than zero, so I
believe this is a bug."
Access to that arrays are checked by assert by comparing to
numJumps for example, or "for" loops.

comment:22 by fingolfin, 15 years ago

In any case, this doesn't look related to the original bug report.
In fact, I still can't reproduce it, not even with the provided save game.

comment:23 by fingolfin, 15 years ago

Resolution: worksforme
Status: newclosed

comment:24 by fingolfin, 15 years ago

Still can't reproduce the problem. Unless you can provide
additional information, we'll just have to close this as "Works
for me" again.

Note: See TracTickets for help on using tickets.