Mailinglist Archive: opensuse-programming (52 mails)

[Jerry Feldman <gaf@xxxxxxx>]

On Monday 24 April 2006 3:59 pm, Per Jessen wrote:

> Yep, got it.
>
> Does anyone have suggestions as to how to trap a stack corruption?  I'm
> almost certainly asking a naive question - I'm not quite familiar with
> debugging C on Intel (my normal hunting grounds are assembler on S390).
>
> I'm thinking of maintaining a couple flags/checksum(ish) variable at
> each start/end of a stack, and then checking those at entry/exit?  Does
> anything exist that will assist me doing this? (this method was been
> very successful in catching corruptions in both CICS and TPF).
>
> The error I'm chasing seems highly intermittent - I can process 100.000s
> of emails (sample of 1014 emails repeated in multiple threads) over 24+
> hours with no problem, but also trigger it within 30mins of starting a
> test.
For one, make sure that a core file is produced. Then run GDB on the core 
file. That will point you at the segfault, then try to do a backtrace (the 
bt command) from there. Stack corruptions do tend to be messy because you 
lose context. 


Additionally, one of the most common causes of stack corruption is not so 
much malloc-free issues, but indexing beyond the bounds of an array. Lot's 
of strange things can happen when the stack is corrupted. Note that CICS 
and TPS are ancient and have some very good debuggers. 

Additionally, Intel has its own compilers and debuggers that you can use 
freely for non-commercial use. Their ICC debugger is much more in the line 
of the old Unix dbx (actually it is DEC's ladebug). I've found that in 
trying to debug C++ inline functions, Intel's IDB is better than gdb. 


-- 
Jerry Feldman <gaf@xxxxxxx>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9