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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(4) |
2
|
3
(5) |
4
(7) |
5
(15) |
6
(11) |
|
7
(11) |
8
(3) |
9
(29) |
10
(2) |
11
(14) |
12
(10) |
13
(2) |
|
14
(4) |
15
(9) |
16
(4) |
17
|
18
|
19
|
20
|
|
21
|
22
|
23
(2) |
24
(14) |
25
(11) |
26
(3) |
27
(1) |
|
28
(4) |
29
(21) |
30
(12) |
|
|
|
|
|
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: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 08:37:24
|
Hi, > I am working on an application which has many modules...We have a build > command to do the build > > To compile and generate .o files, we use build command followed by our > filenames. > We cannot run it as ./executable-file... > > So how can I use valgrind... I'm not sure I understand. What do you expect valgrind to do for you? In order to use valgrind you need to build an executable first. It seems to me you have problems building your application, but this isn't related to valgrind, is it? -- 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: Kiran R <not...@ya...> - 2003-09-09 07:54:46
|
Hi All I am working on an application which has many modules...We have a build command to do the build To compile and generate .o files, we use build command followed by our filenames. We cannot run it as ./executable-file... So how can I use valgrind... Thanks for ur time Rgds Kiran Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote: Hi, > I want to include valgrid in my makefile. Can u tell me how I should > include special flags and how I should put it in my makefile There should be no need to include valgrind in your makefile. Why do you want to include valgrind in your makefile? -- Dimitri ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
|
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: 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:38:12
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> In message <106...@zo...>
> Waqar Mohsin <wm...@ci...> wrote:
>
> > disInstr: unhandled instruction bytes: 0xF 0x70 0xC0 0x88
> > Illegal instruction
> >
> > Can anyone please help me figure out what's going on ? Does the x86
> > emulator not support a certain instruction ?
>
> Exactly correct. There are a number of instructions that the emulator
> does not yet support. In this case it appears to be an SSE instruction
> which isn't implemented yet - valgrind's SSE support is only partial
> at the moment.
In fact I've just noticed that the CVS source does seem to have
support for this particular instruction, so you might want to upgrade
to a more recent version.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-09-09 07:36:57
|
In message <106...@zo...>
Waqar Mohsin <wm...@ci...> wrote:
> disInstr: unhandled instruction bytes: 0xF 0x70 0xC0 0x88
> Illegal instruction
>
> Can anyone please help me figure out what's going on ? Does the x86
> emulator not support a certain instruction ?
Exactly correct. There are a number of instructions that the emulator
does not yet support. In this case it appears to be an SSE instruction
which isn't implemented yet - valgrind's SSE support is only partial
at the moment.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
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:29:51
|
Hi, > I want to include valgrid in my makefile. Can u tell me how I should > include special flags and how I should put it in my makefile There should be no need to include valgrind in your makefile. Why do you want to include valgrind in your makefile? -- Dimitri |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-09-09 07:28:13
|
Hi, > I'm running Valgrind on mp4live, a program to capture, encode and > record/stream mpeg4 video (http://mpeg4ip.net). Here's the output: > [...] > Can anyone please help me figure out what's going on ? Does the x86 > emulator not support a certain instruction ? Indeed some instructions such as MMX or SSE are not supported: http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt -- 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: Paul L D. <pld...@pl...> - 2003-09-09 04:13:15
|
On Mon, 8 Sep 2003 20:56:11 -0700 (PDT) Kiran R <not...@ya...> wrote: > > Hi All > > I want to include valgrid in my makefile. Can u tell me how I should include special flags and how I should put it in > my makefile You don't actually include valgrind in your makefile as such. However, make sure that you have the '-g' option active in your compiles so that sufficient debugging information is left in the binary files for when you do valgrind them. Once you have your binary build, you only need to do : valgrind ./my-application And the rest will happen. ... or did I miss your need? -- Paul L Daniels http://www.pldaniels.com Linux/Unix systems Internet Development ICQ#103642862,AOL:pldsoftware,IRC:inflex irc.freenode.net A.B.N. 19 500 721 806 |
|
From: Kiran R <not...@ya...> - 2003-09-09 03:56:12
|
Hi All I want to include valgrid in my makefile. Can u tell me how I should include special flags and how I should put it in my makefile Thanks kiran --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
|
From: Waqar M. <wm...@ci...> - 2003-09-09 02:11:57
|
Hi, I'm running Valgrind on mp4live, a program to capture, encode and record/stream mpeg4 video (http://mpeg4ip.net). Here's the output: [wmohsin@zoneplate work]$ valgrind --skin=addrcheck ~/mpeg4ip/server/mp4live/.libs/mp4live ==14353== Addrcheck, a fine-grained address checker for x86-linux. ==14353== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==14353== Using valgrind-20030725, a program supervision framework for x86-linux. ==14353== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==14353== Estimated CPU clock rate is 1615 MHz ==14353== For more details, rerun with: -v ==14353== 18:48:55.366-mp4live-7: audio device /dev/dsp doesn't support sampling rate 7350 18:48:55.402-mp4live-7: audio device /dev/dsp doesn't support sampling rate 64000 18:48:55.404-mp4live-7: audio device /dev/dsp doesn't support sampling rate 88200 18:48:55.405-mp4live-7: audio device /dev/dsp doesn't support sampling rate 96000 ==14353== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==14353== valgrind's libpthread.so: KLUDGED call to: sem_destroy disInstr: unhandled instruction bytes: 0xF 0x70 0xC0 0x88 Illegal instruction Can anyone please help me figure out what's going on ? Does the x86 emulator not support a certain instruction ? Thanks Waqar |
|
From: Paul L D. <pld...@pl...> - 2003-09-09 02:11:49
|
> Well, it does (or should) return the same value that the non-valground > process does. Okay, point understood. Just had to check first to be sure ;-) > file (using a command line like "valgrind --logfile=tmp myprog") and then > check the file for zero size. Thanks - that was one of my 'second choices' - now working fine. Kind Regards. -- Paul L Daniels http://www.pldaniels.com Linux/Unix systems Internet Development ICQ#103642862,AOL:pldsoftware,IRC:inflex irc.freenode.net A.B.N. 19 500 721 806 |
|
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: Nicholas N. <nj...@ca...> - 2003-09-08 07:23:14
|
On Mon, 8 Sep 2003, Paul L Daniels wrote: > Is there a way to get valgrind to exit a non-zero return code if it > finds errors in the grind process? > > So far I've noticed that it essentially always returns '0' if valgrind > itself didn't fail. Well, it does (or should) return the same value that the non-valground process does. > I want to do this so that I can run valgrind in a shell script which I > currently use to validate my program (using ~5000 > data set tests ) - and have the shell script halt if valgrind finds a > problem while running one of the tests. If the valground process returned non-zero, how could you tell if it was because Valgrind found errors, or because the process returned non-zero? An alternative solution is to run valgrind with -q, send the output to a file (using a command line like "valgrind --logfile=tmp myprog") and then check the file for zero size. N |
|
From: Derrick K.
|
Hi,
I've been getting errors like:
==28584== Thread 226:
==28584== Invalid write of size 4
==28584== at 0x8050749: findEqualFit (sched_struct.c:3143)
==28584== by 0x65B68DFB: ???
==28584== Address 0x64BF0BE8 is just below %esp. Possibly a bug in
GCC/G++
==28584== v 2.96 or 3.0.X. To suppress, use:
--workaround-gcc296-bugs=yes
and
==3112== Thread 226:
==3112== Invalid read of size 8
==3112== at 0x804DC2A: isResourceNotTooSlow (sched_struct.c:1908)
==3112== by 0x804D916: areJobResSuitable (sched_struct.c:1842)
==3112== Address 0x676973A3 is not stack'd, malloc'd or free'd.
The documentation suggests that this is possibly due to gcc producing
invalid code, and suggests using gcc 2.9.3, where this bug is fixed. Is
there any version of gcc >= 3.0 where this bug has been fixed?
Thanks.
|
|
From: Paul L D. <pld...@pl...> - 2003-09-08 00:45:37
|
Is there a way to get valgrind to exit a non-zero return code if it finds errors in the grind process? So far I've noticed that it essentially always returns '0' if valgrind itself didn't fail. I've looked at the valgrind help output - and I've tried searching the online email archives (which seem to be broken a bit, I keep getting 'Forum not found' when I try to move to the next page). I want to do this so that I can run valgrind in a shell script which I currently use to validate my program (using ~5000 data set tests ) - and have the shell script halt if valgrind finds a problem while running one of the tests. Regards. -- Paul L Daniels http://www.pldaniels.com Linux/Unix systems Internet Development ICQ#103642862,AOL:pldsoftware,IRC:inflex irc.freenode.net A.B.N. 19 500 721 806 |
|
From: Olly B. <ol...@su...> - 2003-09-07 20:49:20
|
I just tried Massif. It seemed to work well, but I found myself wanting
to know in more detail how the time axis corresponded to the execution
of my program.
Maybe there should be a valgrind client request to tell Massif to
annotate the current time with a label, and then hp2ps could mark this
time with a vertical line and label on the plot? Then I could add
something like this to my code:
VALGRIND_MASSIF_MARK("func foo() entered")
And I could then see each time this was executed on the graph.
Cheers,
Olly
|
|
From: Dan K. <da...@ke...> - 2003-09-07 15:06:56
|
Greg Hosler wrote: > On 07-Sep-2003 Dan Kegel wrote: >>Steve G wrote: >>>>If I were you, I'd install a fresh copy of the latest >>>>gnu make just to see if that made a difference. >>> >>>I wouldn't. If you install a tarball over an rpm, you might get >>>some of the directories wrong and then you have files all over >>>the place that aren't tracked by rpm. >> >>Yes, that would be messy. However, if you install the new >>make in /usr/local, there's no conflict, as it turns out. >>And /usr/local is the default install destination, so it's >>fairly safe. > > As far as I am aware, *no* distribution, has *ever* installed make, or any other > major utility (or minor, for that matter) into /usr/local. That's right; that's why it's safe to install a 'make' compiled from sources into /usr/local. When you run 'configure' on the make sources, you'll see that the default installation path is /usr/local, so it's quite safe to build from sources if you just use the defaults; it's can't conflict with your system's make. Since two people seem to have misinterpreted what I wrote, here are the steps I'm suggesting: ------------- wget http://ftp.gnu.org/pub/gnu/make/make-3.80.tar.bz2 tar -xjvf make-3.80.tar.bz2 cd make-3.80 ./configure make su -c "make install" -------- This will install make to /usr/local; I just did it, and verified that's where it goes. You can then use the new make instead of the system make by putting /usr/local/bin in front of your PATH: PATH=/usr/local/bin:$PATH And voila, you're trying out make-3.80 without affecting your system's copy of make or its data files. You can revert to the system make just by setting your PATH back. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Greg H. <gr...@ho...> - 2003-09-07 13:57:56
|
On 07-Sep-2003 Dan Kegel wrote: > Steve G wrote: >>>If I were you, I'd install a fresh copy of the latest >>>gnu make just to see if that made a difference. >> >> >> I wouldn't. If you install a tarball over an rpm, you might get >> some of the directories wrong and then you have files all over >> the place that aren't tracked by rpm. > > Yes, that would be messy. However, if you install the new > make in /usr/local, there's no conflict, as it turns out. > And /usr/local is the default install destination, so it's > fairly safe. As far as I am aware, *no* distribution, has *ever* installed make, or any other major utility (or minor, for that matter) into /usr/local. best rgds, -Greg +---------------------------------------------------------------------+ You can release software that's good, software that's inexpensive, or software that's available on time. You can usually release software that has 2 of these 3 attributes -- but not all 3. | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
|
From: Steve G <lin...@ya...> - 2003-09-07 11:45:51
|
>However, if you install the new make in /usr/local, there's >no conflict, as it turns out. And /usr/local is the default >install destination rpm -ql make You will see nothing that goes into /usr/local. This is just the kind of accident that makes a mess out of your system. Try building the srpm from rawhide and install the resulting binary package. Its a safer course of action and slightly newer than RH 9's. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Benjamin L. <ben...@us...> - 2003-09-07 08:37:50
|
Oh... whoah... my bad, I read you email incorrectly. I didn't notice
the 'i' and 'j'. Please ignore my previous email.
Please see comments inserted below...
On Sunday, 2003-09-07 at 05:58:11 PM, Benjamin Lee scribbled:
*snip*
>
> On Sunday, 2003-09-07 at 01:54:19 PM, Gong Cheng scribbled:
> > I have a wired bug
> >
> > the code is like this
> >
> >
> > printf("%d",i);
> > free(j);
> > printf("%d",i);
> >
Can you explain what your 'i' variable has to do with 'j'?
> > if we suppose i =1 ,the result should be
> > 1
> > 1
> > but in reality, the result is
> > 1
> > 0
> >
> > The interesting thing is that if I use valgrind to run the program,
> > the result turn back to
> > 1
> > 1
> >
> > anybody know what's the difference between normal free and the free in
> > valgrind?
> >
> > Thanks a lot!
> >
> > Gong
> >
>
--
Benjamin Lee
Melbourne, Australia "Always real." http://www.realthought.net/
__________________________________________________________________________
What's another word for "thesaurus"?
-- Steven Wright
|