This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ask for help] threaded app crashes with pretty null backtrace.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]