Re: [Chicken-hackers] howto interpret gdb's stacktrace

[Felix]

From: Jörg F. Wittenberger <address@hidden>
Subject: [Chicken-hackers] howto interpret gdb's stacktrace
Date: 27 May 2012 23:37:02 +0200

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

Was this code compiled with C optimization options? If yes, any
assumption about the correctness of the trace is moot.


cheers,
felix