|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 01:45:18
|
Hi,
We're using Red Hat Linux 9 with latest updates, and valgrind 20030725
built from sources. Our machines have lots of different NVidia cards
like Quadro4 700 XGL or Quadro4 NVS.
I'm attempting to run our OpenGL application under valgrind. Since our
machines have NVidia graphic cards, I tried the trick described in the FAQ:
__GL_FORCE_GENERIC_CPU=1
export __GL_FORCE_GENERIC_CPU
Unfortunately this doesn't help. I've tried with NVidia drivers 4349,
4363, and 4496. I get the exact same error with all of these drivers:
==8001== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==8001== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==8001== Using valgrind-20030725, a program supervision framework for
x86-linux.
==8001== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==8001== Estimated CPU clock rate is 1999 MHz
==8001== For more details, rerun with: -v
==8001==
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
==8001== at 0x4120C641: __nvsym18200 (in /usr/lib/tls/libGL.so.1.0.4496)
Do you have a clue what might be happening here? My understanding is
that the NVidia drivers don't disable all of MMX and SSE optimizations
when __GL_FORCE_GENERIC_CPU is defined. I'll attempt to contact NVidia
through the NVidia users' forum, but it would help if you have a clue
about what might be happening.
--
Dimitri
|
|
From: Jeremy F. <je...@go...> - 2003-09-09 06:06:24
|
On Mon, 2003-09-08 at 06:59, Dimitri Papadopoulos-Orfanos wrote: > Unfortunately this doesn't help. I've tried with NVidia drivers 4349, > 4363, and 4496. I get the exact same error with all of these drivers: I just tried this, and it works for me with glxgears. I've got a GeForce FX 5600 with 4496 drivers on a Pentium 4 machine. I'm also running a 2.6-test kernel, so I wonder if that has anything to do with it. One other thing to try: some shells do strange things with __ in variable names, so you could try: env __GL_FORCE_GENERIC_CPU=1 valgrind yourprog Does it work with glxgears, or is it broken for everything? I wonder if it has something to do with threading or something. J |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 07:43:20
|
Hi, >>Unfortunately this doesn't help. I've tried with NVidia drivers 4349, >>4363, and 4496. I get the exact same error with all of these drivers: > > > I just tried this, and it works for me with glxgears. I've got a > GeForce FX 5600 with 4496 drivers on a Pentium 4 machine. I'm also > running a 2.6-test kernel, so I wonder if that has anything to do with > it. I've just tried glxgears. I have exactly the same error message: $ env __GL_FORCE_GENERIC_CPU=1 valgrind /usr/X11R6/bin/glxgears ==9373== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==9373== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==9373== Using valgrind-20030725, a program supervision framework for x86-linux. ==9373== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==9373== Estimated CPU clock rate is 2002 MHz ==9373== For more details, rerun with: -v ==9373== 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 ==9373== at 0x40272641: __nvsym18200 (in /usr/lib/tls/libGL.so.1.0.4496) > One other thing to try: some shells do strange things with __ in > variable names, so you could try: > > env __GL_FORCE_GENERIC_CPU=1 valgrind yourprog Unfortunately this is not a shell issue. > Does it work with glxgears, or is it broken for everything? I wonder if > it has something to do with threading or something. It's broken for everything. I don't think this has anything to do with threading. The glxgears example doesn't use threads (although OpenGL probably does internally). It's possible to revert from NTPL to the old threading mechanism by setting: LD_ASSUME_KERNEL=2.4.1 export LD_ASSUME_KERNEL I don't think the kernel has anything to do with that either, this really has to do with code executed in NVidia's libGL. The nVidia card model may have something to do with that, as different cards may trigger different code. I'm currently using an nVidia NV25GL [Quadro4 700 XGL] card. I'll try with other cards and report back. Does anyone have a clue whether this error has to do with unsupported MMX/SSE instructions? -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 07:33:40
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> 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
> ==8001== at 0x4120C641: __nvsym18200 (in
> /usr/lib/tls/libGL.so.1.0.4496)
This is a segment selector problem in a TLS library, so is almost
certainly nothing to do with MMX or SSE support.
You said you were using RH9 but I'm guessing that the version of
valgrind you're using is too old to set LD_ASSUME_KERNEL so it is
trying to use NPTL style TLS which valgrind can't handle.
Try setting LD_ASSUME_KERNEL=2.4.1 in your environment, and if that
makes it work then consider upgrading valgrind.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 07:47:44
|
Hi, > This is a segment selector problem in a TLS library, so is almost > certainly nothing to do with MMX or SSE support. > > You said you were using RH9 but I'm guessing that the version of > valgrind you're using is too old to set LD_ASSUME_KERNEL so it is > trying to use NPTL style TLS which valgrind can't handle. > > Try setting LD_ASSUME_KERNEL=2.4.1 in your environment, and if that > makes it work then consider upgrading valgrind. Unfortunately this doesn't work any better. I'll try different nVidia cards and see if that makes a difference. -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 08:31:32
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> > This is a segment selector problem in a TLS library, so is almost
> > certainly nothing to do with MMX or SSE support.
> > You said you were using RH9 but I'm guessing that the version of
>
> > valgrind you're using is too old to set LD_ASSUME_KERNEL so it is
> > trying to use NPTL style TLS which valgrind can't handle.
> > Try setting LD_ASSUME_KERNEL=2.4.1 in your environment, and if that
>
> > makes it work then consider upgrading valgrind.
>
> Unfortunately this doesn't work any better.
Does it still fail in a /lib/tls/... library? Only those libraries
use NPTL style TLS and won't work with valgrind, but that setting
of LD_ASSUME_KERNEL should stop the dynamic loader using them.
Look at what happens to libc on my RH9 box when I set it:
audi [~] % ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
audi [~] % LD_ASSUME_KERNEL=2.4.1 ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
libc.so.6 => /lib/i686/libc.so.6 (0x40031000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 08:52:27
|
Hi,
> Does it still fail in a /lib/tls/... library? Only those libraries
Yes, the error message is exactly the same.
> use NPTL style TLS and won't work with valgrind, but that setting
> of LD_ASSUME_KERNEL should stop the dynamic loader using them.
>
> Look at what happens to libc on my RH9 box when I set it:
>
> audi [~] % ldd /bin/ls
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
> libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> audi [~] % LD_ASSUME_KERNEL=2.4.1 ldd /bin/ls
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
> libc.so.6 => /lib/i686/libc.so.6 (0x40031000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
My machine runs Red Hat 9 with recent updates. The output of these same
commands on my machine is identical:
$ ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$
$ setenv LD_ASSUME_KERNEL 2.4.1
$
$ ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000)
libc.so.6 => /lib/i686/libc.so.6 (0x40030000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$
However it's different for GL libraries:
$ ldd /usr/X11R6/bin/glxgears
libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x4002c000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40097000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400a5000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40185000)
libm.so.6 => /lib/tls/libm.so.6 (0x40193000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x401b5000)
libdl.so.2 => /lib/libdl.so.2 (0x40695000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$
$ setenv LD_ASSUME_KERNEL 2.4.1
$ ldd /usr/X11R6/bin/glxgears
libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x4002c000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40097000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400a5000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40185000)
libm.so.6 => /lib/i686/libm.so.6 (0x401d5000)
libc.so.6 => /lib/i686/libc.so.6 (0x401f7000)
libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x4032f000)
libdl.so.2 => /lib/libdl.so.2 (0x4080f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /usr/X11R6/bin/glxgears
libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x4002c000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40097000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400a5000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40185000)
libm.so.6 => /lib/i686/libm.so.6 (0x401d5000)
libc.so.6 => /lib/i686/libc.so.6 (0x401f7000)
libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x4032f000)
libdl.so.2 => /lib/libdl.so.2 (0x4080f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$
What is the output on your machine? These are the libGL libraries
available on my machine:
$ locate libGL.
/usr/lib/libGL.so.1.0.4496
/usr/lib/tls/libGL.so.1.0.4496
/usr/lib/tls/libGL.so.1
/usr/lib/tls/libGL.so
/usr/lib/libGL.so.1
/usr/lib/libGL.so
$
$ file [...]
/usr/lib/libGL.so.1.0.4496: ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), stripped
/usr/lib/tls/libGL.so.1.0.4496: ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), stripped
/usr/lib/tls/libGL.so.1: symbolic link to libGL.so.1.0.4496
/usr/lib/tls/libGL.so: symbolic link to libGL.so.1
/usr/lib/libGL.so.1: symbolic link to libGL.so.1.0.4496
/usr/lib/libGL.so: symbolic link to libGL.so.1
$
--
Dimitri
|
|
From: Tom H. <th...@cy...> - 2003-09-09 09:33:43
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> What is the output on your machine? These are the libGL libraries
> available on my machine:
>
>
> $ locate libGL.
> /usr/lib/libGL.so.1.0.4496
> /usr/lib/tls/libGL.so.1.0.4496
> /usr/lib/tls/libGL.so.1
> /usr/lib/tls/libGL.so
> /usr/lib/libGL.so.1
> /usr/lib/libGL.so
I don't seem to have the TLS ones. This is what I have:
audi [~] % locate libGL.
/usr/lib/libGL.so.1
/usr/lib/libGL.so
/usr/X11R6/lib/libGL.so.1
/usr/X11R6/lib/libGL.so.1.2
/usr/X11R6/lib/libGL.a
/usr/X11R6/lib/libGL.so
They are from the XFree86-Mesa-libGL-4.3.0-2 rpm. Presumably your
ones have come from some NVidia specific driver or something? I'm
using a Matrox G550 in this machine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 11:20:12
|
Hi, >>What is the output on your machine? These are the libGL libraries >>available on my machine: >> >> >>$ locate libGL. >>/usr/lib/libGL.so.1.0.4496 >>/usr/lib/tls/libGL.so.1.0.4496 >>/usr/lib/tls/libGL.so.1 >>/usr/lib/tls/libGL.so >>/usr/lib/libGL.so.1 >>/usr/lib/libGL.so > > > I don't seem to have the TLS ones. This is what I have: > > audi [~] % locate libGL. > /usr/lib/libGL.so.1 > /usr/lib/libGL.so > /usr/X11R6/lib/libGL.so.1 > /usr/X11R6/lib/libGL.so.1.2 > /usr/X11R6/lib/libGL.a > /usr/X11R6/lib/libGL.so > > They are from the XFree86-Mesa-libGL-4.3.0-2 rpm. Presumably your > ones have come from some NVidia specific driver or something? I'm > using a Matrox G550 in this machine. These are indeed added by the nVidia driver. But nVidia have always replaced the stock libGL with their own libGL. Could this be the problem? -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 11:58:05
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> These are indeed added by the nVidia driver. But nVidia have always
> replaced the stock libGL with their own libGL. Could this be the
> problem?
It is the problem, the question is whether you can work around it.
I see that you have /usr/lib/libGL.so as well as the TLS variant, so
it maybe that using that would resolve the problem. I would have
expected setting LD_ASSUME_KERNEL to do that though if the libraries
have been built correctly with the right capability masks.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 14:02:35
|
Hi, >>These are indeed added by the nVidia driver. But nVidia have always >>replaced the stock libGL with their own libGL. Could this be the >>problem? > > > It is the problem, the question is whether you can work around it. > > I see that you have /usr/lib/libGL.so as well as the TLS variant, so > it maybe that using that would resolve the problem. I would have > expected setting LD_ASSUME_KERNEL to do that though if the libraries > have been built correctly with the right capability masks. OK. I've temporarily moved /usr/lib/tls to /usr/lib/tls- and valgrind now runs on glxgears. There are lots of errors/warnings, but it runs: $ glxgears-valgrind ==5008== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==5008== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==5008== Using valgrind-20030725, a program supervision framework for x86-linux. ==5008== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==5008== Estimated CPU clock rate is 1995 MHz ==5008== For more details, rerun with: -v ==5008== ==5008== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains uninitialised or unaddressable byte(s) ==5008== at 0x402708D8: (within /usr/lib/libGL.so.1.0.4496) ==5008== Address 0xBFFFDF00 is on thread 1's stack ==5008== ==5008== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) [...] ==5008== ERROR SUMMARY: 2195 errors from 103 contexts (suppressed: 0 from 0) ==5008== malloc/free: in use at exit: 2149874 bytes in 418 blocks. ==5008== malloc/free: 1652 allocs, 1234 frees, 3488651 bytes allocated. ==5008== For a detailed leak analysis, rerun with: --leak-check=yes ==5008== For counts of detected errors, rerun with: -v $ Is this bug in nVidia libraries? I'd be grateful if someone can rapidly explain the problem, so that I can report it to nVidia. From what I can understand nVidia libraries aren't properly tagged with capability masks, so LD_ASSUME_KERNEL doesn't have the expected effect. How to retrieve the capability mask of a library? What should the capability mask of /usr/lib/libGL.so and /usr/lib/tls/libGL.so look like? -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 14:43:47
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> Is this bug in nVidia libraries? I'd be grateful if someone can
> rapidly explain the problem, so that I can report it to nVidia. From
> what I can understand nVidia libraries aren't properly tagged with
> capability masks, so LD_ASSUME_KERNEL doesn't have the expected
> effect. How to retrieve the capability mask of a library? What should
> the capability mask of /usr/lib/libGL.so and /usr/lib/tls/libGL.so
> look like?
Move the libraries back where they were and try doing "ldconfig -p"
and see what you get. This is what I see for libc:
audi [~] % ldconfig -p | grep libc.so
libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20) => /lib/tls/libc.so.6
libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6
Note that the TLS library has an OS ABI of 2.4.20 which is why setting
the ABI to 2.4.1 with LD_ASSUME_KERNEL causes the i686 version to be
used. You should see something similar for those libGL instances and
if you don't then it would explain your problem.
You can also use objdump to look at the ABI declaration in the
libraries directly:
audi [~] % objdump -j .note.ABI-tag -s /lib/tls/libc.so.6
/lib/tls/libc.so.6: file format elf32-i386
Contents of section .note.ABI-tag:
42000134 04000000 10000000 01000000 474e5500 ............GNU.
42000144 00000000 02000000 04000000 14000000 ................
Here the last three words are 0x2, 0x4 and 0x14, or 2.2.20 in decimal.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 16:04:58
|
Hi, > Move the libraries back where they were and try doing "ldconfig -p" > and see what you get. This is what I see for libc: > > audi [~] % ldconfig -p | grep libc.so > libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20) => /lib/tls/libc.so.6 > libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6 > libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6 Ah! We're getting somewhere: # ldconfig -p | grep libGL.so libGL.so.1 (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/libGL.so.1 libGL.so (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so libGL.so (libc6) => /usr/lib/libGL.so # There's no 'OS ABI' information in these libraries. > Note that the TLS library has an OS ABI of 2.4.20 which is why setting > the ABI to 2.4.1 with LD_ASSUME_KERNEL causes the i686 version to be > used. You should see something similar for those libGL instances and > if you don't then it would explain your problem. OK, I understand this is unrelated to __GL_FORCE_GENERIC_CPU and is a bug in nVidia libraries. /lib/tls/libc.so.6 should have this additional information: OS ABI: Linux 2.4.20 Is that correct? If so, I'll send a bug report to nVidia. By the way, what is the role of these 'tls' subdirectories? Are they supposed to specifically offer alternatives between NTPL and older thread mechanisms? -- Dimitri |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-10 12:33:05
|
Hi, > OK, I understand this is unrelated to __GL_FORCE_GENERIC_CPU and is > a bug in nVidia libraries. /lib/tls/libc.so.6 should have this > additional information: > OS ABI: Linux 2.4.20 > > Is that correct? If so, I'll send a bug report to nVidia. > > By the way, what is the role of these 'tls' subdirectories? Are they > supposed to specifically offer alternatives between NTPL and older > thread mechanisms? OK, I've now read this post: http://www.cs.helsinki.fi/linux/linux-kernel/2003-20/0672.html and it helped me understand the role of the 'tls' subdirectories: It is because you only compiled it with nptl support. In recent (nptl enabled) Redhat glibc's glibc is build two times. 1) without nptl 2) with nptl The version without nptl support is then installed into the 'default' location. The other is installed into /lib/tls/ and /usr/lib/tls/. ld.so is then hacked (maybe in mainline glibc now?) to load the tls enabled versions of the libraries only if the kernel/hardware support it. My understanding was that switching between libraries in /usr/lib/tls/ to /usr/lib/ or from /lib/tls/ to /lib/ was governed by simple rules based only on the location of libraries in either of these directories. In that scenario, library capability masks in specific don't play any role. Now my understanding is that ld.so actually looks into the capability mask inside libraries, in addition to the location of the libraries in tls/ subdirectories. I'm surprized by the lack of information on these new ld.so mechanisms. I wasn't able to find anything substantial in Google or Ulrich Drepper's home page http://people.redhat.com/drepper/. I guess I'll have to look into the ld.so source code. Does anyone have more information on this mechanism or a link that woudl explain it? -- Dimitri |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 09:10:01
|
Hi, > I'll try different nVidia cards and see if that makes a difference. I've tried many of the following nVidia cards and the error message is always the same: NV25GL [Quadro4 700 XGL] NV15 [GeForce2 GTS/Pro] So this is probably not related to the card model. The interesting thing is that valgrind also fails on a Red Hat 9 machine with recent updates with a Matrox MGA G400 AGP card. But it fails differently: ==11019== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==11019== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==11019== Using valgrind-20030725, a program supervision framework for x86-linux. ==11019== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==11019== Estimated CPU clock rate is 548 MHz ==11019== For more details, rerun with: -v ==11019== ==11019== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==11019== at 0x404C2D24: __GI___ioctl (in /lib/libc-2.3.2.so) ==11019== by 0x417FE093: mgaInitDriver (in /usr/X11R6/lib/modules/dri/mga_dri.so) ==11019== by 0x416BBAC0: __driUtilCreateScreen (in /usr/X11R6/lib/modules/dri/mga_dri.so) ==11019== by 0x417FE884: __driCreateScreen (in /usr/X11R6/lib/modules/dri/mga_dri.so) ==11019== Address 0xBFFFDDD4 is on thread 1's stack disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF At this point the glxgears window hasn't appeared, valgrind has exited, and glxgears cannot be stopped using Ctrl+C or Ctrl+Z, one has to open another console to kill -9 it. -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 09:31:13
|
In message <3F5...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> The interesting thing is that valgrind also fails on a Red Hat 9
> machine with recent updates with a Matrox MGA G400 AGP card. But it
> fails differently:
I see the same with a G550 card.
> ==11019== Address 0xBFFFDDD4 is on thread 1's stack
> disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF
> disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF
These are SSE divide instructions which valgrind presumably doesn't
implement yet.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-09 09:24:39
|
On Tue, 9 Sep 2003, Dimitri Papadopoulos-Orfanos wrote: > > audi [~] % ldd /bin/ls > > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000) > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > audi [~] % LD_ASSUME_KERNEL=2.4.1 ldd /bin/ls > > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000) > > libc.so.6 => /lib/i686/libc.so.6 (0x40031000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > My machine runs Red Hat 9 with recent updates. The output of these same > commands on my machine is identical: > > $ ldd /bin/ls > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > $ > $ setenv LD_ASSUME_KERNEL 2.4.1 > $ > $ ldd /bin/ls > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) > libc.so.6 => /lib/i686/libc.so.6 (0x40030000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Um, those outputs aren't identical. N |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 09:32:35
|
>>$ ldd /bin/ls >> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) >> libc.so.6 => /lib/tls/libc.so.6 (0x42000000) >> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) >>$ >>$ setenv LD_ASSUME_KERNEL 2.4.1 >>$ >>$ ldd /bin/ls >> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000) >> libc.so.6 => /lib/i686/libc.so.6 (0x40030000) >> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > Um, those outputs aren't identical. I mean they are (almost) identical to Tom's output. -- Dimitri |
|
From: Tom H. <th...@cy...> - 2003-09-09 09:37:01
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 9 Sep 2003, Dimitri Papadopoulos-Orfanos wrote:
>
> > $ ldd /bin/ls
> > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000)
> > libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > $
> > $ setenv LD_ASSUME_KERNEL 2.4.1
> > $
> > $ ldd /bin/ls
> > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002c000)
> > libc.so.6 => /lib/i686/libc.so.6 (0x40030000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Um, those outputs aren't identical.
I think he meant identical to what I got.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|