This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [ask for help] threaded app crashes with pretty null backtrace.
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Paweł Sikora <pluto at agmk dot net>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 22 Mar 2012 11:27:29 -0400
- Subject: Re: [ask for help] threaded app crashes with pretty null backtrace.
- References: <1553090.Vayg0KOcjV@localhost>
2012/3/22 PaweÅ Sikora <pluto@agmk.net>:
> i'd like to ask glibc's hackers if the glibc has some internal machinery
> to debug threads or guard stacks? i have a buggy application which crashes
> in ugly way. gdb and valgrind didn't help Â:(
Start by strace-ing the application e.g. strace -ttt -ff -o
tracelog.txt <application>.
Start by looking at the system calls made by the application and note
where the thread dies.
Then you might try latrace (http://people.redhat.com/jolsa/latrace/index.shtml).
Start by looking at the library calls made by the application and note
where the thread dies.
Then work backwards and set breakpoints everywhere you think there
might be problems.
Start inspecting input arguments and program behaviour.
You can always script gdb by passing `-x <script file>' with
pre-canned gdb commands.
I once had script file with a million `step instruction' commands to
watch the behaviour of the dynamic linker at the instruction level.
Cheers,
Carlos.