|
From: Joe V. A. <van...@at...> - 2003-10-16 13:22:22
|
Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure: valgrind -v --gdb-attach=yes merge_beam -v ==16807== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==16807== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==16807== Using valgrind-20031012, a program supervision framework for x86-linux. ==16807== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==16807== Command line: ==16807== merge_beam ==16807== -v ==16807== Startup, with flags: ==16807== --suppressions=/opt/local_rh90/lib/valgrind/default.supp ==16807== -v ==16807== --gdb-attach=yes ==16807== Reading syms from /code/vanandel/raddx/spol/merge_beam/merge_beam ==16807== Reading syms from /lib/ld-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/valgrind/vgskin_memcheck.so ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/valgrind/valgrind.so ==16807== Reading syms from /net/opt_lnx/ACE-5.3/ace/libACE.so.5.3.0 ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/libdb_cxx-4.1.so ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/libdb-4.1.so ==16807== Reading syms from /net/local_lnx/gcc/3.2.2-redhat8.0/lib/liblog4cpp.so.3.1.3 ==16807== Reading syms from /usr/lib/libstdc++.so.5.0.3 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /lib/tls/libm-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /net/local_lnx/gcc/3.2.2-redhat8.0/lib/libgcc_s.so.1 ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/valgrind/libpthread.so ==16807== Reading syms from /lib/libdl-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /lib/tls/librt-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /net/opt_lnx/qt-3.1.2/lib/libqt-mt.so.3.1.2 ==16807== Reading syms from /lib/libnsl-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXft.so.2.1 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libfontconfig.so.1.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libpng12.so.0.1.2.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libz.so.1.1.4 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /net/opt_lnx/local_rh90/lib/libGL.so.1.4.501 ==16807== Reading syms from /usr/X11R6/lib/libXmu.so.6.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXrender.so.1.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libfreetype.so.6.3.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXext.so.6.4 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libX11.so.6.2 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libSM.so.6.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libICE.so.6.3 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/lib/libexpat.so.0.4.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXi.so.6.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /usr/X11R6/lib/libXt.so.6.0 ==16807== object doesn't have a symbol table ==16807== object doesn't have any debug info ==16807== Reading syms from /lib/tls/libc-2.3.2.so ==16807== object doesn't have any debug info ==16807== Reading suppressions file: /opt/local_rh90/lib/valgrind/default.supp ==16807== Estimated CPU clock rate is 2796 MHz ==16807== REPLACING libc(__GI___errno_location) with libpthread(__errno_location) ==16807== REPLACING libc(__GI___h_errno_location) with libpthread(__h_errno_location) ==16807== REPLACING libc(__GI___res_state) with libpthread(__res_state) ==16807== valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed. sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==16807== at 0x42029E51: __new_exitfn (in /lib/tls/libc-2.3.2.so) ==16807== by 0x42029E08: __cxa_atexit_internal (in /lib/tls/libc-2.3.2.so) ==16807== by 0x40611727: (within /usr/lib/libstdc++.so.5.0.3) ==16807== by 0x40611779: (within /usr/lib/libstdc++.so.5.0.3) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: js...@ac... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel at ucar dot edu |
|
From: Tom H. <th...@cy...> - 2003-10-16 13:52:46
|
In message <3F8...@at...>
Joe Van Andel <van...@at...> wrote:
> Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure:
>
> valgrind -v --gdb-attach=yes merge_beam -v
> ==16807== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==16807== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==16807== Using valgrind-20031012, a program supervision framework for x86-linux.
[ snipped details ]
> valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed.
That's an attempt to access the GDT which won't work, but it's
happening because you're using RedHat 9 which has NPTL and you've
somehow managed to bypass the code in valgrind that tries to set
LD_ASSUME_KERNEL to force old style threading.
Set LD_ASSUME_KERNEL to 2.4.1 in your environment and it should
work fine.
You might also like to check what nptl_threading is set to at the
top of the valgrind shell script - it should be "yes" for RH9 which
would then force LD_ASSUME_KERNEL to be set.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dirk M. <dm...@gm...> - 2003-10-16 17:20:32
|
On Thursday 16 October 2003 17:22, Joe Van Andel wrote: > I rebuilt valgrind from CVS, today, 2003/10/16. Valgrind works under > the 2.4.22 kernel, but fails under 2.4.20 (as shipped by Redhat). I'm > not sure why a newer kernel allows valgrind to work, but at least I can > continue debugging. because you didn't include the patches to make NPTL work. please answer the questions so we can see if there is anything wrong with the configure check. |
|
From: Joe V. A. <van...@at...> - 2003-10-16 19:04:10
|
Dirk Mueller wrote: > On Thursday 16 October 2003 17:22, Joe Van Andel wrote: > > >>I rebuilt valgrind from CVS, today, 2003/10/16. Valgrind works under >>the 2.4.22 kernel, but fails under 2.4.20 (as shipped by Redhat). I'm >>not sure why a newer kernel allows valgrind to work, but at least I can >>continue debugging. > > > because you didn't include the patches to make NPTL work. Which patches? I built direct with source direct from CVS, where should I obtain the additional patches? > > please answer the questions so we can see if there is anything wrong with the > configure check. Now I have a better idea what happened. I built valgrind under 2.4.22, but ran it on 2.4.20. I didn't realize this might be a problem, but I'll be more careful in the future. Perhaps there is a way of warning the user when valgrind is not compatible with the current kernel? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel at ucar dot edu |
|
From: Dirk M. <dm...@gm...> - 2003-10-16 19:32:11
|
On Thursday 16 October 2003 21:01, Joe Van Andel wrote: > > because you didn't include the patches to make NPTL work. > Which patches? > I built direct with source direct from CVS, where should I obtain the > additional patches? The kernel patches which are needed to use NPTL. > Now I have a better idea what happened. I built valgrind under 2.4.22, > but ran it on 2.4.20. I didn't realize this might be a problem, but > I'll be more careful in the future. Perhaps there is a way of warning > the user when valgrind is not compatible with the current kernel? well, then there would be not much point in checking at compile time at all. |
|
From: Olly B. <ol...@su...> - 2003-10-16 20:16:39
|
On Thu, Oct 16, 2003 at 09:31:58PM +0200, Dirk Mueller wrote:
> well, then there would be not much point in checking at compile time at all.
Perhaps the small program which is currently built and run at configure
time to check for NPTL should actually be built and installed (e.g. as
/usr/lib/valgrind/nptlcheck) and then run from the valgrind wrapper
script?
AIUI, at present if the user builds and installs valgrind using a
non-NPTL kernel and then upgrades to an NPTL kernel, valgrind won't
disable NPTL. That seems a fairly common scenario. It'll also fail to
disable NPTL if the user installs a valgrind package (RPM, deb, etc)
built on a non-NPTL kernel machine.
Cheers,
Olly
|
|
From: Tom H. <th...@cy...> - 2003-10-16 22:38:19
|
In message <200...@su...>
Olly Betts <ol...@su...> wrote:
> Perhaps the small program which is currently built and run at configure
> time to check for NPTL should actually be built and installed (e.g. as
> /usr/lib/valgrind/nptlcheck) and then run from the valgrind wrapper
> script?
You don't need a special program - glibc already provides a way to
check using the getconf program, like this:
audi [~] % getconf GNU_LIBPTHREAD_VERSION
NPTL 0.34
on an RH8 box you get this:
ginetta [~] % getconf GNU_LIBPTHREAD_VERSION
linuxthreads-0.10
and on an RH7.3 box before glibc added the variable, you get an error:
alvis [~] % getconf GNU_LIBPTHREAD_VERSION
getconf: Unrecognised variable `GNU_LIBPTHREAD_VERSION'
So using this line in the valgrind shell script in place of the current
solution should fix things:
getconf GNU_LIBPTHREAD_VERSION | grep -qi NPTL 2> /dev/null && \
LD_ASSUME_KERNEL=2.4.1
Note that you only need to go back to 2.4.1 and not 2.2.5 as it does
at the moment - as shown by this on an RH9 box:
audi [~] % LD_ASSUME_KERNEL=2.4.1 getconf GNU_LIBPTHREAD_VERSION
linuxthreads-0.10
> AIUI, at present if the user builds and installs valgrind using a
> non-NPTL kernel and then upgrades to an NPTL kernel, valgrind won't
> disable NPTL. That seems a fairly common scenario. It'll also fail to
> disable NPTL if the user installs a valgrind package (RPM, deb, etc)
> built on a non-NPTL kernel machine.
All true.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Olly B. <ol...@su...> - 2003-10-17 10:10:01
Attachments:
valgrind-nptl.patch
|
On Thu, Oct 16, 2003 at 11:37:49PM +0100, Tom Hughes wrote:
> So using this line in the valgrind shell script in place of the current
> solution should fix things:
>
> getconf GNU_LIBPTHREAD_VERSION | grep -qi NPTL 2> /dev/null && \
> LD_ASSUME_KERNEL=2.4.1
>
> Note that you only need to go back to 2.4.1 and not 2.2.5 as it does
> at the moment - as shown by this on an RH9 box:
>
> audi [~] % LD_ASSUME_KERNEL=2.4.1 getconf GNU_LIBPTHREAD_VERSION
> linuxthreads-0.10
Better still! I've made a patch based on this (attached), and tested it
with valgrind-20031012 on a non-NPTL box. I don't have an NPTL box
handy I'm afraid.
Incidentally, memcheck/tests/badrw.c seems to be missing from CVS on the
VALGRIND_2_0_REALLY branch (so "make check" fails), while on HEAD
memcheck/tests/filter_mismatches seems to be missing (so "make" fails).
Cheers,
Olly
|
|
From: Tom H. <th...@cy...> - 2003-10-17 12:54:30
|
In message <200...@su...>
Olly Betts <ol...@su...> wrote:
> Better still! I've made a patch based on this (attached), and tested it
> with valgrind-20031012 on a non-NPTL box. I don't have an NPTL box
> handy I'm afraid.
I just checked it on an RH9 box and it seems to be fine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-20 19:08:07
|
On Fri, 17 Oct 2003, Olly Betts wrote: > Better still! I've made a patch based on this (attached), and tested it > with valgrind-20031012 on a non-NPTL box. I don't have an NPTL box > handy I'm afraid. It's been incorporated, thanks. > Incidentally, memcheck/tests/badrw.c seems to be missing from CVS on the > VALGRIND_2_0_REALLY branch (so "make check" fails), while on HEAD > memcheck/tests/filter_mismatches seems to be missing (so "make" fails). I don't see either of these problems... maybe they've been fixed since you reported them? N |
|
From: Olly B. <ol...@su...> - 2003-10-21 03:07:02
|
On Mon, Oct 20, 2003 at 03:06:59PM +0100, Nicholas Nethercote wrote: > On Fri, 17 Oct 2003, Olly Betts wrote: > > Better still! I've made a patch based on this (attached), and tested it > > with valgrind-20031012 on a non-NPTL box. I don't have an NPTL box > > handy I'm afraid. > > It's been incorporated, thanks. No problem. > > Incidentally, memcheck/tests/badrw.c seems to be missing from CVS on the > > VALGRIND_2_0_REALLY branch (so "make check" fails), while on HEAD > > memcheck/tests/filter_mismatches seems to be missing (so "make" fails). > > I don't see either of these problems... maybe they've been fixed since you > reported them? Nope. Looking at the HEAD problem: $ cvs status memcheck/tests/filter_mismatches =================================================================== File: no file filter_mismatches Status: Up-to-date Working revision: No entry for filter_mismatches Repository revision: 1.2 /cvsroot/valgrind/valgrind/memcheck/tests/Attic/filter_mismatches,v $ cvs up -r1.1 memcheck/tests/filter_mismatches U memcheck/tests/filter_mismatches $ cvs up -r1.2 memcheck/tests/filter_mismatches cvs server: memcheck/tests/filter_mismatches is no longer in the repository I guess this could be a problem with sourceforge's CVS mirroring - you're presumably using the developer server, while I'll be using the mirror which uses 24 hour snapshots. It's not actually a problem for me, but if I can provide any clues to help fix it, just ask. Cheers, Olly |
|
From: Olly B. <ol...@su...> - 2003-10-21 08:27:38
|
On Mon, Oct 20, 2003 at 11:16:19PM +0100, Nicholas Nethercote wrote: > On Mon, 20 Oct 2003, Olly Betts wrote: > > Working revision: No entry for filter_mismatches > > Repository revision: 1.2 /cvsroot/valgrind/valgrind/memcheck/tests/Attic/filter_mismatches,v > > AFAICT, that file has been removed, and all references to it in the > Makefile.am have also been removed. Do you need to run automake+autoconf > again? Aha! That is indeed the problem. I was relying on automake spotting any changes in Makefile.am-s and regenerating them for me, but you've disabled that by default by specifying AM_MAINTAINER_MODE in configure.in. I regenerated everything with `autoreconf -f -i' and it now works. Cheers, Olly |
|
From: Nicholas N. <nj...@ca...> - 2003-10-21 08:34:31
|
On Tue, 21 Oct 2003, Olly Betts wrote: > > AFAICT, that file has been removed, and all references to it in the > > Makefile.am have also been removed. Do you need to run automake+autoconf > > again? > > Aha! That is indeed the problem. I was relying on automake spotting > any changes in Makefile.am-s and regenerating them for me, but you've > disabled that by default by specifying AM_MAINTAINER_MODE in > configure.in. I regenerated everything with `autoreconf -f -i' and > it now works. Ah, so automake can rerun itself when necessary? That would be great... is it just a matter of not specifying AM_MAINTAINER_MODE? What's the advantage of having AM_MAINTAINER_MODE? N |
|
From: Dirk M. <dm...@gm...> - 2003-10-21 09:39:24
|
On Tuesday 21 October 2003 10:28, Nicholas Nethercote wrote: > Ah, so automake can rerun itself when necessary? That would be great... > is it just a matter of not specifying AM_MAINTAINER_MODE? What's the > advantage of having AM_MAINTAINER_MODE? that automake by default does not regenerate the makefiles. this is useful for tarballs where people unpack them on broken partitions or using wrong system time, which might cause the dependency check to think that Makefile.in needs to be regenerated.. which then requires the exact automake version that the tarball was created with initially. That would usually fail, because nondevelopers usually don't have automake installed, or the wrong version. its just a matter of calling ./configure --enable-maintainer-mode if you are a maintainer. |
|
From: Olly B. <ol...@su...> - 2003-10-21 10:06:32
|
On Tue, Oct 21, 2003 at 09:28:35AM +0100, Nicholas Nethercote wrote:
> Ah, so automake can rerun itself when necessary? That would be great...
> is it just a matter of not specifying AM_MAINTAINER_MODE?
Yes and yes.
> What's the advantage of having AM_MAINTAINER_MODE?
Here's what the automake docs say:
`AM_MAINTAINER_MODE'
This macro adds a `--enable-maintainer-mode' option to
`configure'. If this is used, `automake' will cause
`maintainer-only' rules to be turned off by default in the
generated `Makefile.in's. This macro is disallowed in `Gnits'
mode (*note Gnits::). This macro defines the `MAINTAINER_MODE'
conditional, which you can use in your own `Makefile.am'.
I think the idea is to turn off extra rules and dependencies which aren't
useful to people who are only building the software, and would be confused
if they managed to invoke them. But then it confuses people like me not to
regenerate when configure.in or a Makefile.am is modified!
Since valgrind is aimed squarely at developers, AM_MAINTAINER_MODE seems of
little benefit.
Or if you'd prefer to leave AM_MAINTAINER_MODE in, you can turn maintainer
mode back on for yourself by configuring with:
configure --enable-maintainer-mode
Cheers,
Olly
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-21 09:24:46
|
On Tue, 21 Oct 2003, Olly Betts wrote: > > What's the advantage of having AM_MAINTAINER_MODE? > > Here's what the automake docs say: > > `AM_MAINTAINER_MODE' > This macro adds a `--enable-maintainer-mode' option to > `configure'. If this is used, `automake' will cause > `maintainer-only' rules to be turned off by default in the > generated `Makefile.in's. This macro is disallowed in `Gnits' > mode (*note Gnits::). This macro defines the `MAINTAINER_MODE' > conditional, which you can use in your own `Makefile.am'. > > I think the idea is to turn off extra rules and dependencies which aren't > useful to people who are only building the software, and would be confused > if they managed to invoke them. But then it confuses people like me not to > regenerate when configure.in or a Makefile.am is modified! > > Since valgrind is aimed squarely at developers, AM_MAINTAINER_MODE seems of > little benefit. Hmm, the docs are very vague about what 'maintainer-only' rules are. But I don't imagine we're using them. Thanks for the info. N |
|
From: Derick R. <d.r...@jd...> - 2003-10-16 20:05:43
|
On Thu, 16 Oct 2003, Joe Van Andel wrote: > Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure: The latest version (released yesterday) fixed this for me. regards, Derick -- ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ International PHP Magazine http://www.php-mag.net/ ------------------------------------------------------------------------- |
|
From: Joe V. A. <van...@at...> - 2003-10-16 15:23:02
|
Derick Rethans wrote: > On Thu, 16 Oct 2003, Joe Van Andel wrote: > > >>Using RH 9.0 and gcc 3.2.2, valgrind exits with an assertion failure: > > > The latest version (released yesterday) fixed this for me. I rebuilt valgrind from CVS, today, 2003/10/16. Valgrind works under the 2.4.22 kernel, but fails under 2.4.20 (as shipped by Redhat). I'm not sure why a newer kernel allows valgrind to work, but at least I can continue debugging. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel at ucar dot edu |