Opened 20 years ago
Closed 20 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 |
| Version: | 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)
Change History (25)
comment:1 by , 20 years ago
| Priority: | normal → blocker |
|---|
comment:2 by , 20 years ago
comment:3 by , 20 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 , 20 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" ?
comment:5 by , 20 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 , 20 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 , 20 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 , 20 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 , 20 years ago
| Priority: | blocker → high |
|---|---|
| Resolution: | → worksforme |
| Summary: | COMI crashes: talking to Bartender about Dead Aunt (German) → COMI: talking to Bartender about Dead Aunt (German) |
comment:10 by , 20 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 , 20 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 , 20 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 , 20 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 , 20 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:15 by , 20 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 , 20 years ago
| Status: | closed → new |
|---|
comment:17 by , 20 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | worksforme |
comment:18 by , 20 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:20 by , 20 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 , 20 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 , 20 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 , 20 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
comment:24 by , 20 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.
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.