Opened 21 years ago
Closed 20 years ago
#1632 closed defect (fixed)
DIG: SDL parachutes in power room
| Reported by: | SF/ys_ | Owned by: | |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | The Dig |
Description
Sometimes, in the power room (the room with the hook and the control panel with buttons to manipulate it) I get a "SDL parachute deployed". I don't know why, and it seems to be randomly: it occured sometimes when:
- i opened the gate containing the crystal - i looked at the control panel - i pressed the button - the hook gets down
In addition, there is sometimes some junk in the sound (a noisy scrath)
Sorry by my creepy English. I promise put a screenshot in that room, a savegame, and perhaps i should also try "-d9".
Spanish version of The Dig Scummvm CVS 20040520 gcc 3.3 Debian GNU/Linux testing/unstable (kernel 2.6.6)
Ticket imported from: #958054. Ticket imported from: bugs/1632.
Attachments (2)
Change History (13)
comment:1 by , 21 years ago
comment:2 by , 21 years ago
Hi. I've made the screenshots, the savegame.... but now i'm not at home and i won't post them until monday. I haven't done yet the -d9, but that isn't the problem. I dunno how to use dbg. I've only used it to know in what function crashes my newbie-academic programs. Could you tell me some commands to do the backtrace?
comment:3 by , 21 years ago
| Priority: | normal → high |
|---|
comment:4 by , 21 years ago
Do this: 1) Enter the directory your copy of scummvm resides in 2) Type gdb scummvm This will load GDB with scummvm; after a moment, you should be greeted by GDB's command prompt 3) Now type this to run scummvm: run You can also do something like this: run monkey2 i.e. pass any params you would normally pass to scummvm via the "run" command 4) Play like always. 5) If ScummVM crashes, you'll be back on the GDB command console (you may have to switch to the terminal window you started ScummVM from). Type this command to get a backtract: bt You should copy the output of that command into a file and attach that to this bug report.
BTW, I wonder if this might be yet another iMuseDigital crash/lockup. We seem to have a lot of those recently... sounds a bit as if that code has some race conditions or some such...
comment:5 by , 21 years ago
Thank you fingolfin :-) I'll do it tonight and post results tomorrow, with the screenshot and the savegame.
comment:6 by , 21 years ago
Here is, the screenshot (i'll post the savegame in a few seconds)
And here, some debug 9 information:
ys:~$ scummvm -d9 > debugscummvm Fatal signal: Segmentation Fault (SDL Parachute Deployed) ys:~$ tail debugscummvm getResourceAddress(Costume,86) == 0x4182200c getResourceAddress(Costume,87) == 0x4186500c getResourceAddress(String,63) == 0x8489f64 getResourceAddress(String,63) == 0x8489f64 getResourceAddress(Buffer,9) == 0x844e414 getResourceAddress(Costume,87) == 0x4186500c getResourceAddress(Costume,80) == 0x84bf6f4 getResourceAddress(Buffer,9) == 0x844e414 getResourceAddress(Costume,80) == 0x84bf6f4 Locking mutex IMuseDigital::refreshScripts() ys:~$ scummvm -d9 > debugscummvm2 Fatal signal: Segmentation Fault (SDL Parachute Deployed) ys:~$ tail debugscummvm2 getResourceAddress(Costume,86) == 0x4188000c getResourceAddress(Costume,87) == 0x41a0000c getResourceAddress(String,63) == 0x8473ac4 getResourceAddress(String,63) == 0x8473ac4 getResourceAddress(Buffer,9) == 0x8568704 getResourceAddress(Costume,87) == 0x41a0000c getResourceAddress(Costume,80) == 0x8402b6c getResourceAddress(Buffer,9) == 0x8568704 getResourceAddress(Costume,80) == 0x8402b6c Locking mutex IMuseDigital::refreshScripts() ys:~$
The first one occured when the hook goes down by the "roof", just before the screen changes. The second one occured when the screen was already changed (only two seconds later or so). It looks like an IMuseDigital problem, yep... remember that I've got this bug too when removing the "loose board" containing the blue crystal. But I can't reproduce it now :\ I've got it only once.
And here is, gdb in action. Thanks by helping me, fingolfin. This one occured when the hook take the lens and go up with it (just before the screen changes too, as the others excepting the removing loose board one).
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087687600 (LWP 1963)] 0x403a33fa in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x403a33fa in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x0806e39d in ?? () #2 0x0806b307 in ?? () #3 0x0806a685 in ?? () #4 0x081bf421 in putchar () #5 0x081bf35f in putchar () #6 0x401e1b2f in SDL_RemoveTimer () from /usr/lib/libSDL-1.2.so.0 #7 0x401e18ae in SDL_ThreadedTimerCheck () from /usr/lib/libSDL-1.2.so.0 #8 0x401e1dba in SDL_Delay () from /usr/lib/libSDL-1.2.so.0 #9 0x4000bbe0 in _dl_map_object_deps () from /lib/ld-linux.so.2 #10 0x401e0b9b in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0 Previous frame inner to this frame (corrupt stack?)
by , 21 years ago
comment:7 by , 21 years ago
Right in the middle of a mutex lock? Hm, so it IS either a race or debug output just isn't being flushed to a file before segfault (likely)
I really recommend NOT redirecting output to a file. If you do that and the program crashes, there is a high chance that the file will be missing the debug output related to the crash.
comment:8 by , 21 years ago
Oh, sorry, but -d9 gives me about 2MB of debugging, and I can die before that ends showing in the console, so i thought redirecting it to a file would be a good idea. I'll be patient so...
comment:9 by , 20 years ago
Hi again. I've tried again with 20040526 and after loading the savegame in that room, I can't play anymore. If I press the button in the control pannel, it crashes. If I walk to the right, it crashes. If I walk to the north, it crashes. I feel sorry :-( Here is a -d9 output to the console. It seems to be the same as in the output to the file. Well... at least the last line it's the same.
(...)
Script 50, offset 0x2bb: [6C] o6_breakHere()
getResourceAddress(Room,27) == 0x4176a00c
Script 2003, offset 0x28032: [73] o6_jump()
Script 2003, offset 0x28029: [1] o6_pushWord()
Script 2003, offset 0x2802c: [8D] o6_getObjectX()
Script 2003, offset 0x2802d: [1] o6_pushWord()
Script 2003, offset 0x28030: [7A] o6_setCameraAt()
Script 2003, offset 0x28031: [6C] o6_breakHere()
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Matrix,2) == 0x8362cec
getResourceAddress(Matrix,2) == 0x8362cec
getResourceAddress(Costume,14) == 0x4179500c
getResourceAddress(Matrix,2) == 0x8362cec
getResourceAddress(String,63) == 0x847921c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Costume,14) == 0x4179500c
getResourceAddress(Costume,13) == 0x8363824
getResourceAddress(Matrix,2) == 0x8362cec
getResourceAddress(String,63) == 0x847921c
getResourceAddress(Buffer,9) == 0x82c842c
getResourceAddress(Costume,13) == 0x8363824
getResourceAddress(Charset,3) == 0x82e169c
getResourceAddress(Charset,3) == 0x82e169c
getResourceAddress(Buffer,9) == 0x82c842c
Locking mutex IMuseDigital::refreshScripts()
comment:10 by , 20 years ago
It seems to be solved in 20040530, I've been playing for ten minutes in that room with no crashes.
Thank you :-)
comment:11 by , 20 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Debug 9 and GDB backtraces would be nice, yep!