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
(5) |
2
(5) |
3
(3) |
|
4
|
5
(4) |
6
(6) |
7
(4) |
8
(14) |
9
(2) |
10
(4) |
|
11
(2) |
12
(2) |
13
(4) |
14
(7) |
15
(5) |
16
(11) |
17
(4) |
|
18
|
19
(10) |
20
(4) |
21
(13) |
22
(6) |
23
(6) |
24
(4) |
|
25
(5) |
26
(18) |
27
(7) |
28
(10) |
29
(11) |
30
(17) |
|
|
From: Henrik N. <hn...@ma...> - 2004-04-08 17:22:49
|
On Thu, 8 Apr 2004, Bob Rossi wrote: > I understand and agree completely. Unfortunately, this code is in GNAT's > runtime. I don't have the option of modifying it. You have as much option to modify the GNAT runtime as any other Open Source program including Valgrind.. > Apparently the code works and is really portable across UNIX machines, > since GNAT ports and works in many different environments. Still this is a quite serious bug in GNAT and a bug report should be filed to have this GNAT bug fixed.. If not it will soner or later bite someone hard. Regards Henrik |
|
From: tmoog <tm...@sa...> - 2004-04-08 16:34:22
|
I have noticed that when a .so is loaded via dlopen and it is unloaded via dlclose before exit then valgrind doesn't know how to resolve the symbols for that .so. Nicholas Nethercote wrote: > On Thu, 8 Apr 2004, G B wrote: > > > > > CC=g++ > > > > LFLAGS=-L/usr/X11R6/lib -lGL -lGLU -lglut -lm -lXi > > > > -lXmu `/usr/bin/sdl-config --libs` -lSDL_image > > > > CFLAGS=-Wall -Wno-parentheses -fstack-check > > > > `/usr/bin/sdl-config --cflags` > > > > > > > > $(CC) -g -o main $(OBJS) $(LFLAGS) $(CFLAGS) > > > > > > Hmm, maybe -fstack-check is confusing Valgrind? > > > > Yes it was. Hmm. > > > > Well, the only error I get from my program when I run > > it now is this: > > > > ==3017== Invalid free() / delete / delete[] > > ==3017== at 0x7501CDEC: free (in > > /usr/lib/valgrind/vgpreload_addrcheck.so) > > ==3017== by 0x7540B9B3: (within /lib/libc-2.3.3.so) > > ==3017== by 0x7540B6F9: __libc_freeres (in > > /lib/libc-2.3.3.so) > > ==3017== by 0x75018BBE: (within > > /usr/lib/valgrind/vg_inject.so) > > ==3017== Address 0x759D0818 is not stack'd, malloc'd > > or free'd > > > > Is this valgrind finding a bug in > > a) itself? > > b) libc? > > c) my program? > > Maybe b, maybe c. A longer stack trace (eg. --num-callers=20) will > hopefully make it clearer. > > N > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 16:24:54
|
On Thu, 8 Apr 2004, G B wrote: > > > CC=g++ > > > LFLAGS=-L/usr/X11R6/lib -lGL -lGLU -lglut -lm -lXi > > > -lXmu `/usr/bin/sdl-config --libs` -lSDL_image > > > CFLAGS=-Wall -Wno-parentheses -fstack-check > > > `/usr/bin/sdl-config --cflags` > > > > > > $(CC) -g -o main $(OBJS) $(LFLAGS) $(CFLAGS) > > > > Hmm, maybe -fstack-check is confusing Valgrind? > > Yes it was. Hmm. > > Well, the only error I get from my program when I run > it now is this: > > ==3017== Invalid free() / delete / delete[] > ==3017== at 0x7501CDEC: free (in > /usr/lib/valgrind/vgpreload_addrcheck.so) > ==3017== by 0x7540B9B3: (within /lib/libc-2.3.3.so) > ==3017== by 0x7540B6F9: __libc_freeres (in > /lib/libc-2.3.3.so) > ==3017== by 0x75018BBE: (within > /usr/lib/valgrind/vg_inject.so) > ==3017== Address 0x759D0818 is not stack'd, malloc'd > or free'd > > Is this valgrind finding a bug in > a) itself? > b) libc? > c) my program? Maybe b, maybe c. A longer stack trace (eg. --num-callers=20) will hopefully make it clearer. N |
|
From: Bob R. <bo...@br...> - 2004-04-08 14:53:05
|
> > The problem is, the source and destination are the same a lot, which I > > think is OK, even though it may not be good programming. > > Strictly speaking it is not OK at all. Here's what the Single Unix > Specification has to say about memcpy: > > "The memcpy() function shall copy n bytes from the object pointed to by > s2 into the object pointed to by s1. If copying takes place between > objects that overlap, the behavior is undefined. > > The ISO C standard, to which the Single Unix Specification defers > to for memcpy as the normative reference will say something similar > although I don't haver a copy to hand. > > In reality you will probably get away with it when the addresses are > the same, but there's no reason why somebody couldn't write a perverse > implementation where it would fail. I understand and agree completely. Unfortunately, this code is in GNAT's runtime. I don't have the option of modifying it. Apparently the code works and is really portable across UNIX machines, since GNAT ports and works in many different environments. Thanks, Bob Rossi |
|
From: Bill T. <bil...@ve...> - 2004-04-08 14:46:48
|
I'm trying to set up a fairly broad suppression entry to exclude leak
checking in xerces/xalan libraries. The entries look like:
{
xerces
Memcheck:Leak
obj:*libxerces*
fun:*
}
{
xalan
Memcheck:Leak
obj:*libxalan*
fun:*
}
It looks like vg is picking up the file:
==4709== Reading suppressions file: /home/torpey/MXLib/dev/mxlib.supp
but the only entries listed are:
--4709-- supp: 55 Ugly strchr error in /lib/ld-2.3.2.so
--4709-- supp: 6 pthread_mutex_unlock/_IO_funlockfile
--4709-- supp: 8 realpath is inefficiently coded
From docs, it sounds like suppression entries only get listed if they are
used, so I suppose that mine did not. Nevertheless, there are a bunch of
reports, of the general form:
==4709==
==4709== 4 bytes in 1 blocks are still reachable in loss record 1 of 864
==4709== at 0x3C01C3B4: operator new(unsigned) (vg_replace_malloc.c:107)
==4709== by 0x3C651CE5: xercesc_2_2::gScannerMutex() (in
/home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C653F50: xercesc_2_2::XMLScanner::commonInit() (in
/home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C6521A2:
xercesc_2_2::XMLScanner::XMLScanner(xercesc_2_2::XMLValidator*) (in
/home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C5C9C99:
xercesc_2_2::IGXMLScanner::IGXMLScanner(xercesc_2_2::XMLValidator*) (in
/home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C656858:
xercesc_2_2::XMLScannerResolver::getDefaultScanner(xercesc_2_2::XMLValidator
*) (in /home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C5F7DC0: xercesc_2_2::SAX2XMLReaderImpl::initialize() (in
/home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C5F7A8D:
xercesc_2_2::SAX2XMLReaderImpl::SAX2XMLReaderImpl() (in
/home/torpey/gcc32-32/xerces-c-src2_2_0/lib/libxerces-c.so.22.0)
==4709== by 0x3C331ED8:
xalanc_1_5::XalanSourceTreeParserLiaison::createReader() (in
/home/torpey/gcc32-32/xml-xalan/c/lib/libxalan-c1_5_0.so)
==4709== by 0x3C3317D8:
xalanc_1_5::XalanSourceTreeParserLiaison::parseXMLStream(xercesc_2_2::InputS
ource const&, xalanc_1_5::XalanDOMString const&) (in
/home/torpey/gcc32-32/xml-xalan/c/lib/libxalan-c1_5_0.so)
==4709== by 0x80572F3: XMLConfig::ParseXML(char const*)
(../XMLConfig/XMLConfig_xalan.h:221)
==4709== by 0x8055D96: XMLConfig::loadFile(char const*)
(../XMLConfig/XMLConfig_xalan.h:204)
==4709== by 0x80551BB: XMLConfig::XMLConfig(char const*)
(../XMLConfig/XMLConfig_xalan.h:145)
==4709== by 0x8051661: main (xla.cpp:606)
==4709==
If anyone has any experience getting wildcard suppression entries to work, I
would certainly appreciate some pointers. The '--gen-suppressions' option
is useless in this case because there are just too many potential entries.
I'm running valgrind 2.1.1. Parameters are:
==4709== Startup, with flags:
==4709== --tool=memcheck
==4709== --verbose
==4709== --leak-check=yes
==4709== --leak-resolution=high
==4709== --num-callers=20
==4709== --show-reachable=yes
==4709== --workaround-gcc296-bugs=yes
==4709== --suppressions=/home/torpey/MXLib/dev/mxlib.supp
Thanks in advance for any help!
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 14:39:22
|
On Thu, 8 Apr 2004, Bob Rossi wrote: > > Easy option: modify memcheck/mac_replace_strmem.c:is_overlap() to not > > consider this an overlap -- it's a one-line change, the last case in the > > function, the comment explains. > > Wow, that worked great. Should I make this into an option? Or will > someone else take care of this? Or is this the proper work around for > me? Probably best as a personal workaround. If 50 people had the same issue, then maybe an option would be appropriate. Until then... Valgrind has enough options already. N |
|
From: Tom H. <th...@cy...> - 2004-04-08 14:32:40
|
In message <20040408140907.GA5369@white>
Bob Rossi <bo...@br...> wrote:
> The problem is, the source and destination are the same a lot, which I
> think is OK, even though it may not be good programming.
Strictly speaking it is not OK at all. Here's what the Single Unix
Specification has to say about memcpy:
"The memcpy() function shall copy n bytes from the object pointed to by
s2 into the object pointed to by s1. If copying takes place between
objects that overlap, the behavior is undefined.
The ISO C standard, to which the Single Unix Specification defers
to for memcpy as the normative reference will say something similar
although I don't haver a copy to hand.
In reality you will probably get away with it when the addresses are
the same, but there's no reason why somebody couldn't write a perverse
implementation where it would fail.
> Is there any way to suppress all of these warnings?
Well you can add Overlap suppressions, but you would have to specify
at least one routine for each one.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-04-08 14:30:20
|
On Thu, Apr 08, 2004 at 03:23:17PM +0100, Nicholas Nethercote wrote: > On Thu, 8 Apr 2004, Bob Rossi wrote: > > > I do have one small issue that I was hoping would be easy to solve. I am > > using the Memcheck skin of valgrind and I keep getting this error, > > > > ==32699== Source and destination overlap in memcpy(0x43083a74, 0x43083a74, 32) > > ==32699== at 0x4002068A: memcpy (../../valgrind-2.0.0/memcheck/mac_replace_strmem.c:95) > > ==32699== by 0x8385899: config___deep_adjust__2 (/home/BONO/bar/cvs/edg/vectors/vcast/config.ads:129) > > ==32699== by 0x83C0B04: config__default_config_parameters (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2366) > > ==32699== by 0x83C2367: config___elabb (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2415) > > > > The problem is, the source and destination are the same a lot, which I > > think is OK, even though it may not be good programming. Unfortunately, > > most of this is happening in the Ada runtime, so I can not change that. > > > > Is there any way to suppress all of these warnings? > > Not to suppress all the warnings where the src and dst are the same. You > could write a suppression to suppress all overlap errors, but I don't > think you want that. > > > My only alternative is to just keep adding these suppressions to a file, > > however, there could potentially be thousands of them. > > Easy option: modify memcheck/mac_replace_strmem.c:is_overlap() to not > consider this an overlap -- it's a one-line change, the last case in the > function, the comment explains. Wow, that worked great. Should I make this into an option? Or will someone else take care of this? Or is this the proper work around for me? Thanks, Bob Rossi |
|
From: Paul L D. <pld...@pl...> - 2004-04-08 14:29:43
|
Hi Bob, > > The problem is, the source and destination are the same a lot, which I > think is OK, even though it may not be good programming. Unfortunately, Use memmove() --- if you can, not sure if you can't modify the Ada source. Other than that, you perhaps will have to go the route of using a 'temporary' holding variable. > Is there any way to suppress all of these warnings? use --gen-suppressions=yes if you really must, and add them into your default.supp file.... one should eliminate the errors for all instances of the memcpy() calls. Regards. -- Paul L Daniels - PLD Software - Xamime Unix systems Internet Development A.B.N. 19 500 721 806 ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73 PGP Public Key at http://www.pldaniels.com/gpg-keys.pld |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 14:26:09
|
On Thu, 8 Apr 2004, G B wrote: > > That output looks like the relevant part of the program has been > > stripped of both debug info and symbol tables. But if you are > > compiling with -g, that shouldn't be the case. Are you compiling with > > -fomit-frame-pointer? That could be a problem. > > I'm compiling like this: > > CC=g++ > LFLAGS=-L/usr/X11R6/lib -lGL -lGLU -lglut -lm -lXi > -lXmu `/usr/bin/sdl-config --libs` -lSDL_image > CFLAGS=-Wall -Wno-parentheses -fstack-check > `/usr/bin/sdl-config --cflags` > > $(CC) -g -o main $(OBJS) $(LFLAGS) $(CFLAGS) Hmm, maybe -fstack-check is confusing Valgrind? N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 14:23:24
|
On Thu, 8 Apr 2004, Bob Rossi wrote: > I do have one small issue that I was hoping would be easy to solve. I am > using the Memcheck skin of valgrind and I keep getting this error, > > ==32699== Source and destination overlap in memcpy(0x43083a74, 0x43083a74, 32) > ==32699== at 0x4002068A: memcpy (../../valgrind-2.0.0/memcheck/mac_replace_strmem.c:95) > ==32699== by 0x8385899: config___deep_adjust__2 (/home/BONO/bar/cvs/edg/vectors/vcast/config.ads:129) > ==32699== by 0x83C0B04: config__default_config_parameters (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2366) > ==32699== by 0x83C2367: config___elabb (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2415) > > The problem is, the source and destination are the same a lot, which I > think is OK, even though it may not be good programming. Unfortunately, > most of this is happening in the Ada runtime, so I can not change that. > > Is there any way to suppress all of these warnings? Not to suppress all the warnings where the src and dst are the same. You could write a suppression to suppress all overlap errors, but I don't think you want that. > My only alternative is to just keep adding these suppressions to a file, > however, there could potentially be thousands of them. Easy option: modify memcheck/mac_replace_strmem.c:is_overlap() to not consider this an overlap -- it's a one-line change, the last case in the function, the comment explains. N |
|
From: Bob R. <bo...@br...> - 2004-04-08 14:09:20
|
Hello, I am just learning how to use valgrind and think it is a wonderful program. Thanks for the great work. I do have one small issue that I was hoping would be easy to solve. I am using the Memcheck skin of valgrind and I keep getting this error, ==32699== Source and destination overlap in memcpy(0x43083a74, 0x43083a74, 32) ==32699== at 0x4002068A: memcpy (../../valgrind-2.0.0/memcheck/mac_replace_strmem.c:95) ==32699== by 0x8385899: config___deep_adjust__2 (/home/BONO/bar/cvs/edg/vectors/vcast/config.ads:129) ==32699== by 0x83C0B04: config__default_config_parameters (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2366) ==32699== by 0x83C2367: config___elabb (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2415) The problem is, the source and destination are the same a lot, which I think is OK, even though it may not be good programming. Unfortunately, most of this is happening in the Ada runtime, so I can not change that. Is there any way to suppress all of these warnings? My only alternative is to just keep adding these suppressions to a file, however, there could potentially be thousands of them. Any help would be greatly appreciated. Thanks, Bob Rossi |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 08:18:42
|
On Thu, 8 Apr 2004, G B wrote: > I'm getting output like this when I run my program > under addrcheck or memcheck: > > ==852== Invalid write of size 4 > ==852== at 0x8050887: ??? > ==852== by 0x80510EC: ??? > ==852== by 0x80514C0: ??? > ==852== by 0x80514B5: ??? > ==852== Address 0x9BFFD1A8 is not stack'd, malloc'd > or free'd > > and only slightly more helpfully: > ==852== Invalid write of size 4 > ==852== at 0x804A4B3: ??? > ==852== by 0x804A84A: ??? > ==852== by 0x7510655B: processEventsAndTimeouts (in > /usr/lib/libglut.so.3.7.1) > ==852== by 0xCE: ??? > ==852== Address 0x9BFFD2B8 is not stack'd, malloc'd > or free'd > > Could the lack of pointers to source code be a problem > with the way I've compiled my program? I've got -g in > there - is there anything else I need? That output looks like the relevant part of the program has been stripped of both debug info and symbol tables. But if you are compiling with -g, that shouldn't be the case. Are you compiling with -fomit-frame-pointer? That could be a problem. N |
|
From: <gil...@ya...> - 2004-04-08 02:07:44
|
Hi, I'm getting output like this when I run my program under addrcheck or memcheck: ==852== Invalid write of size 4 ==852== at 0x8050887: ??? ==852== by 0x80510EC: ??? ==852== by 0x80514C0: ??? ==852== by 0x80514B5: ??? ==852== Address 0x9BFFD1A8 is not stack'd, malloc'd or free'd and only slightly more helpfully: ==852== Invalid write of size 4 ==852== at 0x804A4B3: ??? ==852== by 0x804A84A: ??? ==852== by 0x7510655B: processEventsAndTimeouts (in /usr/lib/libglut.so.3.7.1) ==852== by 0xCE: ??? ==852== Address 0x9BFFD2B8 is not stack'd, malloc'd or free'd Could the lack of pointers to source code be a problem with the way I've compiled my program? I've got -g in there - is there anything else I need? Thanks ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
|
From: Oswald B. <os...@kd...> - 2004-04-07 23:02:19
|
hoi, the option name and associated documentation is misleading, if not plainly wrong. a child is an artifact of a fork(), not of an execve(). i have no idea how the artifact of an execve() is called, so i can't suggest a better option name than --trace-execs. greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Tom H. <th...@cy...> - 2004-04-07 18:47:58
|
In message <2b6...@lo...>
Tom Hughes <th...@cy...> wrote:
> In message <200...@we...>
> smiley glitter <smi...@ya...> wrote:
>
> > I have a program that uses shared memory. When the
> > program requests for a segment it goes through fine.
> > when i want it to be aligned at a particular address,
> > there seems to be some problem with valgrind.
> >
> > i.e.
> >
> > shmat(key, <addr>, <perms>)
> >
> > problem occurs when addr is not null. Have attached a
> > sample program.
>
> When you say "there seems to be some problem" what exactly does
> that mean? What happens that is different from normal?
OK. I've tried your example now, and I see the problem.
Your problem is that valgrind has to reserve part of the address
space for it's own use, and the address you are trying to use is
in that reserved space when you use the memcheck skin, so valgrind
prevents you using it.
If you use addrcheck then it will work, because that skin doesn't
need as much shadow memory, so there is more address space left
for the client program.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-04-07 18:36:33
|
In message <200...@we...>
smiley glitter <smi...@ya...> wrote:
> I have a program that uses shared memory. When the
> program requests for a segment it goes through fine.
> when i want it to be aligned at a particular address,
> there seems to be some problem with valgrind.
>
> i.e.
>
> shmat(key, <addr>, <perms>)
>
> problem occurs when addr is not null. Have attached a
> sample program.
When you say "there seems to be some problem" what exactly does
that mean? What happens that is different from normal?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: smiley g. <smi...@ya...> - 2004-04-07 18:28:31
|
Hello, I have a program that uses shared memory. When the program requests for a segment it goes through fine. when i want it to be aligned at a particular address, there seems to be some problem with valgrind. i.e. shmat(key, <addr>, <perms>) problem occurs when addr is not null. Have attached a sample program. Thanks in advance, smile __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Russ C. <rs...@sw...> - 2004-04-06 21:09:52
|
Tom Hughes wrote: > Is that with a 2.2 kernel by any chance? That's the only way I know > to provoke that message at present. So it is! I played funny games tricking the Debian/stable installer into installing a Debian/testing system, but apparently I missed the kernels. I'll upgrade my kernel. Thanks. Russ |
|
From: Tom H. <th...@cy...> - 2004-04-06 19:44:49
|
In message <407...@sw...>
Russ Cox <rs...@sw...> wrote:
> Just installed valgrind 2.1.1-2 using Debian testing apt-get.
>
> tux=; valgrind ls
> fix_auxv: we didn't see enough auxv entries (seen=0)
> tux=;
Is that with a 2.2 kernel by any chance? That's the only way I know
to provoke that message at present.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Russ C. <rs...@sw...> - 2004-04-06 18:56:50
|
Just installed valgrind 2.1.1-2 using Debian testing apt-get. tux=; valgrind ls fix_auxv: we didn't see enough auxv entries (seen=0) tux=; Is this likely to be a Debian problem or did they just get a bad version of Valgrind? I searched the valgrind-users archives on sourceforge for fix_auxv but found nothing. Apologies if this has been recently discussed. Russ |
|
From: Henrik N. <hn...@ma...> - 2004-04-06 12:45:56
|
On Tue, 6 Apr 2004, Attila wrote: > Is it a bug of mine or of glibc? Is it a serious thing? > ==16380== at 0x3C1130A6: sendto (in /lib/i686/libc.so.6) > ==16380== by 0x3C12F081: __check_pf (in /lib/i686/libc.so.6) > ==16380== by 0x3C0FEB10: getaddrinfo (in /lib/i686/libc.so.6) > ==16380== by 0x804839D: main (main.c:9) Looks to me like a harmless glibc or nsswitch misfeature/overoptimization. Regards Henrik |
|
From: Steve G <lin...@ya...> - 2004-04-06 12:33:49
|
>Is it a bug of mine or of glibc? This is in glibc. I've mentioned it to Red Hat developers a couple of times. What is happening is they are using a dummy structure to fill in a lower level call for something that was otherwise passed to getaddrinfo as a NULL pointer. Usually, this is the service parameter. As best as I can tell, it is harmless...but I wished they would correct it. Hope this helps... -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ |
|
From: Attila <sa...@fr...> - 2004-04-06 10:46:37
|
Hi,
I had a strange message with getaddrinfo (before that I used
gethostbyname, but it was no good in a multithreaded
program, so moved to getaddrinfo per man page instructions
(gethostbyname -> getipnodebyname -> getaddrinfo).
Is it a bug of mine or of glibc? Is it a serious thing?
I include a small test program here, and the verbose vg output.
I use SuSE 9 and vg 2.1.1.
br,
Attila
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
int main()
{
int ret;
struct addrinfo* ainfo;
ret = getaddrinfo(/* node = */ "127.0.0.1", /* service =
*/ NULL,
/* hints = */ NULL, &ainfo);
freeaddrinfo(ainfo);
return ret;
}
==16380== Memcheck, a memory error detector for x86-linux.
==16380== Copyright (C) 2002-2004, and GNU GPL'd, by Julian
Seward.
==16380== Using valgrind-2.1.1, a program supervision
framework for x86-linux.
==16380== Copyright (C) 2000-2004, and GNU GPL'd, by Julian
Seward.
==16380== Valgrind library directory: /usr/local/lib/valgrind
==16380== Command line
==16380== ./a.out
==16380== Startup, with flags:
==16380== --tool=memcheck
==16380== --leak-check=yes
==16380== --num-callers=9
==16380== -v
==16380== Reading syms from
/home/avangel/test/vg_getaddrinfo/a.out (0x8048000)
==16380== Reading syms from /lib/ld-2.3.2.so (0x3C000000)
==16380== object doesn't have any debug info
==16380== Reading syms from /lib/ld-2.3.2.so (0xB0000000)
==16380== object doesn't have any debug info
==16380== Reading syms from /lib/libdl.so.2 (0xB002A000)
==16380== object doesn't have any debug info
==16380== Reading syms from /lib/i686/libc.so.6 (0xB002D000)
==16380== object doesn't have any debug info
==16380== Reading syms from
/usr/local/lib/valgrind/vgskin_memcheck.so (0xB0260000)
==16380== Reading syms from /usr/local/lib/valgrind/stage2
(0xB8000000)
==16380== Reading suppressions file:
/usr/local/lib/valgrind/default.supp
==16380== REDIRECT soname:libc.so.6(__GI___errno_location)
to soname:libpthread.so.0(__errno_location)
==16380== REDIRECT soname:libc.so.6(__errno_location) to
soname:libpthread.so.0(__errno_location)
==16380== REDIRECT soname:libc.so.6(__GI___h_errno_location)
to soname:libpthread.so.0(__h_errno_location)
==16380== REDIRECT soname:libc.so.6(__h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==16380== REDIRECT soname:libc.so.6(__GI___res_state) to
soname:libpthread.so.0(__res_state)
==16380== REDIRECT soname:libc.so.6(__res_state) to
soname:libpthread.so.0(__res_state)
==16380== REDIRECT soname:libc.so.6(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==16380== REDIRECT soname:libc.so.6(strnlen) to
*vgpreload_memcheck.so*(strnlen)
==16380== REDIRECT soname:ld-linux.so.2(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==16380== REDIRECT soname:ld-linux.so.2(strchr) to
*vgpreload_memcheck.so*(strchr)
==16380==
==16380== Reading syms from
/usr/local/lib/valgrind/vg_inject.so (0x3C01C000)
==16380== Reading syms from
/usr/local/lib/valgrind/vgpreload_memcheck.so (0x3C01F000)
==16380== TRANSLATE: 0x3C0133D0 redirected to 0x3C020A30
==16380== Reading syms from /lib/i686/libc.so.6 (0x3C036000)
==16380== object doesn't have any debug info
==16380== Syscall param socketcall.sendto(msg) contains
uninitialised or unaddressable byte(s)
==16380== at 0x3C1130A6: sendto (in /lib/i686/libc.so.6)
==16380== by 0x3C12F081: __check_pf (in /lib/i686/libc.so.6)
==16380== by 0x3C0FEB10: getaddrinfo (in /lib/i686/libc.so.6)
==16380== by 0x804839D: main (main.c:9)
==16380== Address 0x4FFFDF41 is on thread 1's stack
==16380==
==16380== ERROR SUMMARY: 1 errors from 1 contexts
(suppressed: 11 from 1)
==16380==
==16380== 1 errors in context 1 of 1:
==16380== Syscall param socketcall.sendto(msg) contains
uninitialised or unaddressable byte(s)
==16380== at 0x3C1130A6: sendto (in /lib/i686/libc.so.6)
==16380== by 0x3C12F081: __check_pf (in /lib/i686/libc.so.6)
==16380== by 0x3C0FEB10: getaddrinfo (in /lib/i686/libc.so.6)
==16380== by 0x804839D: main (main.c:9)
==16380== Address 0x4FFFDF41 is on thread 1's stack
--16380--
--16380-- supp: 11 Ugly strchr error in /lib/ld-2.3.2.so
==16380==
==16380== IN SUMMARY: 1 errors from 1 contexts (suppressed:
11 from 1)
==16380==
==16380== malloc/free: in use at exit: 0 bytes in 0 blocks.
==16380== malloc/free: 3 allocs, 3 frees, 144 bytes allocated.
==16380==
==16380== No malloc'd blocks -- no leaks are possible.
--16380-- TT/TC: 0 tc sectors discarded.
--16380-- 1106 chainings, 2 unchainings.
--16380-- translate: new 1856 (33714 -> 438005; ratio
129:10)
--16380-- discard 1 (23 -> 320; ratio 139:10).
--16380-- dispatch: 0 jumps (bb entries), of which 4650
(465000%) were unchained.
--16380-- 25/2210 major/minor sched events. 1979
tt_fast misses.
--16380-- reg-alloc: 418 t-req-spill, 82057+3327 orig+spill
uis, 10145 total-reg-r.
--16380-- sanity: 26 cheap, 2 expensive checks.
--16380-- ccalls: 6989 C calls, 54% saves+restores
avoided (22284 bytes)
--16380-- 9271 args, avg 0.86 setup instrs each
(2446 bytes)
--16380-- 0% clear the stack (20967 bytes)
--16380-- 3137 retvals, 27% of reg-reg movs
avoided (1688 bytes)
|
|
From: Peter S. <sei...@ci...> - 2004-04-05 16:57:06
|
Hello, calling pthhread_cond_destroy under valgrind-2.1.2-CVS gives ==3119== warning: Valgrind's pthread_cond_destroy is incomplete ==3119== (it doesn't check if the cond is waited on) ==3119== your program may misbehave as a result The attached patch implements this missing check by counting the number of threads waiting on the specified condition (using 'vg_pthread_cond_t.__vg_c_waiting'). The patch works for me (and the two short testprogramms in the second attachement), hope I didn't miss something... Peter -- ------------------------------------------------------------------------ Peter Seiderer E-Mail: sei...@ci... |