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: Nicholas N. <nj...@ca...> - 2003-09-15 09:45:39
|
On Sun, 7 Sep 2003, Geoff Alexander wrote:
> The attached change works fine for valgrind 1.9.6. I get
> ==1324== Warning: invalid file descriptor -1 in syscall read()
> ==1324== at 0x403CA224: __libc_read (in /lib/libc.so.6)
> ==1324== by 0x40378920: _IO_file_underflow@@GLIBC_2.1 (in /lib/libc.so.6)
> ==1324== by 0x40379CAA: _IO_default_uflow (in /lib/libc.so.6)
> ==1324== by 0x40379BA6: __uflow (in /lib/libc.so.6)
> ==1324== by 0x40362DC9: _IO_vfscanf (in /lib/libc.so.6)
> ==1324== by 0x40366C85: __vfscanf (in /lib/libc.so.6)
> ==1324== by 0x804CF6E: _ZN12gdaUtilities15SystemFunctions6fscanfEP8_IO_FILEPKcz (SystemFunctions.cpp:57)
> ==1324== by 0x8049ED0: main (TestSystemFunctions.cpp:152)
> ==1324== by 0x40327BAE: __libc_start_main (in /lib/libc.so.6)
> ==1324== by 0x8049460: (within /home/gdlxn/gdaUtilities/test/TestSystemFunctions)
> But when I make the change in valgrind 20030725, I get
> ==15191== Warning: invalid file descriptor -1 in syscall read()
> ==15191== at 0x0: ???
> Is there a way to get a valid trace in valgrind 20030725?
Try changing the VG_(pp_ExeContext)() call in the added code snippet to
this:
VG_(pp_ExeContext)( VG_(get_ExeContext)( tid ) );
> Also, is it possible to suppress invalid file descriptor warnings in
> valgrind? I tried using the --gen-suppressions option in valgrind
> 20030725, but no suppression was generated.
No, because those warnings aren't done "properly" through the error
handling system, because they tend to be pretty rare. The easiest answer
is to comment out the code.
As for why you want to suppress it... is there a good reason why you're
passing -1 as a file descriptor to read()?
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-15 09:40:03
|
On Sat, 6 Sep 2003, Evan Berggren Daniel wrote: > Is there a way to make valgrind not decide that the program has switched > stacks? I have a program that allocates a lot on the stack as main() > initializes, which causes valgrind to think the program has switched > stacks; this then causes spurious errors. I have since changed the > program to work around this, and valgrind is working fine, but it seems > there should be some sort of option for when you know the client program > won't switch stacks. If there is none, then count this as a feature > request :) The quick hacky way is to adjust the value of VG_PLAUSIBLE_STACK_SIZE in coregrind/vg_memory.c. N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-15 07:28:57
|
On Fri, 12 Sep 2003, Jorrit Tyberghein wrote: > > It seems there are two sort of problems with nVidia drivers: > > > > * They use MMX/SSE instructions which are not supported by valgrind. > > How hard would it be for valgrind to support MMX? Not very. It already supports (I think) all the MMX instructions and some/most of the SSE/SSE2 ones. The remaining SSE ones are being added slowly. N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-15 07:20:27
|
On Sun, 14 Sep 2003, Dan Kegel wrote: > I think it might be because I'm using --skin=addrcheck. I just updated the HEAD so they apply for Addrcheck too. > BTW --gen-suppressions=yes with --skin=addrcheck seems to > generate suppressions that are rejected by valgrind when you > try to use them; it doesn't like the adrcheck keyword for some reason. Can you give an example? I just tried and it worked ok for me. N |
|
From: Jorrit T. <Jor...@uz...> - 2003-09-15 06:50:52
|
Jorrit Tyberghein wrote: > > I got a crash inside the fglrx driver itself (the program without > valgrind doesn't > crash). I can give you more details later but at this moment I'm not > at my linux > machine. Ok, here is more information: Running valgrind with my program that uses the ATI drivers gives: ==3489== Warning: segment-override prefix encountered, but thread has no LDT ==3489== Warning: segment access: virtual addr 0 exceeds segment limit of 0 ==3489== ==3489== Invalid read of size 4 ==3489== at 0x43CA26F5: s14065 (in /usr/X11R6/lib/modules/dri/fglrx_dri.so) ==3489== Address 0x0 is not stack'd, malloc'd or free'd Segmentation fault The program runs fine outside valgrind. Greetings, |
|
From: Michael S. <ms...@xi...> - 2003-09-15 01:59:07
|
On Saturday 13 September 2003 01:54, b h wrote: > This one doesn't for, tho I have other daemons that do that I'm trying to > get working as well. I assume for those I just need to use the > --track-children=yes flag, right? > > More info - appears to be chown and setuid problem. Is this known? Valgrind relies on LD_PRELOAD to load itself into the executable at runtime. The linker ignores LD_PRELOAD on setuid binaries (neccesary, otherwise any user could make a setuid application run whatever code they wanted - obviously a bad thing with things setuid root). So you can't use valgrind on this application as-is. You'll have to un-setuid it, then run it directly as the appropriate user. Mike |
|
From: Dan K. <da...@ke...> - 2003-09-14 23:40:00
|
Dirk Mueller wrote: > we added suppressions for realpath, it seems for some reason they're not > completely working for you. > > If you can figure out what is wrong with them, please let me know. I think it might be because I'm using --skin=addrcheck. BTW --gen-suppressions=yes with --skin=addrcheck seems to generate suppressions that are rejected by valgrind when you try to use them; it doesn't like the adrcheck keyword for some reason. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Dirk M. <dm...@gm...> - 2003-09-14 21:10:09
|
On Sunday 14 September 2003 00:25, Dan Kegel wrote: > What gives? we added suppressions for realpath, it seems for some reason they're not completely working for you. If you can figure out what is wrong with them, please let me know. |
|
From: Dan K. <da...@ke...> - 2003-09-14 04:55:13
|
Saw this one while running OpenOffice, figured it might
be the old X bug Keith mentioned in the linked paper.
Not sure, but it seems like a good guess.
{
"Xlib does not zero out unused bytes in the protocol stream"; see http://keithp.com/~keithp/talks/usenix2003/html/net.html
Memcheck:Param
writev(vector[...])
fun:vgAllRoadsLeadToRome_writev
fun:__writev
obj:/usr/X11R6/lib/libX11.so.6.2
fun:_X11TransWritev
}
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
|
|
From: Robert W. <rj...@du...> - 2003-09-14 00:48:28
|
Hi Matthew, The new watchpoint patch is now available at: http://www.durables.org/software/valgrind/ To set watchpoints on the command line, use the following option: --watchpoint=3DWP If WP is a single number, watch that address only. If WP is of the form X-Y, watch the range of addresses from X to Y. If WP is of the form X+Y, watch the range of addresses from X to X+Y. X and Y can be decimal or hexadecimal numbers. Hex numbers are prefixed by 0x. You can specify as many watchpoints as you want. e.g.: valgrind --watchpoint=3D0xBFFFF400 ls This watches the single byte at 0xBFFFF400 valgrind --watchpoint=3D0xBFFFF400-0xBFFFF500 This watches the range from 0xBFFFF400 to 0xBFFFF500. valgrind --watchpoint=3D0xBFFFF500+256 This watches the 256 bytes starting at 0xBFFFF500 Watchpoints will be triggered if: * the watched addresses are read from or written to * the watched addresses go in to or out of scope on the stack * memory is allocated or freed over the watched addresses Let me know if you run into any problems with this. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Dan K. <da...@ke...> - 2003-09-13 22:00:39
|
When running latest? valgrind on openoffice, I see
a whole bunch of source/destination overlap errors
inside the glibc function realpath() (see below).
I looked at the code in glibc-2.3.2 for realpath(), and sure enough,
it has a path where it does a strcpy(x, x) for some reason. I wrote a
little test case for this:
main()
{
char buf[256];
char *p;
buf[0] = 0;
p = realpath("/doesnotexist", buf);
printf("p %p buf %s\n", p, buf);
}
When I prepend the source for realpath() to that fragment, and compile it
into my test, I get what I expect:
==12241== Source and destination overlap in strcpy(0xbfffdfd0, 0xbfffdfd0)
==12241== at 0x400226E7: strcpy (mac_replace_strmem.c:87)
==12241== by 0x8048ACF: __realpath (x.c:186)
==12241== by 0x8048B22: main (x.c:198)
==12241== by 0x4024C8C6: __libc_start_main (in /lib/libc-2.3.2.so)
p (nil) buf /doesnotexist
But when I use the copy of realpath() in red hat 9's glibc, my test
doesn't demonstrate the problem. This is odd, since it was on
that very red hat 9 system where I saw all those errors in realpath()
when running openoffice.
What gives?
- Dan
p.s. Here's the error summary from just starting up openoffice1.1.0rc4 with --skin=addrcheck:
4 errors in context 3 of 8:
Source and destination overlap in strcpy(0xbfffcc70, 0xbfffcc70)
at 0x40021277: strcpy (mac_replace_strmem.c:87)
by 0x414DBA4A: realpath@@GLIBC_2.3 (in /lib/libc-2.3.2.so)
by 0x414DBDE9: realpath@GLIBC_2.0 (in /lib/libc-2.3.2.so)
by 0x415F152E: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libpsp645li.so)
by 0x415F1A7C: psp::PrintFontManager::initialize(void*) (in /opt/OpenOffice.org1.1.0rc4-pre/program/libpsp645li.so)
by 0x415EC724: psp::PrintFontManager::get() (in /opt/OpenOffice.org1.1.0rc4-pre/program/libpsp645li.so)
...
5 errors in context 4 of 8:
Source and destination overlap in memcpy(0xbfffcc70, 0xbfffcc70, 53)
at 0x40021529: memcpy (mac_replace_strmem.c:95)
by 0x414DBBF9: realpath@@GLIBC_2.3 (in /lib/libc-2.3.2.so)
by 0x414DBDE9: realpath@GLIBC_2.0 (in /lib/libc-2.3.2.so)
by 0x415F152E: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libpsp645li.so)
by 0x415F1A7C: psp::PrintFontManager::initialize(void*) (in /opt/OpenOffice.org1.1.0rc4-pre/program/libpsp645li.so)
by 0x415EC724: psp::PrintFontManager::get() (in /opt/OpenOffice.org1.1.0rc4-pre/program/libpsp645li.so)
...
8 errors in context 5 of 8:
Source and destination overlap in memcpy(0x435cead0, 0x435cead0, 23)
at 0x40021529: memcpy (mac_replace_strmem.c:95)
by 0x414DBBF9: realpath@@GLIBC_2.3 (in /lib/libc-2.3.2.so)
by 0x414DBDE9: realpath@GLIBC_2.0 (in /lib/libc-2.3.2.so)
by 0x40DB3480: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
by 0x40DB3391: osl_openProfile (in /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
...
8 errors in context 6 of 8:
Source and destination overlap in strcpy(0xbfff8d50, 0xbfff8d50)
at 0x40021277: strcpy (mac_replace_strmem.c:87)
by 0x414DBA4A: realpath@@GLIBC_2.3 (in /lib/libc-2.3.2.so)
by 0x414DBDE9: realpath@GLIBC_2.0 (in /lib/libc-2.3.2.so)
by 0x40DBBD45: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
by 0x40DBBF52: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
by 0x40DBC19A: osl_getAbsoluteFileURL (in /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
...
25 errors in context 7 of 8:
Source and destination overlap in memcpy(0xbfffcfe0, 0xbfffcfe0, 52)
at 0x40021529: memcpy (mac_replace_strmem.c:95)
by 0x414DBBF9: realpath@@GLIBC_2.3 (in /lib/libc-2.3.2.so)
by 0x414DBDE9: realpath@GLIBC_2.0 (in /lib/libc-2.3.2.so)
by 0x40DBCF43: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
by 0x40DBD2EB: osl_getExecutableFile (in /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
...
236 errors in context 8 of 8:
Source and destination overlap in memcpy(0xbfff8e40, 0xbfff8e40, 2)
at 0x40021529: memcpy (mac_replace_strmem.c:95)
by 0x414DBBF9: realpath@@GLIBC_2.3 (in /lib/libc-2.3.2.so)
by 0x414DBDE9: realpath@GLIBC_2.0 (in /lib/libc-2.3.2.so)
by 0x40DBBD45: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
by 0x40DBBF52: (within /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
by 0x40DBC19A: osl_getAbsoluteFileURL (in /opt/OpenOffice.org1.1.0rc4-pre/program/libsal.so.3.1.0)
...
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-13 16:50:50
|
On Fri, 12 Sep 2003, Charles Coffing wrote:
> Using Valgrind 20030725. I did this simple test:
>
> #include <stdio.h>
> #include <valgrind.h>
> int main(void)
> {
> printf("running on valgrind? %d\n", RUNNING_ON_VALGRIND);
> return 0;
> }
>
> Strangely, it claims it's not running under Valgrind:
Hmm, it works for me. I'm afraid I don't know what might be wrong... if
it's compiling, it should work. Sorry to not be more help.
N
|
|
From: Charles C. <cco...@no...> - 2003-09-12 22:39:14
|
Using Valgrind 20030725. I did this simple test:
#include <stdio.h>
#include <valgrind.h>
int main(void)
{
printf("running on valgrind? %d\n", RUNNING_ON_VALGRIND);
return 0;
}
Strangely, it claims it's not running under Valgrind:
[ccoffing@ccoffing1 ccoffing]$ valgrind ./test
==9093== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==9093== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==9093== Using valgrind-20030725, a program supervision framework for
x86-linux.==9093== Copyright (C) 2000-2003, and GNU GPL'd, by Julian
Seward.
==9093== Estimated CPU clock rate is 498 MHz
==9093== For more details, rerun with: -v
==9093==
running on valgrind? 0
==9093==
==9093== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==9093== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9093== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==9093== For a detailed leak analysis, rerun with: --leak-check=yes
==9093== For counts of detected errors, rerun with: -v
Likewise, VALGRIND_MAKE_READABLE, VALGRIND_MAKE_WRITABLE, etc. don't
seem to do anything. I tried this earlier on a 1.9.x build, and it
didn't work there either.
What am I doing wrong?
Thanks,
Charles
|
|
From: b h <bhh...@ma...> - 2003-09-12 15:56:44
|
This one doesn't for, tho I have other daemons that do that I'm trying to get working as well. I assume for those I just need to use the --track-children=yes flag, right? More info - appears to be chown and setuid problem. Is this known? This is on a SuSE SLES8 system. thx.bri. pdoslinux:~ # file p p: setgid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped pdoslinux:~ # chown osseal:osseal p pdoslinux:~ # ls -l p -r-xr-sr-x 1 osseal osseal 61115 Sep 12 10:44 p* pdoslinux:~ # valgrind ./p AOSUT0407I Could not get the credential of the invoker: 0x35a6200e: AOSSS0014E PDOSD is not running (pd / oss) pdoslinux:~ # chown root:root p pdoslinux:~ # ls -l p -r-xr-sr-x 1 root root 61115 Sep 12 10:44 p* pdoslinux:~ # valgrind ./p ==24547== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==24547== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==24547== Using valgrind-20030725, a program supervision framework for x86-linux. ==24547== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==24547== Estimated CPU clock rate is 398 MHz ==24547== For more details, rerun with: -v ==24547== ==24547== Conditional jump or move depends on uninitialised value(s) ==24547== at 0x804945F: main (in /root/p) ==24547== by 0x403294A1: __libc_start_main (in /lib/libc.so.6) ==24547== by 0x8048CB0: (within /root/p) AOSUT0407I Could not get the credential of the invoker: 0x35a6200e: AOSSS0014E PDOSD is not running (pd / oss) ==24547== ==24547== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 5 from 2) ==24547== malloc/free: in use at exit: 14224 bytes in 73 blocks. ==24547== malloc/free: 188 allocs, 115 frees, 44197 bytes allocated. ==24547== For a detailed leak analysis, rerun with: --leak-check=yes ==24547== For counts of detected errors, rerun with: -v ----- Original Message ----- From: Steve G <lin...@ya...> Date: Thu, 11 Sep 2003 18:00:19 -0700 (PDT) To: Brian Horton <bhh...@ma...> Subject: Re: [Valgrind-users] no output > >Trying to use valgrind on a product I support and it's not > >working - I don't get any of the ==pid== output at all > > Does your program fork? Many daemons need to be modified not to > fork or a command line option has to be given to keep it in the > foreground or nothing comes out. > > -Steve Grubb > -- __________________________________________________________ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers |
|
From: Nicholas N. <nj...@ca...> - 2003-09-12 08:49:56
|
On Thu, 11 Sep 2003, Brian Mosher wrote: > A couple days ago there was an article on Slashdot discussing a tool created > by Eric S Raymond called the "comparator" that generated md5sum hashes for > every three lines of source code fed into it. See details here: > [snip] > I was thinking about this and was curious if something like this could be > used on the generated machine code as executed at runtime. Could a valgrind > skin be written to md5sum the running system at the micro-code level? It > seems like this might be possible with valgrind and/or user-mode linux > and/or some sort of bastardized Bochs/vmware type thing. > > Clearly the compiler/optimizer used would affect the generated machine code. > Assuming that you could somehow compile linux using the same > compiler/optimizer as the SCO release, what are some other problems that > would prevent this from being technically feasible? I'd be inclined to do it on the static machine code, rather than the dynamic instruction stream. One big problem: I expect that machine code is far less "stable" than source code, and tiny changes in the source code would make big differences in the machine code (eg. register allocation). Or if you used a different compiler or optimisation level. Also, I imagine machine code would be less "distinctive" than source code, for comparison purposes. Also, Valgrind can't run the Linux kernel (although maybe something could be done with UML). So I'm sceptical, but willing to be proven wrong :) For a discussion of a similar-ish idea, have a look at www.cl.cam.ac.uk/~njn25/pubs/redux2003.ps.gz N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-12 08:23:55
|
On Thu, 11 Sep 2003, Matthew Tippett wrote: > Is it possible to configure valgrind to display reads and > writes to memory locations if they can be determined? For > example, debugging a XFree86 driver by looking at what what > is written to different parts of memory. > > Obviously with instrumentation this would appear to be possible, > but I am wondering if there is a valgrind skin that allows you > to do something like... > > valgrind --skin=memwatch --region=000a0000-000c0000 X > > And consequently understand all the reads and writes (and > possibly execution) of data and code in the BIOS. No current skin can do that, but it would be easy to do. Try modifying Cachegrind (cachegrind/cg_main.c). The SK_(instrument) function does the instrumentation. It's already setup to call one of several C functions on every memory-accessing instruction. Change it to call a different C function that prints out (or whatever) the accesses in the given range. Adding command-line options to skins is pretty easy, look at clo_I1_cache for an example in Cachegrind. There's a fair bit of stuff to know about when writing skins, but using Cachegrind as a starting point will make it fairly easy, and provide a good example. Write back (me or the list) if you have problems. N |
|
From: Jorrit T. <Jor...@uz...> - 2003-09-12 06:08:52
|
Dimitri Papadopoulos-Orfanos wrote: > Hi, > >> I'm using the closed source ATI drivers for my Radeon 9000 and I want >> to use >> valgrind. But apparently there are similar problems as with Valgrind >> and nVidia >> cards. Does anyone know if there is a similar solution too? > > > What sort of problems? I got a crash inside the fglrx driver itself (the program without valgrind doesn't crash). I can give you more details later but at this moment I'm not at my linux machine. > > > It seems there are two sort of problems with nVidia drivers: > > * They use MMX/SSE instructions which are not supported by valgrind. > This can be disabled by setting __GL_FORCE_GENERIC_CPU. > Maybe ATI support a similar environment variable. Do they have some > sort of mailing list you could ask to? Otherwise you'll have to > revert to some other driver to run valgrind. On the other hand other > drivers such as the XFree86 Matrox driver also contains MMX or SSE > instructions. > This leads me to think that valgrind is most often incompatible > with OpenGL programs on Linux, because many OpenGL drivers use MMX > instructions that can't be disabled. How hard would it be for valgrind to support MMX? > > > * They use NPTL on Red Hat 9, which is not supported by valgrind. > This seems to be specific to nVidia and shouldn't affect you. > Which Linux distribution are you running? I'm using RedHat 9 but I have no problems using valgrind on programs that don't use OpenGL. Greetings, |
|
From: Brian M. <bm...@di...> - 2003-09-12 01:50:29
|
All, Firstly, let me apologize for airing a half-baked idea that is probably crazy. Stop reading now if you are easily offended by ideas that are not well thought out. No flames please. A couple days ago there was an article on Slashdot discussing a tool created by Eric S Raymond called the "comparator" that generated md5sum hashes for every three lines of source code fed into it. See details here: http://slashdot.org/article.pl?sid=03/09/09/2129207 The gist of the Slashdot posting was that you could run this tool on the SCO source tree and on the linux source tree and see how much code was in common. The Slashdot community response was mixed as you might expect. They raised two basic issues: 1. SCO would never let anyone run this tool on their source, and legitimate licensees may be on shaky legal ground if they were to do it. 2. This would only detect complete cut-and-paste code reuse. Something as simple as a search-and-replace of variable names would throw off the md5sum hash enough to prevent a match. I was thinking about this and was curious if something like this could be used on the generated machine code as executed at runtime. Could a valgrind skin be written to md5sum the running system at the micro-code level? It seems like this might be possible with valgrind and/or user-mode linux and/or some sort of bastardized Bochs/vmware type thing. Clearly the compiler/optimizer used would affect the generated machine code. Assuming that you could somehow compile linux using the same compiler/optimizer as the SCO release, what are some other problems that would prevent this from being technically feasible? Thanks for indulging me, --Brian |
|
From: Dirk M. <dm...@gm...> - 2003-09-12 01:49:42
|
On Friday 12 September 2003 02:15, Dirk Morris wrote: > Does someone know how I can fix/workaround this? > Sorry if this is well known and documented elsewhere; I was unable to > find anything. Well, if you look at the code of valgrind it looks like some invalid fd is passed to it. do you call poll on a closed fd ? |
|
From: Dirk M. <dm...@gm...> - 2003-09-12 01:43:35
|
On Thursday 11 September 2003 20:08, Brian Horton wrote: > Trying to use valgrind on a product I support and it's not working - I > don't get any of the ==pid== output at all. One of my commands works, > one doesn't. I've been able to see the following difference - ldd under > valgrind does NOT show the valgrind library for the one that fails. > what's it mean? Do I need to build my code differently? > > pdoslinux:~ # valgrind pdoswhoami is this a script or an elf executable ? does this run on Redhat 9 or which distro are you using? |
|
From: Steve G <lin...@ya...> - 2003-09-12 01:00:55
|
>Trying to use valgrind on a product I support and it's not >working - I don't get any of the ==pid== output at all Does your program fork? Many daemons need to be modified not to fork or a command line option has to be given to keep it in the foreground or nothing comes out. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Dirk M. <dm...@me...> - 2003-09-12 00:15:36
|
I'm problem with valgrind. Does someone know how I can fix/workaround this? Sorry if this is well known and documented elsewhere; I was unable to find anything. The error message is this: valgrind: the `impossible' happened: poll_for_ready_fds: select failed?! Basic block ctr is approximately 100000 The command I'm running is this: valgrind --leak-check=yes --leak-resolution=high --show-reachable=yes ./foo ./foo uses many threads (pthread) and does use poll quite a bit. It happens when foo is cleaning up; it exits normally in the absense of valgrind. Versions: On Debian testing: # dpkg -l | grep libc ii libc6 2.3.1-16 GNU C Library: Shared libraries and Timezone ii libc6-dev 2.3.1-16 GNU C Library: Development Libraries and Hea # uname -a Linux jimbo 2.5.68 #5 Fri Sep 5 10:22:36 PDT 2003 i686 GNU/Linux # valgrind --version valgrind-20030725 # gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/3.3.1/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i386-linux Thread model: posix gcc version 3.3.1 20030626 (Debian prerelease) Full Output: <snip> Thu Sep 11 16:45:42 2003: Cleaning up... poll_for_ready_fds: select returned -1 valgrind: the `impossible' happened: poll_for_ready_fds: select failed?! Basic block ctr is approximately 100000 sched status: Thread 1: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 ==16736== at 0x403D2F11: __libc_nanosleep (in /lib/libc-2.3.1.so) ==16736== by 0x8049E41: main (xenon.c:150) ==16736== by 0x4034EA50: __libc_start_main (in /lib/libc-2.3.1.so) ==16736== by 0x8049A94: (within /home/dmorris/work/xenon/xenon) Thread 2: status = WaitSIG, associated_mx = 0x0, associated_cv = 0x0 ==16736== at 0x4031D3D9: sigwait (vg_libpthread.c:1297) ==16736== by 0x804A3AE: _signal_watcher (xenon.c:329) ==16736== by 0x4031C585: thread_wrapper (vg_libpthread.c:667) ==16736== by 0x4016FE24: do__quit (vg_scheduler.c:2146) Thread 3: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==16736== at 0x401815A4: vgAllRoadsLeadToRome_poll (vg_intercept.c:95) ==16736== by 0x4018165A: __poll (vg_intercept.c:366) ==16736== by 0x4018238A: vgAllRoadsLeadToRome_wait_for_fd_to_be_readable_or_erring (vg_intercept.c:883) ==16736== by 0x40181869: vgAllRoadsLeadToRome_accept (vg_intercept.c:481) Thread 6: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0 ==16736== at 0x403F0A54: __libc_read (in /lib/libc-2.3.1.so) ==16736== by 0x805833E: ru_read_request (requtil.c:85) ==16736== by 0x804F5B2: _reqhandler_handle_request (reqhandler.c:57) ==16736== by 0x804F525: reqhandler_newtransform (reqhandler.c:40) 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. |
|
From: Dirk M. <dm...@gm...> - 2003-09-11 22:00:12
|
On Thursday 11 September 2003 17:54, Andrés Roldán wrote: > I have several requests from users with a strange error whis is not > reproducible all the times. It seems to happen when network connections > are attempted. This error has been reproducible with packages such as > iptstate, nget and squid. The error is as follows: do you dlopen() or dlclose() stuff? otherwise its the NIS stuff of glibc (do you call gethostbyname() or similiar?) |
|
From: Robert W. <rj...@du...> - 2003-09-11 18:46:54
|
> Is it possible to configure valgrind to display reads and > writes to memory locations if they can be determined? For > example, debugging a XFree86 driver by looking at what what > is written to different parts of memory. I wrote a patch some months back to allow watchpoints. I haven't tested it in a while, but I could blow the dust off of it and see if I can get it working again. It uses client requests, but I could add a command-line option, I suppose. Regards, Robert. |
|
From: Brian H. <bhh...@ma...> - 2003-09-11 18:09:09
|
Trying to use valgrind on a product I support and it's not working - I
don't get any of the ==pid== output at all. One of my commands works,
one doesn't. I've been able to see the following difference - ldd under
valgrind does NOT show the valgrind library for the one that fails.
what's it mean? Do I need to build my code differently?
this is with the latest build:
pdoslinux:~ # valgrind --version
valgrind-20030725
valgrind does NOT work on this one:
pdoslinux:~ # valgrind pdoswhoami
AOSUT0413E Unable to determine the ID of the invoker: 0x35a62780:
AOSSS1920E invalid parameter value (pd / oss)
pdoslinux:~ # valgrind ldd /opt/pdos/bin/pdoswhoami
==2646== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==2646== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2646== Using valgrind-20030725, a program supervision framework for
x86-linux.
==2646== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2646== Estimated CPU clock rate is 399 MHz
==2646== For more details, rerun with: -v
==2646==
libpthread.so.0 => /lib/libpthread.so.0 (0x40019000)
libosseal.so => /usr/lib/libosseal.so (0x4002e000)
libkosseal.so => /usr/lib/libkosseal.so (0x40095000)
libpdsvcutl.so => /usr/lib/libpdsvcutl.so (0x40098000)
libc.so.6 => /lib/libc.so.6 (0x400f5000)
libpdadminapi.so => /usr/lib/libpdadminapi.so (0x40214000)
libpdz.5.1.so => /usr/lib/libpdz.5.1.so (0x402c1000)
libmsg22.so => /usr/lib/libmsg22.so (0x4034c000)
libamserutl.so => /usr/lib/libamserutl.so (0x40367000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4041a000)
libm.so.6 => /lib/libm.so.6 (0x404ce000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x404f1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libdl.so.2 => /lib/libdl.so.2 (0x404f9000)
libgsk7km.so => /usr/lib/libgsk7km.so (0x404fd000)
libpdmgrapi.so => /usr/lib/libpdmgrapi.so (0x4059e000)
libpdauthzn.so => /usr/lib/libpdauthzn.so (0x40664000)
libpdmts.so => /usr/lib/libpdmts.so (0x406dc000)
liburaf.so => /usr/lib/liburaf.so (0x40753000)
libpdcore.so => /usr/lib/libpdcore.so (0x40780000)
libpdutil.so => /usr/lib/libpdutil.so (0x407d3000)
libgsk7cms.so => /usr/lib/libgsk7cms.so (0x407ef000)
libpdira.so => /usr/lib/libpdira.so (0x40975000)
libpdauthn.so => /usr/lib/libpdauthn.so (0x409c4000)
libgsomgmt.so => /usr/lib/libgsomgmt.so (0x409cf000)
libamaudutl.so => /usr/lib/libamaudutl.so (0x409ed000)
libamxalan-c.so => /usr/lib/libamxalan-c.so (0x40a20000)
libamxerces-c.so => /usr/lib/libamxerces-c.so (0x40d95000)
libgsk7ssl.so => /usr/lib/libgsk7ssl.so (0x4102c000)
libgsk7sys.so => /usr/lib/libgsk7sys.so (0x410a6000)
==2646==
==2646== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2646== malloc/free: in use at exit: 22967 bytes in 763 blocks.
==2646== malloc/free: 2905 allocs, 2142 frees, 89416 bytes allocated.
==2646== For a detailed leak analysis, rerun with: --leak-check=yes
==2646== For counts of detected errors, rerun with: -v
but does work here:
pdoslinux:~ # valgrind pdosversion
==2640== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==2640== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2640== Using valgrind-20030725, a program supervision framework for
x86-linux.
==2640== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2640== Estimated CPU clock rate is 398 MHz
==2640== For more details, rerun with: -v
==2640==
pdosversion 5.1.0.0 (030904a)
libosseald 5.1.0.0 (030904a)
libosseal 5.1.0.0 (030904a)
libkosseal 5.1.0.0 (030904a)
liblpm 5.1.0.0 (030904a)
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x40008691: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==2640==
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x40008695: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
LRD_AuditInput 5.1.0.0 (030904a)
==2640==
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x400086FA: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==2640==
==2640== Conditional jump or move depends on uninitialised value(s)
==2640== at 0x4000872F: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2640== by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2640== by 0x405500C0: dl_open_worker (in /lib/libc.so.6)
==2640== by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
LRD_EmailOutput 5.1.0.0 (030904a)
LRD_FileOutput 5.1.0.0 (030904a)
LRD_NetOutput 5.1.0.0 (030904a)
==2640==
==2640== ERROR SUMMARY: 10 errors from 4 contexts (suppressed: 1 from 1)
==2640== malloc/free: in use at exit: 14412 bytes in 113 blocks.
==2640== malloc/free: 279 allocs, 166 frees, 56361 bytes allocated.
==2640== For a detailed leak analysis, rerun with: --leak-check=yes
==2640== For counts of detected errors, rerun with: -v
pdoslinux:~ # valgrind ldd /opt/pdos/bin/pdosversion
==2641== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==2641== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2641== Using valgrind-20030725, a program supervision framework for
x86-linux.
==2641== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2641== Estimated CPU clock rate is 399 MHz
==2641== For more details, rerun with: -v
==2641==
/usr/local/lib/valgrind/valgrinq.so =>
/usr/local/lib/valgrind/valgrinq.so (0x40014000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4001b000)
libosseal.so => /usr/lib/libosseal.so (0x40030000)
libosseald.so => /usr/lib/libosseald.so (0x40097000)
libkosseal.so => /usr/lib/libkosseal.so (0x400c1000)
liblpm.so => /usr/lib/liblpm.so (0x400c5000)
libpdsvcutl.so => /usr/lib/libpdsvcutl.so (0x40104000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40161000)
libm.so.6 => /lib/libm.so.6 (0x40215000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40238000)
libc.so.6 => /lib/libc.so.6 (0x40240000)
libdl.so.2 => /lib/libdl.so.2 (0x4035e000)
libpdadminapi.so => /usr/lib/libpdadminapi.so (0x40361000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4040f000)
libpdz.5.1.so => /usr/lib/libpdz.5.1.so (0x40440000)
libmsg22.so => /usr/lib/libmsg22.so (0x404cb000)
libamserutl.so => /usr/lib/libamserutl.so (0x404e6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libgsk7km.so => /usr/lib/libgsk7km.so (0x40599000)
libpdmgrapi.so => /usr/lib/libpdmgrapi.so (0x4063a000)
libpdauthzn.so => /usr/lib/libpdauthzn.so (0x40700000)
libpdmts.so => /usr/lib/libpdmts.so (0x40779000)
liburaf.so => /usr/lib/liburaf.so (0x407f0000)
libpdcore.so => /usr/lib/libpdcore.so (0x4081d000)
libpdutil.so => /usr/lib/libpdutil.so (0x40870000)
libgsk7cms.so => /usr/lib/libgsk7cms.so (0x4088b000)
libpdira.so => /usr/lib/libpdira.so (0x40a11000)
libpdauthn.so => /usr/lib/libpdauthn.so (0x40a60000)
libgsomgmt.so => /usr/lib/libgsomgmt.so (0x40a6c000)
libamaudutl.so => /usr/lib/libamaudutl.so (0x40a8a000)
libamxalan-c.so => /usr/lib/libamxalan-c.so (0x40abd000)
libamxerces-c.so => /usr/lib/libamxerces-c.so (0x40e32000)
libgsk7ssl.so => /usr/lib/libgsk7ssl.so (0x410c8000)
libgsk7sys.so => /usr/lib/libgsk7sys.so (0x41142000)
==2641==
==2641== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2641== malloc/free: in use at exit: 22970 bytes in 763 blocks.
==2641== malloc/free: 2905 allocs, 2142 frees, 89510 bytes allocated.
==2641== For a detailed leak analysis, rerun with: --leak-check=yes
==2641== For counts of detected errors, rerun with: -v
|