#1632 DIG: SDL parachutes in power room

[Jorge Suárez]

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)

[James Brown]

Logged In: YES
user_id=2715

Debug 9 and GDB backtraces would be nice, yep!

[Jorge Suárez]

Logged In: YES
user_id=961437

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?

[Max Horn]

Logged In: YES
user_id=12935

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...

[Jorge Suárez]

Logged In: YES
user_id=961437

Thank you fingolfin :-)
I'll do it tonight and post results tomorrow, with the
screenshot and the savegame.

[Jorge Suárez]

Logged In: YES
user_id=961437

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?)

[Jorge Suárez]

screenshot

[Jorge Suárez]

[Jorge Suárez]

Logged In: YES
user_id=961437

[James Brown]

Logged In: YES
user_id=2715

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.

[Jorge Suárez]

Logged In: YES
user_id=961437

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...

[Jorge Suárez]

Logged In: YES
user_id=961437

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()

[Jorge Suárez]

Logged In: YES
user_id=961437

It seems to be solved in 20040530, I've been playing for ten
minutes in that room with no crashes.

Thank you :-)