Understanding the segmentation fault output generated using gdb

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

One of perl programs is failing with segementation fault.Since it was not reproducible , i investigated the core file. The output of the core file is as follows

#0  0xfedd49f2 in t_splay () from /lib/libc.so.1
(gdb) backtrace
#0  0xfedd49f2 in t_splay () from /lib/libc.so.1
#1  0xfedd48d0 in t_delete () from /lib/libc.so.1
#2  0xfedd4629 in realfree () from /lib/libc.so.1
#3  0xfedd4c13 in cleanfree () from /lib/libc.so.1
#4  0xfedd412f in _malloc_unlocked () from /lib/libc.so.1
#5  0xfedd4058 in malloc () from /lib/libc.so.1
#6  0x080bf003 in Perl_safesysmalloc ()
#7  0x080dbe4c in Perl_pp_entersub ()
#8  0x00000005 in ?? ()
[download]

Could some one tell me how to increase the frame depth of backtrace command or could send me a link for more info for gdb. My OS Distribution is Solaris 10 8/07 s10x_u4wos_12b X86 Thanks

Comment on Understanding the segmentation fault output generated using gdb Download Code

Replies are listed 'Best First'.
Re: Understanding the segmentation fault output generated using gdb by Utilitarian (Vicar) on Aug 18, 2009 at 07:45 UTC
The first question is what version of Perl are you using? If you didn't build it yourself then you have found a bug `(gdb) backtrace full (gdb) info registers (gdb) thread apply all backtrace` [download] This will give you the values of all the variables at the time of the crash. Update: You should ideally run gdb on the same machine that the core was generated on, in frame 8 you have a library call which is not available on the machine the backtrace was generated on.	[reply] [d/l]
Re^2: Understanding the segmentation fault output generated using gdb by Anonymous Monk on Aug 18, 2009 at 12:52 UTC
I am using perl 5.8.6 , but it has been build :(. Any other tutorials for gdb to get more information out of the core file	[reply]
Re: Understanding the segmentation fault output generated using gdb by cdarke (Prior) on Aug 18, 2009 at 11:15 UTC
What you will not get is the line of your perl script which it is failing on. That address in Perl_pp_entersub is the nearest you are going to get - address 0x00000005 is clearly invalid and looks like the stack has been overwritten. Suspect will be any XS or third-party modules you might be using.	[reply]
Re^2: Understanding the segmentation fault output generated using gdb by Anonymous Monk on Aug 18, 2009 at 13:02 UTC
Could you tell me why the address is invalid. Regarding third party modules i had similar failure earlier but at that time it was failing in Sybase module during destruction of object. This is the previous backtrace. gdb) backtrace #0 0xfeae7253 in syb_st_destroy () from /usr/local/lib/perl5/site_per +l/5.8.6/i86pc-solaris/auto/DBD/Sybase/Sybase.so #1 0x08183c80 in ?? () #2 0x08365b8c in ?? () #3 0x1d7d7640 in ?? () #4 0xfeaff840 in ?? () from /usr/local/lib/perl5/site_perl/5.8.6/i86p +c-solaris/auto/DBD/Sybase/Sybase.so #5 0xfead99ab in XS_DBD__Sybase__st_DESTROY () from /usr/local/lib/pe +rl5/site_perl/5.8.6/i86pc-solaris/auto/DBD/Sybase/Sybase.so #6 0x08183c8c in ?? () #7 0x00000004 in ?? () #8 0xfec40b5c in ?? () from /usr/local/lib/perl5/site_perl/5.8.6/i86p +c-solaris/auto/DBI/DBI.so #9 0x08183c80 in ?? () #10 0x08183cc0 in ?? () #11 0x00000000 in ?? () (gdb) [download] Are there any more information i can extract from the core enabling more debugging.	[reply] [d/l]
Re^3: Understanding the segmentation fault output generated using gdb by cdarke (Prior) on Aug 21, 2009 at 16:35 UTC
Could you tell me why the address is invalid. Aye, there's the rub. Usually a duff pointer, all you have to do is find which one (that's a joke, by the way). Thing is that all you are seeing is the result of a memory location being overwritten, not the cause. A needle in a haystack is simple to these kinds of issues. Just because it was failing in the Sybase module does not mean that that module caused the fault - just that it happened to be the area of memory stomped on. You will not stand much chance using gdb unless you recompile perl and any XS modules with debug switched on (unless you are really good at assembler), and that is not for the faint hearted. Realistically you must try to reproduce the fault and then remove code until it stops happening. Personally I have known bugs like this to have a life of five or six years and never get resolved. Part of the joys of C. By the way, are you using a reasonably up-to-date version of Perl and associated modules? It might be worth considering an upgrade if you are not.	[reply]
Re: Understanding the segmentation fault output generated using gdb by Anonymous Monk on Aug 18, 2009 at 07:00 UTC
Also could you help me in understanding the gdb output	[reply]