radare have no support for core dumps yet :) Any volunteer? :)
On Tue, 4 Mar 2008 14:35:39 +0100 "Lluís Batlle" <[EMAIL PROTECTED]> wrote: > use core dumps, my friend! > > 2008/3/4, pancake <[EMAIL PROTECTED]>: > > http://ru.gentoo.neysx.org/proj/ru/qa/backtraces.xml > > > > > > Finally there is the series of "Real-Time events". They are named SIGnn > > with nn being a number greater than 31. The pthread implementation > > usually uses them to syncronise the different threads of the program, and > > thus they don't represent error conditions of any sort. It's easy to > > provide > > meaningless backtraces when confusing the Real-Time signals with error > > conditions. To prevent this, you can tell gdb to not stop the program when > > they are received, and instead pass them directly to the program, like in > > the > > following example. > > > > > > > > > > > > > > Code Listing 1.3: Running xine-ui through gdb, ignoring real-time signals. > > > > > > > > $ gdb /usr/bin/xine > > GNU gdb 6.4 > > [...] > > > > (gdb) run > > Starting program: /usr/bin/xine > > [...] > > > > Program received signal SIG33, Real-time event 33. > > [Switching to Thread 1182845264 (LWP 11543)] > > 0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from > > /lib/libpthread.so.0 > > (gdb) handle SIG33 nostop noprint noignore pass > > Signal Stop Print Pass to program Description > > SIG33 No No Yes Real-time event 33 > > (gdb) kill > > Kill the program being debugged? (y or n) y > > (gdb) run > > > > > > > > > > > > > > > > The handle command tells gdb what it should do when the given signal is > > sent to the command; in this case the flags are nostop (don't stop the > > program returning the command to the debugger), noprint (don't bother > > printing the reception of such a signal), noignore (don't ignore the > > signal — > > ignoring signals is dangerous, as it means discarding them without passing > > them > > to the program), pass (pass the signal to the debugged program). > > > > > > > > > > After the eventual Real-Time events are being ignored by gdb, you should > > try to reproduce the crash you want to report. If you can reproduce it > > systematically, it's quite easy. When gdb tells you that the program > > received the SIGSEGV or SIGABRT signal (or whatever else signal might > > represent > > the error condition for the program), you'll have to actually ask for the > > backtrace, possibly saving it somewhere. The basic command to do that is > > bt, which is short for backtrace, which will show you the backtrace of > > the current thread (if the program is single-threaded, there's only one > > thread). > > > > > > --pancake > > _______________________________________________ > > radare mailing list > > [email protected] > > https://lists.nopcode.org/mailman/listinfo/radare > > > _______________________________________________ > radare mailing list > [email protected] > https://lists.nopcode.org/mailman/listinfo/radare _______________________________________________ radare mailing list [email protected] https://lists.nopcode.org/mailman/listinfo/radare
