gdb question
in [Unix Programming]
|
From: Ersek, Laszlo on 19 Mar 2010 16:33 In article <87df764a-bcbe-4493-8ef1-dd43c51f5b77(a)g28g2000prb.googlegroups.com>, cerr <ron.eggler(a)gmail.com> writes: > On Mar 18, 11:44=A0am, Ben Bacarisse <ben.use...(a)bsb.me.uk> wrote: >> Step through the program skipping over everything but the top-level >> functions to find where the fault it. Keep going deeper as you get >> closer to fault. > Uhm, that's difficult as there's various threads. Finally; I was waiting for this. So you're on Linux, and gdb is unable to show you any usable stack frame in a multi-threaded debuggee. Please paste the output of "ldd binary". I may be completely off, but I had the exact same phenomenon with lbzip2 earlier. It didn't even crash, IIRC I just wanted to take a look at it. Although I couldn't find anything definitive on the web, from the bits scattered all accross I had the impression that "vdso" and "multi-threaded" and "gdb" don't play together. So for debugging, I relinked lbzip2 statically. I think there were other (better) workarounds. Static linking broke getpid(), for example, it started to return different PID's in different threads, and perhaps something else too. But the stack trace was fixed, so it worked temporarily. Some links that may or may not be relevant -- I guess especially the last one may pertain to you: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401482 https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/74691 https://bugzilla.novell.com/show_bug.cgi?id=258433 ----v---- yzzx xyzzx 2007-03-28 19:23:28 UTC This is a kernel bug. The compat vDSO mapped to ffffe000, but that is not readable via ptrace. ----^---- HTH, lacos
From: Ben Bacarisse on 19 Mar 2010 20:29
cerr <ron.eggler(a)gmail.com> writes: > On Mar 18, 11:44 am, Ben Bacarisse <ben.use...(a)bsb.me.uk> wrote: <snip> >> It's possible that gdb can't give you a stack trace because the stack >> has been messed up. > How would that happen? Any number of ways. The common feature would be writing to stack locations that are not objects in your program. >> Step through the program skipping over everything but the top-level >> functions to find where the fault it. Keep going deeper as you get >> closer to fault. > Uhm, that's difficult as there's various threads. Ah! Do all the threads 'bt' results look like the same? "thread apply all bt" will show them all. I'd expect only the thread that caused the damage to have a messed up stack but that is only a rule of thumb. If they all look like that, maybe you have hit the kernel issue mentioned in another post. >> Have you tried other tools like valgrind? > Nope I unfortunately can't get valgring compiled for my target > platform... :( What target? -- Ben. |