|
From: Julian S. <js...@ac...> - 2006-03-07 02:03:09
|
I'd like to release 3.1.1 some time around Friday, if possible. Many bug fixes have been merged in now and I'm hoping to be in a code freeze state soon. A good summary of the bugs that have been fixed are in trunk/docs/internals/3_1_BUGSTATUS.txt. If you're a packager, or you want to check that 3.1.1 fixes your showstopping bug in 3.1.0, now would be a good time to check out the 3.1.X line and test it: svn co svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_1_BRANCH \ branch31 cd branch31 ./autogen.sh # then configure and build as usual Let me know of any critical breakage ASAP. J |
|
From: Patrick O. <pat...@in...> - 2006-03-07 11:09:57
|
On Tue, 2006-03-07 at 02:02 +0000, Julian Seward wrote: > I'd like to release 3.1.1 some time around Friday, if possible. > Many bug fixes have been merged in now and I'm hoping to be in a > code freeze state soon. A good summary of the bugs that have > been fixed are in trunk/docs/internals/3_1_BUGSTATUS.txt. I still think the handling of suid binaries called from inside programs running under valgrind control should be investigated further (#119404, listed as "possibly just close") and the failing suppression of uninitialized memory reads inside Linux pthreads has also irritated a few people on this list (#119446, not listed). Both problems still occur with current SVN head. -- 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. |
|
From: Tom H. <to...@co...> - 2006-03-07 11:17:53
|
In message <114...@po...>
Patrick Ohly <pat...@in...> wrote:
> I still think the handling of suid binaries called from inside
> programs running under valgrind control should be investigated
> further (#119404, listed as "possibly just close") and the
> failing suppression of uninitialized memory reads inside Linux
> pthreads has also irritated a few people on this list (#119446,
> not listed).
Keeping with all the different builds of glibc that people use
and which all seem to manage to give different backtraces is a
major pain as far as the linuxthreads issue goes.
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...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Patrick O. <pat...@in...> - 2006-03-07 12:33:38
|
On Tue, 2006-03-07 at 11:17 +0000, Tom Hughes wrote: > In message <114...@po...> > Patrick Ohly <pat...@in...> wrote: > > > I still think the handling of suid binaries called from inside > > programs running under valgrind control should be investigated > > further (#119404, listed as "possibly just close") and the > > failing suppression of uninitialized memory reads inside Linux > > pthreads has also irritated a few people on this list (#119446, > > not listed). > > Keeping with all the different builds of glibc that people use > and which all seem to manage to give different backtraces is a > major pain as far as the linuxthreads issue goes. There are suppressions which used to work fine. > 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. -- 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. |
|
From: Tom H. <to...@co...> - 2006-03-07 12:42:49
|
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.
Do you have DWARF debugging available for glibc and libpthread? or
have them built with frame pointers?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
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. |
|
From: Tom H. <to...@co...> - 2006-03-07 14:28:28
|
In message <114...@po...>
Patrick Ohly <pat...@in...> wrote:
> 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
I wonder how it is doing that...
> I'm not sure about this _DTOR_END__ and how the program ended up there.
> 0x403aa1c contains:
> 0x0403aa1c: jmp *0x18(%ebx)
That's the PLT entry that links the two shared libraries together
at a guess.
> 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
> ...
That is the problem then - as __libc_write does not construct a
stack frame, the PC will appear to be in that routine but when the
stack is unwound we will wind up in the caller of __pthread_create_2_1.
When there are no frame pointers unwinding the stack is hard (there
are tricks but I didn't realise gdb used them) unless the debug
info tells you how, and stabs can't do that (DWARF can).
The debugger we use (ups) does have tricks for unwinding the stack
when there is no frame pointer by searching the stack looking for
an address which appears to map to a call instruction targeting
the current routine - my colleague wrote the code in question and
it has been maintained by me more recently. That is really horrible
stuff though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|