Am Donnerstag, 22. Februar 2007 schrieb Dennis Schridde: > Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > > Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > > > Am Mittwoch, 21. Februar 2007 schrieb Per Inge Mathisen: > > > > On 2/21/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > > > For those interested in signal handling and backtrace creation, > > > > > this sample might be usefull. > > > > > > > > Dump caused by signal: SIGSEGV, Segmentation fault > > > > > > > > Backtrace: > > > > 0x8048513 > > > > 0x315420 > > > > 0x8048995 > > > > 0x4b8ae4e4 > > > > 0x8048451 > > > > > > > > At lines: > > > > /home/devel/warzone/gdmp.c:27 > > > > ??:0 > > > > /home/devel/warzone/gdmp.c:90 > > > > ??:0 > > > > ??:0 > > > > > > > > Did not seem to work very well here. I compiled with -g -O0. > > > > > > Oh, it does... > > > What you see are not the places where the signal was generated. > > > You see the return addresses. > > > > > > The 1st line is probably allways useless. It shows the location where > > > the backtrace was generated. The 2nd line is probably allways not in > > > the signaled binary, I think it belongs to the signal handler in glibc. > > > The 3rd line is the interesting one, it shows the location after the > > > function where the signal was generated. > > > > > > In this case the signal is generated in except(), so it points to the > > > next instruction after returning from except(). > > > I agree that this might not be too usefull, especially for bigger > > > functions. > > > > > > The only other way would be to compile with -rdynamic and use push the > > > return addresses through backtrace_symbols() before storing them... > > > But that would not give you any significant additional information, you > > > still have only the return addresses. The only gain is that you also > > > get to know the functions of the library instead of just your own > > > binary. This might be a little bit helpful in cases where it crashes > > > not directly in your binary, but eg. in a call to strcpy or similar. > > > I wasn't able to find out how to create "real" backtraces or even how > > > to dump the callstack. It currently seems to me that the glibc doesn't > > > offer such functionality. Maybe GCC does offer something, since the > > > calling convention is probably defined by GCC and not the LibC... > > > > > > --Dennis > > > > Found a doc with a tiny little bit of more information: > > http://www.linuxjournal.com/article/6391 > > More potentialy usefull information: > http://alephnull.com/ > http://savannah.nongnu.org/projects/libunwind If I didn't do anything wrong libunwind doesn't offer anything additional than the GLibC integrated backtrace() (at least nothing of use for us). Additional to that it also crashes after examination of the signal handler function (it works well if not called from the signal handler)...
--Dennis
pgp2NmUkCptbQ.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
