[Chicken-hackers] howto interpret gdb's stacktrace

[Jörg F . Wittenberger]

Hi Chickenhackers,

I'm looking into another segfault, which is triggered within
the garbage collection.

I did a make DEBUGBUILD=1 and have this backtrace:


Program terminated with signal 11, Segmentation fault. #0 0xb6de4730 in 
really_mark (x=0x9d0304) at runtime.c:3074 3074 h = p->header; (gdb) bt #0 
0xb6de4730 in really_mark (x=0x9d0304) at runtime.c:3074 #1 0xb6de2bc0 in 
C_reclaim (trampoline=0xb68c8134, proc=0xb691429c) at runtime.c:2721 #2 
0xb6de27ec in C_save_and_reclaim (trampoline=0xbe8041d0, proc=0xbe8041c4, 
n=-1098890712)
   at runtime.c:2643 #3 0xb69141e8 in f_6537 (c=6, t0=-1283594908, 
t1=-1098890712, t2=7, t3=1, t4=33) at library.c:18824 #4 0xb68e88b4 in 
f_6311 (c=2, t0=-1098890624, t1=30) at library.c:12899 #5 0xb68e8ccc in 
f_6307 (c=5, t0=-1283677196, t1=-1098890552, t2=-1281794848, t3=7, 
t4=-1281794960)
   at library.c:12949 #6 0x00116c9c in f_9910 (c=<value optimized out>, 
t0=-1281794880, t1=<value optimized out>, t2=-1281794960)
   at clformat.c:5199
...

#2 is either suspicious or an artifact.

How much can I trust this trace to show the parameters as they
where at call time?  Could they have been modified by the gc
between the actual call and the time the coredump is written?

If the parameter "n" was actually that negative value I'd expect
mildly trouble, since C_save_and_reclaim takes it as va_args count.

Should I doubt the trace?

thanks

/Jörg
........