|
From: <aho...@es...> - 2003-10-16 16:38:13
|
I get the following log and segfault when running glxgears (or any other GL program it seems) with valgrind. My machine config is: AMD XP 1900 Radeon 9000 RH 9 with DRI from cvs Any suggestions where to start? Is there a convenient way to run gdb on valgrind while still using the 'valgrind' wrapper script? cheers, aaron wilder:~$ valgrind -v glxgears ==10543== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==10543== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==10543== Using valgrind-20031012, a program supervision framework for x86-linux. ==10543== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==10543== Command line: ==10543== glxgears ==10543== Startup, with flags: ==10543== --suppressions=/home/aholtzma/lib/valgrind/default.supp ==10543== -v ==10543== Reading syms from /usr/X11R6/bin/glxgears ==10543== object doesn't have a symbol table ==10543== object doesn't have any debug info ==10543== Reading syms from /lib/ld-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading syms from /home/aholtzma/lib/valgrind/vgskin_memcheck.so ==10543== Reading syms from /home/aholtzma/lib/valgrind/valgrind.so ==10543== Reading syms from /usr/X11R6/lib/libGL.so.1.2 ==10543== Reading syms from /usr/X11R6/lib/libXext.so.6.4 ==10543== object doesn't have a symbol table ==10543== object doesn't have any debug info ==10543== Reading syms from /usr/X11R6/lib/libX11.so.6.2 ==10543== object doesn't have a symbol table ==10543== object doesn't have any debug info ==10543== Reading syms from /home/aholtzma/lib/valgrind/libpthread.so ==10543== Reading syms from /lib/libm-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading syms from /lib/libc-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading syms from /lib/libdl-2.3.2.so ==10543== object doesn't have any debug info ==10543== Reading suppressions file: /home/aholtzma/lib/valgrind/default.supp ==10543== Estimated CPU clock rate is 1601 MHz ==10543== REPLACING libc(__GI___errno_location) with libpthread(__errno_location) ==10543== REPLACING libc(__GI___h_errno_location) with libpthread(__h_errno_location) ==10543== REPLACING libc(__GI___res_state) with libpthread(__res_state) ==10543== ==10543== TRANSLATE: 0x403F4CF0 redirected to 0x40387DC8 ==10543== Reading syms from /usr/X11R6/lib/modules/dri/r200_dri.so ==10543== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==10543== at 0x404BAD24: __GI___ioctl (in /lib/libc-2.3.2.so) ==10543== by 0x417C6B65: r200CreateScreen (r200_screen.c:185) ==10543== by 0x417C6E93: r200InitDriver (r200_screen.c:301) ==10543== by 0x416B2AF8: __driUtilCreateScreen (dri_util.c:1201) ==10543== Address 0xBFFFED94 is on thread 1's stack ==10543== ==10543== Use of uninitialised value of size 4 ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118) ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213) ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275) ==10543== by 0x4172D95A: _math_init (m_xform.c:218) ==10543== ==10543== Invalid read of size 2 ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118) ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213) ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275) ==10543== by 0x4172D95A: _math_init (m_xform.c:218) ==10543== Address 0x6E is not stack'd, malloc'd or free'd Segmentation fault wilder:~$ |
|
From: Nicholas N. <nj...@ca...> - 2003-10-16 16:58:52
|
On Thu, 16 Oct 2003 aho...@es... wrote: > I get the following log and segfault when running glxgears (or any other > GL program it seems) with valgrind. My machine config is: [snip] > ==10543== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) > ==10543== at 0x404BAD24: __GI___ioctl (in /lib/libc-2.3.2.so) > ==10543== by 0x417C6B65: r200CreateScreen (r200_screen.c:185) > ==10543== by 0x417C6E93: r200InitDriver (r200_screen.c:301) > ==10543== by 0x416B2AF8: __driUtilCreateScreen (dri_util.c:1201) > ==10543== Address 0xBFFFED94 is on thread 1's stack > ==10543== > ==10543== Use of uninitialised value of size 4 > ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118) > ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213) > ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275) > ==10543== by 0x4172D95A: _math_init (m_xform.c:218) > ==10543== > ==10543== Invalid read of size 2 > ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118) > ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213) > ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275) > ==10543== by 0x4172D95A: _math_init (m_xform.c:218) > ==10543== Address 0x6E is not stack'd, malloc'd or free'd > Segmentation fault Strange. It looks like vg_hashtable.c is causing a FP exception, which glxgears is catching, or something like that. But line 213 of vg_hashtable.c is the closing brace of VG_(HT_destruct)(), and vg_hashtable.c doesn't contain and FP arithmetic. Hmm. N |
|
From: David E. <tw...@us...> - 2003-10-16 18:17:09
|
On Thu, 2003-10-16 at 18:58, Nicholas Nethercote wrote:
> On Thu, 16 Oct 2003 aho...@es... wrote:
>
> > I get the following log and segfault when running glxgears (or any other
> > GL program it seems) with valgrind. My machine config is:
>
> [snip]
>
> > ==10543== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s)
> > ==10543== at 0x404BAD24: __GI___ioctl (in /lib/libc-2.3.2.so)
> > ==10543== by 0x417C6B65: r200CreateScreen (r200_screen.c:185)
> > ==10543== by 0x417C6E93: r200InitDriver (r200_screen.c:301)
> > ==10543== by 0x416B2AF8: __driUtilCreateScreen (dri_util.c:1201)
> > ==10543== Address 0xBFFFED94 is on thread 1's stack
> > ==10543==
> > ==10543== Use of uninitialised value of size 4
> > ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118)
> > ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213)
> > ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275)
> > ==10543== by 0x4172D95A: _math_init (m_xform.c:218)
> > ==10543==
> > ==10543== Invalid read of size 2
> > ==10543== at 0x417A9D4A: sigfpe_handler (common_x86.c:118)
> > ==10543== by 0x4017EF2F: ??? (vg_hashtable.c:213)
> > ==10543== by 0x417A9F6B: _mesa_init_all_x86_transform_asm (common_x86.c:275)
> > ==10543== by 0x4172D95A: _math_init (m_xform.c:218)
> > ==10543== Address 0x6E is not stack'd, malloc'd or free'd
> > Segmentation fault
>
> Strange. It looks like vg_hashtable.c is causing a FP exception, which
> glxgears is catching, or something like that. But line 213 of
> vg_hashtable.c is the closing brace of VG_(HT_destruct)(), and
> vg_hashtable.c doesn't contain and FP arithmetic. Hmm.
It is probably a division by zero that causes the SIGFPE (Arithmetic
exception).
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: <aho...@es...> - 2003-10-16 18:24:18
|
It would seem that Nicholas Nethercote (nj...@ca...) said: > Strange. It looks like vg_hashtable.c is causing a FP exception, which > glxgears is catching, or something like that. But line 213 of > vg_hashtable.c is the closing brace of VG_(HT_destruct)(), and > vg_hashtable.c doesn't contain and FP arithmetic. Hmm. I believe libGL may be catching FP exceptions in order to do 3dnow/SSE detection. ah |
|
From: Patrick M. <un...@pa...> - 2003-10-16 19:16:00
|
The simple answer to this is that you cant valgrind something that interacts with hardware, and due to the way mesa is setup, it loads dri modules direc= tly, and interacts with hardware. Basically, you cant valgrind with hardware acceleration enabled. However, t= here is a neat trick to turn it off, though it gets way slow. At your command prompt, before running valgrind, run... export LIBGL_ALWAYS_INDIRECT=3Dyes =2E.. and it should work fine. I usually do that, in addition to... export LIBGL_DEBUG=3Dyes export MESA_DEBUG=3Dyes =2E.. to enable more debugging output. On 16-Oct-2003, aho...@es... wrote: > I get the following log and segfault when running glxgears (or any other > GL program it seems) with valgrind. My machine config is: >=20 > AMD XP 1900 > Radeon 9000 > RH 9 with DRI from cvs >=20 > Any suggestions where to start? Is there a convenient way to run gdb on= =20 > valgrind while still using the 'valgrind' wrapper script? >=20 > cheers, > aaron >=20 > wilder:~$ valgrind -v glxgears > =3D=3D10543=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for = x86-linux. > =3D=3D10543=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Sewar= d. > =3D=3D10543=3D=3D Using valgrind-20031012, a program supervision framewor= k for x86-linux. > =3D=3D10543=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Sewar= d. > =3D=3D10543=3D=3D Command line: > =3D=3D10543=3D=3D glxgears > =3D=3D10543=3D=3D Startup, with flags: > =3D=3D10543=3D=3D --suppressions=3D/home/aholtzma/lib/valgrind/default= =2Esupp > =3D=3D10543=3D=3D -v > =3D=3D10543=3D=3D Reading syms from /usr/X11R6/bin/glxgears > =3D=3D10543=3D=3D object doesn't have a symbol table > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading syms from /lib/ld-2.3.2.so > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading syms from /home/aholtzma/lib/valgrind/vgskin_me= mcheck.so > =3D=3D10543=3D=3D Reading syms from /home/aholtzma/lib/valgrind/valgrind.= so > =3D=3D10543=3D=3D Reading syms from /usr/X11R6/lib/libGL.so.1.2 > =3D=3D10543=3D=3D Reading syms from /usr/X11R6/lib/libXext.so.6.4 > =3D=3D10543=3D=3D object doesn't have a symbol table > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading syms from /usr/X11R6/lib/libX11.so.6.2 > =3D=3D10543=3D=3D object doesn't have a symbol table > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading syms from /home/aholtzma/lib/valgrind/libpthrea= d.so > =3D=3D10543=3D=3D Reading syms from /lib/libm-2.3.2.so > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading syms from /lib/libc-2.3.2.so > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading syms from /lib/libdl-2.3.2.so > =3D=3D10543=3D=3D object doesn't have any debug info > =3D=3D10543=3D=3D Reading suppressions file: /home/aholtzma/lib/valgrind/= default.supp > =3D=3D10543=3D=3D Estimated CPU clock rate is 1601 MHz > =3D=3D10543=3D=3D REPLACING libc(__GI___errno_location) with libpthread(_= _errno_location) > =3D=3D10543=3D=3D REPLACING libc(__GI___h_errno_location) with libpthread= (__h_errno_location) > =3D=3D10543=3D=3D REPLACING libc(__GI___res_state) with libpthread(__res_= state) > =3D=3D10543=3D=3D=20 > =3D=3D10543=3D=3D TRANSLATE: 0x403F4CF0 redirected to 0x40387DC8 > =3D=3D10543=3D=3D Reading syms from /usr/X11R6/lib/modules/dri/r200_dri.so > =3D=3D10543=3D=3D Syscall param ioctl(generic) contains uninitialised or = unaddressable byte(s) > =3D=3D10543=3D=3D at 0x404BAD24: __GI___ioctl (in /lib/libc-2.3.2.so) > =3D=3D10543=3D=3D by 0x417C6B65: r200CreateScreen (r200_screen.c:185) > =3D=3D10543=3D=3D by 0x417C6E93: r200InitDriver (r200_screen.c:301) > =3D=3D10543=3D=3D by 0x416B2AF8: __driUtilCreateScreen (dri_util.c:120= 1) > =3D=3D10543=3D=3D Address 0xBFFFED94 is on thread 1's stack > =3D=3D10543=3D=3D=20 > =3D=3D10543=3D=3D Use of uninitialised value of size 4 > =3D=3D10543=3D=3D at 0x417A9D4A: sigfpe_handler (common_x86.c:118) > =3D=3D10543=3D=3D by 0x4017EF2F: ??? (vg_hashtable.c:213) > =3D=3D10543=3D=3D by 0x417A9F6B: _mesa_init_all_x86_transform_asm (com= mon_x86.c:275) > =3D=3D10543=3D=3D by 0x4172D95A: _math_init (m_xform.c:218) > =3D=3D10543=3D=3D=20 > =3D=3D10543=3D=3D Invalid read of size 2 > =3D=3D10543=3D=3D at 0x417A9D4A: sigfpe_handler (common_x86.c:118) > =3D=3D10543=3D=3D by 0x4017EF2F: ??? (vg_hashtable.c:213) > =3D=3D10543=3D=3D by 0x417A9F6B: _mesa_init_all_x86_transform_asm (com= mon_x86.c:275) > =3D=3D10543=3D=3D by 0x4172D95A: _math_init (m_xform.c:218) > =3D=3D10543=3D=3D Address 0x6E is not stack'd, malloc'd or free'd > Segmentation fault > wilder:~$=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users --=20 Patrick "Diablo-D3" McFarland || un...@pa... "Computer games don't affect kids; I mean if Pac-Man affected us as kids, w= e'd=20 all be running around in darkened rooms, munching magic pills and listening= to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 |
|
From: <aho...@es...> - 2003-10-16 19:23:06
|
It would seem that Patrick McFarland (un...@pa...) said: > The simple answer to this is that you cant valgrind something that interacts > with hardware, and due to the way mesa is setup, it loads dri modules directly, > and interacts with hardware. Only the drm kernel module talks to the hardware (or that is my understanding anyways). Everything goes through ioctls and shared memory. > export LIBGL_ALWAYS_INDIRECT=yes > That defeats the purpose of running it on the direct rending code! :) cheers, aaron |