|
From: Patrick O. <pat...@in...> - 2006-03-07 13:32:12
|
On Tue, 2006-03-07 at 12:42 +0000, Tom Hughes wrote: > In message <114...@po...> > Patrick Ohly <pat...@in...> wrote: > > > On Tue, 2006-03-07 at 11:17 +0000, Tom Hughes wrote: > > > >> Some of them are virtually impossible to suppress as I recall > >> as the write appears to come directly from the user program with > >> no sign of libpthread at all... > > > > That's exactly the problem here: why is the stack backtrace > > incomplete and doesn't list the write() as coming from > > inside libpthread? When I use --db-attach on such a write > > gdb correctly tells me that, but valgrind skips one > > level in the callstack. > > I was assuming it was a tail call from libpthread to write that > caused the stack frame to disappear. In gdb, I see: #0 0x04148034 in __libc_write () from /lib/i686/libc.so.6 #1 0x040469b8 in __DTOR_END__ () from /lib/i686/libpthread.so.0 #2 0x0403f37d in __pthread_create_2_1 (thread=0xbefe9e30, attr=0x0, start_routine=0x8048520 <threadhandler>, arg=0x0) at pthread.c:673 According to /proc/*/maps #2 is also in libpthread.so. The 0x0403f37d is after a normal call instruction, not a jmp: 0x0403f36f <__pthread_create_2_1+127>: mov 0x1f4(%ebx),%eax 0x0403f375 <__pthread_create_2_1+133>: mov (%eax),%ecx 0x0403f377 <__pthread_create_2_1+135>: push %ecx 0x0403f378 <__pthread_create_2_1+136>: call 0x403aa1c 0x0403f37d <__pthread_create_2_1+141>: add $0x10,%esp 0x0403f380 <__pthread_create_2_1+144>: inc %eax 0x0403f381 <__pthread_create_2_1+145>: je 0x403f3b0 <__pthread_create_2_1+192> ... I'm not sure about this _DTOR_END__ and how the program ended up there. 0x403aa1c contains: 0x0403aa1c: jmp *0x18(%ebx) gdb shows that it is feasible to detect the __pthread_create_2_1 call in the stack backtrace; whether it is possible with reasonable effort in valgrind is of course a different story. > Do you have DWARF debugging available for glibc and libpthread? or > have them built with frame pointers? These are the standard libraries as included in RH AS2.1 and I am not sure how exactly those are built, but the gcc 2.96 in that release does not use DWARF by default. I suppose readelf should be able to tell me what is really contained in /lib/i686/libpthread-0.9.so but I need some guidance what to watch out for - I have never dealt with debug information at that level. Regarding frame pointers, __pthread_create_2_1 starts with the usual code for frame pointers: #2 0x0403f37d in __pthread_create_2_1 (thread=0xbefe9e30, attr=0x0, start_routine=0x8048520 <threadhandler>, arg=0x0) at pthread.c:673 Line number 673 out of range; pthread.c has 15 lines. (gdb) disass Dump of assembler code for function __pthread_create_2_1: 0x0403f2f0 <__pthread_create_2_1+0>: push %ebp 0x0403f2f1 <__pthread_create_2_1+1>: mov %esp,%ebp 0x0403f2f3 <__pthread_create_2_1+3>: push %esi 0x0403f2f4 <__pthread_create_2_1+4>: push %ebx 0x0403f2f5 <__pthread_create_2_1+5>: sub $0xa0,%esp ... libc however apparently is not compiled with frame pointers, unless I misinterpret something here: (gdb) disass __libc_write Dump of assembler code for function __libc_write: 0x04148020 <__libc_write+0>: push %ebx 0x04148021 <__libc_write+1>: mov 0x10(%esp,1),%edx 0x04148025 <__libc_write+5>: mov 0xc(%esp,1),%ecx 0x04148029 <__libc_write+9>: mov 0x8(%esp,1),%ebx 0x0414802d <__libc_write+13>: mov $0x4,%eax 0x04148032 <__libc_write+18>: int $0x80 0x04148034 <__libc_write+20>: pop %ebx ... BTW, if I run the simple test program (one with pthread_create/join in main) directly in gdb with a break point in __libc_write, I never get such an unusual stack backtrace. Could that be an artifact of the valgrind engine? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |