You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(8) |
2
(1) |
3
(3) |
4
(3) |
|
5
(2) |
6
(7) |
7
(1) |
8
(9) |
9
(7) |
10
(9) |
11
(2) |
|
12
(5) |
13
(8) |
14
(19) |
15
(8) |
16
(25) |
17
(9) |
18
(6) |
|
19
(11) |
20
(2) |
21
(10) |
22
(13) |
23
(7) |
24
(6) |
25
(3) |
|
26
|
27
(2) |
28
(1) |
29
(4) |
30
(7) |
31
(5) |
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-18 13:53:57
|
On Sat, 18 Oct 2003, Joerg Walter wrote: > when running one of my regression tests built with ICC 7.1 under the newly > released valgrind I see the following assertion failure: > > Memcheck: mc_translate.c:1108 (memcheck_instrument): Assertion `u_in->size > == 4 || u_in->size == 16' failed. It's a bug, change the line to this: sk_assert(u_in->size == 4 || u_in->size == 8 || u_in->size == 16); I've committed the change. Thanks for the report. N |
|
From: <jhr...@t-...> - 2003-10-18 12:41:35
|
Hello, when running one of my regression tests built with ICC 7.1 under the newly released valgrind I see the following assertion failure: ---------- ==6555== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==6555== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==6555== Using valgrind-20031012, a program supervision framework for x86-linux. ==6555== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==6555== Estimated CPU clock rate is 1720 MHz ==6555== For more details, rerun with: -v ==6555== test_vector double, unbounded_array v1 = v2 = [3](1,2,3) v1.assign_temporary (v2) = [3](1,2,3) v1.swap (v2) = [3](1,2,3) [3](1,2,3) - v1 = [3](-1,-2,-3) conj (v1) = [3](1,2,3) v1 + v2 = [3](2,4,6) v1 - v2 = [3](0,0,0) element_prod (v1, v2) = [3](1,4,9) 1. * v1 = [3](1,2,3) N * v1 = [3](3,6,9) v1 * 1. = [3](1,2,3) v1 * N = [3](3,6,9) v2 += v1 = [3](2,4,6) v2 -= v1 = [3](1,2,3) v1 *= 1. = [3](1,2,3) v1 *= N = [3](3,6,9) sum (v1) = 6 norm_1 (v1) = 6 Memcheck: mc_translate.c:1108 (memcheck_instrument): Assertion `u_in->size == 4 || u_in->size == 16' failed. sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==6555== at 0x804A5B8: (within /usr/local/lib/boost_dev/boost/libs/numeric/ublas/test1/bin/test1/intel-linu x/release/runtime-link-dynamic/test1) ==6555== by 0x8067622: (within /usr/local/lib/boost_dev/boost/libs/numeric/ublas/test1/bin/test1/intel-linu x/release/runtime-link-dynamic/test1) ==6555== by 0x804A2AA: (within /usr/local/lib/boost_dev/boost/libs/numeric/ublas/test1/bin/test1/intel-linu x/release/runtime-link-dynamic/test1) ==6555== by 0x804A1F8: (within /usr/local/lib/boost_dev/boost/libs/numeric/ublas/test1/bin/test1/intel-linu x/release/runtime-link-dynamic/test1) 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. ---------- Thanks for any advice, Joerg P.S.: this is *not* a regression, as far as I can tell. P.P.S.: Running the test under SuSE 7.3, but this should be irrelevant. P.P.P.S.: Many thanks for improving the SSE support! |
|
From: Alan S. <al...@me...> - 2003-10-17 23:16:35
|
Paul, Aaron, Thanks much for the responses. I now have glxgears running, but it generates the same stream of errors (eg, 3000+ errors). However, using the methods you described I have generated some suppression rules (the ability to apply both --suppress=file and --generate-suppress=yes simultaneously was *very* helpful) specific to libGL which reveal bugs in the non-GL routines; exactly what I was hoping to do . Perhaps this problem (a plethora of errors from libGL in NV drivers) should be mentioned in the manual or a FAQ with a pointer to the manual for suppression of errors (the workaround). BTW, I'm not very familiar with the theory underlying the instrumentation of code, but I appreciate the way that valgrind operates directly on the binary without requiring special compilation. IMHO, this process is far more preferable than, for example, using PurifyPlus which requires configuration so that the tool can replicate all the functions and configurations of the Makefile. Regards, --Alan Paul A. Clarke wrote: >Alan, > >__GL_FORCE_GENERIC_CPU=1 is only intended to keep the library from using >special instructions which may not yet be supported by valgrind (thus >keeping valgrind from working *at all*). > >The errors you see I see as well (although I'm on 4363), and guess that >they are "don't care" cases in the NV libs. > >The best I was able to do was to tell Valgrind to suppress the errors >(run with --gen-suppressions=yes, save generated suppressions to a file, >say $HOME/.valgrind/NV.suppress, then run again with >--suppressions=$HOME/.valgrind/NV.suppress). > >Regards, >Paul Clarke > >On Fri, 2003-10-17 at 10:54, Alan wrote: > > >>I get tons of errors from the libGL routines as expected, however >>setting __GL_FORCE_GENERIC_CPU=1 doesn't seem to help at all! >> >>I would test on something more standardized like "glxgears", but >>unfortunately it isn't in my distribution (perish the thought of >>upgrading X and all its dependencies from 4.1.0 to current!) and I >>haven't seen a standalone package to build it from. >> >>At the end of this email is the output from a valgrind run (with some >>extraneous stuff clipped). >> >>My questions: >>1) If the problem is related to the hardware-based libGL calls from the >>NV drivers, is there a simple way to turn off hardware acceleration so >>that valgrind would run without errors? >>2) Is this related to special CPU instructions? Why doesn't >>__GL_FORCE_GENERIC_CPU=1 seem to do anything? >>3) Is there a quick/easy way for me to build glxgears to make testing >>valgrind on GL hardware a bit more uniform (eg, eliminates behavior >>specific to my image processing program)? >> >>Thanks for any insight into this problem and also for the all the effort >>on valgrind. >> >> --Alan >> >> >>BTW, for the records, I don't have the "tls" directory tree. The only >>files are: >> >>[root@ripple root]# locate libGL. >>/usr/lib/libGL.so >>/usr/lib/libGL.so.1.0.4496 >>/usr/lib/libGL.so.1 >> >>valgrind output follows: >> >> >> >>[astein@ripple ~]$ valgrind display 0 0 0 1 >>==2551== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. >>==2551== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. >>==2551== Using valgrind-20031012, a program supervision framework for >>x86-linux.==2551== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. >>==2551== Warning: set address range perms: large range 130834432, a 0, v 0 >>==2551== Estimated CPU clock rate is 996 MHz >>==2551== For more details, rerun with: -v >>==2551== >>==2551== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains >>uninitialised or unaddressable byte(s) >>==2551== at 0x404F18D8: (within /usr/lib/libGL.so.1.0.4496) >>==2551== Address 0xBFFFF4C0 is on thread 1's stack >>==2551== >>... >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x40511649: NvRmAllocRoot (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x4050BC9E: (within /usr/lib/libGL.so.1.0.4496) >>==2551== Address 0xBFFFF120 is on thread 1's stack >>==2551== Warning: set address range perms: large range 134217728, a 0, v 0 >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x4050BDCA: (within /usr/lib/libGL.so.1.0.4496) >>==2551== Address 0xBFFFF118 is on thread 1's stack >>==2551== >>... >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x40BD5FBE: (within /usr/lib/libGLcore.so.1.0.4496) >>==2551== Address 0xBFFFF0CC is on thread 1's stack >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x40BD600A: (within /usr/lib/libGLcore.so.1.0.4496) >>==2551== Address 0xBFFFF0CC is on thread 1's stack >>... >>==2551== >>==2551== Syscall param ioctl(generic) contains uninitialised or >>unaddressable byte(s) >>==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) >>==2551== by 0x405121B7: NvRmFree (in /usr/lib/libGL.so.1.0.4496) >>==2551== by 0x40BC4300: __nvsym15143 (in usr/lib/libGLcore.so.1.0.4496) >>==2551== Address 0xBFFFF1D0 is on thread 1's stack >>==2551== >>==2551== ERROR SUMMARY: 3055 errors from 96 contexts (suppressed: 58 from 5) >>==2551== malloc/free: in use at exit: 2340679 bytes in 4405 blocks. >>==2551== malloc/free: 8945 allocs, 4540 frees, 4917877 bytes allocated. >>==2551== For a detailed leak analysis, rerun with: --leak-check=yes >>==2551== For counts of detected errors, rerun with: -v >>[astein@ripple ~]$ >> >> >> >> >> >> >> >>------------------------------------------------------- >>This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo >>The Event For Linux Datacenter Solutions & Strategies in The Enterprise >>Linux in the Boardroom; in the Front Office; & in the Server Room >>http://www.enterpriselinuxforum.com >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > > > > > |
|
From: Jeremy F. <je...@go...> - 2003-10-17 21:51:59
|
On Fri, 2003-10-17 at 08:54, Alan wrote: > My questions: > 1) If the problem is related to the hardware-based libGL calls from the > NV drivers, is there a simple way to turn off hardware acceleration so > that valgrind would run without errors? > 2) Is this related to special CPU instructions? Why doesn't > __GL_FORCE_GENERIC_CPU=1 seem to do anything? No, because it isn't crashing with an illegal instruction. My guess is that the nv driver uses lots of ioctls, and Valgrind doesn't know what they do. See if --weird-hacks=lax-ioctls does anything useful for you. It may not help if the driver uses ioctls to initialize memory which is pointed to by the ioctl structure, rather than the structure itself. Also, if you're using direct rendering, there's a chunk of memory which is shared with the card itself, which Valgrind doesn't know is special (though it might be treated like any other mmaped memory). J |
|
From: Paul A. C. <pa...@us...> - 2003-10-17 19:25:17
|
Alan, __GL_FORCE_GENERIC_CPU=1 is only intended to keep the library from using special instructions which may not yet be supported by valgrind (thus keeping valgrind from working *at all*). The errors you see I see as well (although I'm on 4363), and guess that they are "don't care" cases in the NV libs. The best I was able to do was to tell Valgrind to suppress the errors (run with --gen-suppressions=yes, save generated suppressions to a file, say $HOME/.valgrind/NV.suppress, then run again with --suppressions=$HOME/.valgrind/NV.suppress). Regards, Paul Clarke On Fri, 2003-10-17 at 10:54, Alan wrote: > I get tons of errors from the libGL routines as expected, however > setting __GL_FORCE_GENERIC_CPU=1 doesn't seem to help at all! > > I would test on something more standardized like "glxgears", but > unfortunately it isn't in my distribution (perish the thought of > upgrading X and all its dependencies from 4.1.0 to current!) and I > haven't seen a standalone package to build it from. > > At the end of this email is the output from a valgrind run (with some > extraneous stuff clipped). > > My questions: > 1) If the problem is related to the hardware-based libGL calls from the > NV drivers, is there a simple way to turn off hardware acceleration so > that valgrind would run without errors? > 2) Is this related to special CPU instructions? Why doesn't > __GL_FORCE_GENERIC_CPU=1 seem to do anything? > 3) Is there a quick/easy way for me to build glxgears to make testing > valgrind on GL hardware a bit more uniform (eg, eliminates behavior > specific to my image processing program)? > > Thanks for any insight into this problem and also for the all the effort > on valgrind. > > --Alan > > > BTW, for the records, I don't have the "tls" directory tree. The only > files are: > > [root@ripple root]# locate libGL. > /usr/lib/libGL.so > /usr/lib/libGL.so.1.0.4496 > /usr/lib/libGL.so.1 > > valgrind output follows: > > > > [astein@ripple ~]$ valgrind display 0 0 0 1 > ==2551== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==2551== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==2551== Using valgrind-20031012, a program supervision framework for > x86-linux.==2551== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==2551== Warning: set address range perms: large range 130834432, a 0, v 0 > ==2551== Estimated CPU clock rate is 996 MHz > ==2551== For more details, rerun with: -v > ==2551== > ==2551== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains > uninitialised or unaddressable byte(s) > ==2551== at 0x404F18D8: (within /usr/lib/libGL.so.1.0.4496) > ==2551== Address 0xBFFFF4C0 is on thread 1's stack > ==2551== > ... > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x40511649: NvRmAllocRoot (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x4050BC9E: (within /usr/lib/libGL.so.1.0.4496) > ==2551== Address 0xBFFFF120 is on thread 1's stack > ==2551== Warning: set address range perms: large range 134217728, a 0, v 0 > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x4050BDCA: (within /usr/lib/libGL.so.1.0.4496) > ==2551== Address 0xBFFFF118 is on thread 1's stack > ==2551== > ... > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x40BD5FBE: (within /usr/lib/libGLcore.so.1.0.4496) > ==2551== Address 0xBFFFF0CC is on thread 1's stack > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x40BD600A: (within /usr/lib/libGLcore.so.1.0.4496) > ==2551== Address 0xBFFFF0CC is on thread 1's stack > ... > ==2551== > ==2551== Syscall param ioctl(generic) contains uninitialised or > unaddressable byte(s) > ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) > ==2551== by 0x405121B7: NvRmFree (in /usr/lib/libGL.so.1.0.4496) > ==2551== by 0x40BC4300: __nvsym15143 (in usr/lib/libGLcore.so.1.0.4496) > ==2551== Address 0xBFFFF1D0 is on thread 1's stack > ==2551== > ==2551== ERROR SUMMARY: 3055 errors from 96 contexts (suppressed: 58 from 5) > ==2551== malloc/free: in use at exit: 2340679 bytes in 4405 blocks. > ==2551== malloc/free: 8945 allocs, 4540 frees, 4917877 bytes allocated. > ==2551== For a detailed leak analysis, rerun with: --leak-check=yes > ==2551== For counts of detected errors, rerun with: -v > [astein@ripple ~]$ > > > > > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo > The Event For Linux Datacenter Solutions & Strategies in The Enterprise > Linux in the Boardroom; in the Front Office; & in the Server Room > http://www.enterpriselinuxforum.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: <aho...@es...> - 2003-10-17 16:05:58
|
It would seem that Alan (al...@me...) said: > I would test on something more standardized like "glxgears", but > unfortunately it isn't in my distribution (perish the thought of > upgrading X and all its dependencies from 4.1.0 to current!) and I > haven't seen a standalone package to build it from. > You can get it here: http://cvs.sourceforge.net/viewcvs.py/*checkout*/mesa3d/Mesa/xdemos/glxgears.c cheers, aaron |
|
From: Alan <al...@me...> - 2003-10-17 15:55:15
|
Hi, I'm trying to use valgrind on a custom image processing program on a laptop with RH 7.2, and NVidia GeForce2Go chipset, and NV's most recent drivers (4496). I get tons of errors from the libGL routines as expected, however setting __GL_FORCE_GENERIC_CPU=1 doesn't seem to help at all! I would test on something more standardized like "glxgears", but unfortunately it isn't in my distribution (perish the thought of upgrading X and all its dependencies from 4.1.0 to current!) and I haven't seen a standalone package to build it from. At the end of this email is the output from a valgrind run (with some extraneous stuff clipped). My questions: 1) If the problem is related to the hardware-based libGL calls from the NV drivers, is there a simple way to turn off hardware acceleration so that valgrind would run without errors? 2) Is this related to special CPU instructions? Why doesn't __GL_FORCE_GENERIC_CPU=1 seem to do anything? 3) Is there a quick/easy way for me to build glxgears to make testing valgrind on GL hardware a bit more uniform (eg, eliminates behavior specific to my image processing program)? Thanks for any insight into this problem and also for the all the effort on valgrind. --Alan BTW, for the records, I don't have the "tls" directory tree. The only files are: [root@ripple root]# locate libGL. /usr/lib/libGL.so /usr/lib/libGL.so.1.0.4496 /usr/lib/libGL.so.1 valgrind output follows: [astein@ripple ~]$ valgrind display 0 0 0 1 ==2551== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==2551== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==2551== Using valgrind-20031012, a program supervision framework for x86-linux.==2551== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==2551== Warning: set address range perms: large range 130834432, a 0, v 0 ==2551== Estimated CPU clock rate is 996 MHz ==2551== For more details, rerun with: -v ==2551== ==2551== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains uninitialised or unaddressable byte(s) ==2551== at 0x404F18D8: (within /usr/lib/libGL.so.1.0.4496) ==2551== Address 0xBFFFF4C0 is on thread 1's stack ==2551== ... ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x40511649: NvRmAllocRoot (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x4050BC9E: (within /usr/lib/libGL.so.1.0.4496) ==2551== Address 0xBFFFF120 is on thread 1's stack ==2551== Warning: set address range perms: large range 134217728, a 0, v 0 ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x4050BDCA: (within /usr/lib/libGL.so.1.0.4496) ==2551== Address 0xBFFFF118 is on thread 1's stack ==2551== ... ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x40BD5FBE: (within /usr/lib/libGLcore.so.1.0.4496) ==2551== Address 0xBFFFF0CC is on thread 1's stack ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405129E7: NvRmConfigGet (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x40BD600A: (within /usr/lib/libGLcore.so.1.0.4496) ==2551== Address 0xBFFFF0CC is on thread 1's stack ... ==2551== ==2551== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==2551== at 0x408AAAC4: __ioctl (in /lib/i686/libc-2.2.4.so) ==2551== by 0x405121B7: NvRmFree (in /usr/lib/libGL.so.1.0.4496) ==2551== by 0x40BC4300: __nvsym15143 (in usr/lib/libGLcore.so.1.0.4496) ==2551== Address 0xBFFFF1D0 is on thread 1's stack ==2551== ==2551== ERROR SUMMARY: 3055 errors from 96 contexts (suppressed: 58 from 5) ==2551== malloc/free: in use at exit: 2340679 bytes in 4405 blocks. ==2551== malloc/free: 8945 allocs, 4540 frees, 4917877 bytes allocated. ==2551== For a detailed leak analysis, rerun with: --leak-check=yes ==2551== For counts of detected errors, rerun with: -v [astein@ripple ~]$ |
|
From: Peter S. <Pet...@gm...> - 2003-10-17 14:40:45
|
> > We know about the problem, but there is no fix yet. As we play some
nasty
> > tricks with the stack, it is "okay" that gdb feels confused. It worked
> > before because gdb wasn't able to correctly disassemble the method in
older
> versions. Now it can, and we cannot trick it into unwinding the stack
> > correctly anymore. Another solution has to be found.
>
> Ok, it was easier than I thought, and I committed this patch, which makes
it
> work for me. let me know if you experience problems.
[snip patch]
The Patch worked partly, gdb is now able to show the stacktrace, plus the
one
extra frame with invalid data (see the following gdb trace of the example
programm given on the gdb-bug database).
The other problem was, with your patch on valgrind-20031012I needed the
latet snapshot release of the
gnu-assamler gas, because the installed version on Suse-8.2 (GNU assembler
2.13.90.0.18 20030121)
did not have the CFI support (even not the new 2.14 release).
~/valgrind_test> valgrind --gdb-attach=yes ./t
==3945== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==3945== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==3945== Using valgrind-20031012, a program supervision framework for
x86-linux.
==3945== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==3945== Estimated CPU clock rate is 3119 MHz
==3945== For more details, rerun with: -v
==3945==
==3945== Invalid read of size 1
==3945== at 0x8048363: coin (t.c:4)
==3945== by 0x8048378: coincoin (t.c:7)
==3945== by 0x804838F: main (t.c:9)
==3945== by 0x4025C8AD: __libc_start_main (in /lib/libc.so.6)
==3945== Address 0x411BC029 is 0 bytes after a block of size 5 alloc'd
==3945== at 0x400299D8: malloc (vg_replace_malloc.c:153)
==3945== by 0x402C266F: __GI___strdup (in /lib/libc.so.6)
==3945== by 0x8048356: coin (t.c:3)
==3945== by 0x8048378: coincoin (t.c:7)
==3945==
==3945== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==3945== starting GDB with cmd: /usr/bin/gdb -nw /proc/3945/exe 3945
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Attaching to program: /proc/3945/exe, process 3945
Reading symbols from /usr/local/lib/valgrind/vgskin_memcheck.so...done.
Loaded symbols for /usr/local/lib/valgrind/vgskin_memcheck.so
Reading symbols from /usr/local/lib/valgrind/valgrind.so...done.
Loaded symbols for /usr/local/lib/valgrind/valgrind.so
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
vg_do_syscall3 (syscallno=4294966784, arg1=3948, arg2=0, arg3=0)
at vg_mylibc.c:92
92 }
(gdb) bt
#0 vg_do_syscall3 (syscallno=4294966784, arg1=3948, arg2=0, arg3=0)
at vg_mylibc.c:92
#1 0x4018ba75 in vgPlain_system (
cmd=0xbfffde70 "/usr/bin/gdb -nw /proc/3945/exe 3945") at
vg_mylibc.c:1277
#2 0x4018828d in vgPlain_start_GDB_whilst_on_client_stack () at
vg_main.c:1816
#3 0x4018e6f0 in vgPlain_swizzle_esp_then_start_GDB ()
from /usr/local/lib/valgrind/valgrind.so
#4 0x08048363 in coin () at t.c:4
#5 0x08048363 in coin () at t.c:4
#6 0x08048379 in coincoin () at t.c:7
#7 0x08048390 in main () at t.c:9
(gdb) frame 5
#5 0x08048363 in coin () at t.c:4
4 int i = s[5];
(gdb) p s
$1 = 0x411bc024 "plop"
(gdb) frame 4
#4 0x08048363 in coin () at t.c:4
4 int i = s[5];
(gdb) p s
$2 = 0x4018e6f0
"\213-º¡\035@\213%¾¡\035@aÃ\220\220\203ì\024\211\\$\020\213\\$\0
30\205Ûu$ÇD$\ff\b\035@ÇD$\b\205"
(gdb)
--
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
Jetzt kostenlos anmelden unter http://www.gmx.net
+++ GMX - die erste Adresse für Mail, Message, More! +++
|
|
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: Olly B. <ol...@su...> - 2003-10-17 10:10:01
|
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: Michele I. <mic...@ne...> - 2003-10-17 09:22:16
|
Hello all, valgrind report over 30000 errors on my application !!! There are zillions of "KLUDGE call to: sem_destroy". Are these messages errors ? Please, help. Thank you. -- Michele Iacobellis <mic...@ne...> NEXOTECH Srl |
|
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: <sa...@lu...> - 2003-10-16 22:18:23
|
Hi, What does this error mean? Memcheck: the `impossible' happened: add_MAC_chunk: shadow area is accessible Basic block ctr is approximately 111850000 Is it clear indication that something is wrong in my application or is it i= ndication that I=92m doing something that is not fully supported by Valgrin= d tool? My application seems to be stable and I have not noticed any leakag= e using other tools. The application is using commercial in memory database= , which is using shared memory to store the data. When I comment out the pa= rts that are using the IMDB from the application I don=92t get the error.= =20 Has anyone else run into this kind of problem? I can submit more details if= some one wants to study the issue. As a temporary solution I simply commented out "paranoid" check generating = the error message (lines 146 - 148 from memcheck/mac_malloc_wrappers.c file= ), at least I can now get leak summary when application exits. BR, Sami ............................................................ Maksuton s=E4hk=F6posti aina k=E4yt=F6ss=E4 http://luukku.com Kuukausimaksuton MTV3 Internet-liittym=E4 www.mtv3.fi/liittyma |
|
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: 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: 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: <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 |
|
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: 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: <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: 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: Olly B. <ol...@su...> - 2003-10-16 17:22:55
|
On Thu, Oct 16, 2003 at 06:44:50PM +0000, Philippe Elie wrote: > I think http://developer.kde.org/~sewardj/ "Interesting variants" > should list the existing skin. Most of the existing can't be found > through google. Annelid search don't find your skin in the first 50 > hit (15,900), Annelid and debugger don't find it at all. Another useful link for the valgrind webpage would be to the valgrind CVS page on sourceforge - otherwise it's mightily hard to find unless you already know it's hosted there. My suggestion would be to make "CVS" in "you are welcome to build it from CVS" a link to here: http://sourceforge.net/cvs/?group_id=46268 Also the "Home Page" link on: http://sourceforge.net/projects/valgrind Takes you to the empty page at http://valgrind.sourceforge.net/ but it probably ought to link to http://developer.kde.org/~sewardj/ I'm not sure how you change this on sourceforge - I'm fairly sure I've done it before, but I couldn't see where on the admin pages it is. Cheers, Olly |
|
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: 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: Josef W. <Jos...@gm...> - 2003-10-16 16:49:14
|
Hi, On Thursday 16 October 2003 15:12, Steve G wrote: > >I'm looking at distributing crocus as an independent skin, > >like Josef W's Calltree. > > That's a shame unless its your personal preference. The main > valgrind homepage does not link to your homepage and a lot of > people might not be able to find it (or other skins for that > matter). It would be nice if there was a list of resources on the > main homepage that pointed to these other skins. I support this. > Then you have the problem of rolling a skin into whatever version > of valgrind is on your system. Sometimes its easy, sometimes > there's fixups. I think that developers will get the most benefit > if some of these newer skins were rolled in so that they are > getting more use. I really don't think that distribution is the issue here. This is the job of distributors. And if you install valgrind yourself, what's the issue of doing "./configure; make install" a second time for a skin package? If this seems to be too idealistic: It's working with my Calltree skin with V 1.9.6, V-20030725 and V-20031012 this way, and if there's no change in the skin interface major version number, it should do so for future V releases, too. Josef |