|
From: Tom H. <to...@co...> - 2004-02-28 03:25:24
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-02-28 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 126 tests, 15 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) |
|
From: Tom H. <th...@cy...> - 2004-02-28 17:22:54
|
In message <E1A...@du...>
Tom Hughes <to...@co...> wrote:
> == 126 tests, 15 stderr failures, 1 stdout failure =================
> corecheck/tests/fdleak_cmsg (stderr)
> corecheck/tests/fdleak_creat (stderr)
> corecheck/tests/fdleak_dup (stderr)
> corecheck/tests/fdleak_dup2 (stderr)
> corecheck/tests/fdleak_fcntl (stderr)
> corecheck/tests/fdleak_ipv4 (stderr)
> corecheck/tests/fdleak_open (stderr)
> corecheck/tests/fdleak_pipe (stderr)
> corecheck/tests/fdleak_socketpair (stderr)
> helgrind/tests/inherit (stderr)
> memcheck/tests/buflen_check (stderr)
> memcheck/tests/execve (stderr)
> memcheck/tests/fwrite (stderr)
> memcheck/tests/weirdioctl (stderr)
> memcheck/tests/writev (stderr)
> none/tests/exec-sigmask (stdout)
Most of these are failures of this form (the exact system call varies):
***************
*** 5 ****
! at 0x........: accept (in /...libc...)
--- 5 ----
! at 0x........: _dl_sysinfo_int80 (in /lib/ld-2.3.2.so)
This is down to the FC1 kernel/glibc combination making use of the sysinfo
page so that all system calls appear to occur in _dl_sysinfo_int80 but I did
think that Jeremy had put a hack in valgrind to make it back out to the next
function in that case when printing the stack trace.
The helgrind inherit test is as discussed in the RH 8 analysis and the
only other failure is none/tests/exec-sigmask which is reporting this:
***************
*** 0 ****
--- 1 ----
+ signal 32 missing from mask
I suspect something in glibc is removing signal 32 from the mask during
the exec or something, given that glibc uses that signal itself.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-02-29 21:46:48
|
On Sat, 2004-02-28 at 09:20, Tom Hughes wrote: > *************** > *** 5 **** > ! at 0x........: accept (in /...libc...) > --- 5 ---- > ! at 0x........: _dl_sysinfo_int80 (in /lib/ld-2.3.2.so) > > This is down to the FC1 kernel/glibc combination making use of the sysinfo > page so that all system calls appear to occur in _dl_sysinfo_int80 but I did > think that Jeremy had put a hack in valgrind to make it back out to the next > function in that case when printing the stack trace. Yes, that happens when you run under a kernel which doesn't have a sysinfo page. Normally, glibc will use the kernel's sysinfo, but if there isn't one, it uses _dl_sysinfo_int80. The FV loader will substitute the kernel's sysinfo page for its own, so that if your kernel supports sysinfo, Valgrind will do the right thing. The problem here is that it only substitutes an existing sysinfo page, but won't add an entry if there isn't one already. This means that glibc will use its own, and cause bogus traces like this. The fix is simple: add a sysinfo entry to the AUXV, even if there isn't one already. J |
|
From: Tom H. <th...@cy...> - 2004-03-02 09:58:17
|
In message <1078090988.30493.70.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> Yes, that happens when you run under a kernel which doesn't have a
> sysinfo page. Normally, glibc will use the kernel's sysinfo, but if
> there isn't one, it uses _dl_sysinfo_int80. The FV loader will
> substitute the kernel's sysinfo page for its own, so that if your kernel
> supports sysinfo, Valgrind will do the right thing. The problem here is
> that it only substitutes an existing sysinfo page, but won't add an
> entry if there isn't one already. This means that glibc will use its
> own, and cause bogus traces like this.
Right.
> The fix is simple: add a sysinfo entry to the AUXV, even if there isn't
> one already.
This doesn't appear to work. I think the problem is that recent
versions of glibc will ignore AT_SYSINFO unless AT_SYSINFO_EHDR is
also set - maybe this is what bug 73891 is about?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-03-02 22:10:07
|
On Tue, 2004-03-02 at 01:53, Tom Hughes wrote: > This doesn't appear to work. I think the problem is that recent > versions of glibc will ignore AT_SYSINFO unless AT_SYSINFO_EHDR is > also set - maybe this is what bug 73891 is about? That would be annoying. I'm not really sure what to put for the ehdr. J |
|
From: Tom H. <th...@cy...> - 2004-03-03 11:13:41
|
In message <1078264996.1032.10.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2004-03-02 at 01:53, Tom Hughes wrote:
>> This doesn't appear to work. I think the problem is that recent
>> versions of glibc will ignore AT_SYSINFO unless AT_SYSINFO_EHDR is
>> also set - maybe this is what bug 73891 is about?
>
> That would be annoying. I'm not really sure what to put for the ehdr.
Well it needs to be a pointer to a valid ELF header whose entry
point is the address of the sysinfo routine. The easiest way to
do it might be to actually build a separate shared object that
valgrind could map into the client address space in the same way
the 2.6 kernels do. More details of how it works can be found at:
http://lwn.net/Articles/30258/
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|