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
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Matt P. <uri...@ya...> - 2003-08-07 21:10:06
|
I'm using a valgrind 20030725 on RedHat 9 to analyze a Berkeley database application. For some reason when I start the application under valgrind, Berkeley complains that a "Function isn't implemented" to support locking. I'm assuming that this has something to do with a mutex. Has anyone seen this problem before? Thanks. --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
|
From: Steve F. <sf...@re...> - 2003-08-06 17:31:40
|
Greg Hudson wrote: >After rooting through the valgrind source, I discovered that I am >blind, and the address info I coveted is displayed between two partial >stack traces: > >==6579== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) >==6579== at 0x40181C24: vgAllRoadsLeadToRome_writev (vg_intercept.c:108) >==6579== by 0x40181C60: __writev (vg_intercept.c:732) >==6579== by 0x407C311D: (within /usr/lib/liblinc.so.1.0.0) >==6579== by 0x407C32AB: linc_connection_writev (in /usr/lib/liblinc.so.1.0.0) >==6579== Address 0x4402E83E is 10 bytes inside a block of size 2048 alloc'd >==6579== at 0x4002942A: malloc (vg_replace_malloc.c:153) >==6579== by 0x4112F558: g_malloc (in /usr/lib/libglib-2.0.so.0.200.1) >==6579== by 0x4078531E: get_next_indirect (giop-send-buffer.c:273) >==6579== by 0x407853E3: giop_send_buffer_append_copy (giop-send-buffer.c:295) > >I think I would have been less likely to have missed it if the >"Address 0x4402E83E" line weren't indented. Here's a trivial patch to >de-indent address-info headers if the powers that be agree with me. > As a representative of the Powerless That Be, I would rather not see this patch applied as-is. It's already too difficult to scan past the fault records. On the other hand, I also agree with your complaint. Perhaps a half-indent? A special character in the first column? With respect to making fault records easier to scan past, I'd love to see either a newline after a fault record (so you can skip past paragraphs in the editor of your choice), or some fixed searchable text at the beginning of each record. |
|
From: Dirk M. <dm...@gm...> - 2003-08-06 17:28:07
|
On Mit, 06 Aug 2003, Rob Kramer wrote:
>
> When valgrinding my program, I get the following 2 loss records (sorry for
> lousy wrapping):
they're not lost:
> ==3356== 79218 bytes in 350 blocks are still reachable in loss record 6 of 6
^^^^^^^^^^^^^^^
It says "still reachable" here. The STL allocator is a wrapper around new
which tries to recycle memory in order to be faster. Therefore while the
memory won't be freed, its not lost (as it is "still reachable").
--
Dirk
|
|
From: Melchior F. <mf...@kd...> - 2003-08-06 15:52:29
|
* Noel Yap -- Wednesday 06 August 2003 17:35: > NOTICE: If received in error, please destroy and notify sender. I'd rather notify the sender first, and then destroy him. m. ;-) |
|
From: Noel Y. <Noe...@mo...> - 2003-08-06 15:36:00
|
I'd rather not have to click manually and print each page of the documentation. Is it available in PS or PDF or some other easily printable format anywhere? Thanks, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. |
|
From: Igmar P. <mai...@jd...> - 2003-08-06 07:52:49
|
> Yep... how about this: > > Q. My program dies with a segmentation fault, but Valgrind doesn't give > any error messages before it, or none that look related. > > A. The one kind of segmentation fault that Valgrind won't give any > warnings about is writes to read-only memory. Maybe your program is > writing to a static string like this: > > char* s = "hello"; > s[0] = 'j'; > > or something similar. > > Seem reasonable? Fine with me, if you're not experienced in debugging writing read-only mem and not knowing about it can give you a bad headache :) We might to add that writing to read-only mem makes LinuxThreads behave odd. Igmarx |
|
From: David E. <tw...@us...> - 2003-08-06 07:15:24
|
On Wed, 2003-08-06 at 06:15, Rob Kramer wrote:
> Hi,
>
> When valgrinding my program, I get the following 2 loss records (sorry for
> lousy wrapping):
>
> ==3356== 22248 bytes in 9 blocks are possibly lost in loss record 5 of 6
> ==3356== at 0x40013A09: __builtin_new (vg_replace_malloc.c:172)
> ==3356== by 0x40013A60: operator new(unsigned) (vg_replace_malloc.c:185)
> ==3356== by 0x402F253F: std::__default_alloc_template<true,
> 0>::_S_chunk_alloc(unsigned, int&)
> (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:109)
> ==3356== by 0x402F2448: std::__default_alloc_template<true,
> 0>::_S_refill(unsigned)
> (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:561)
> ==3356==
> ==3356==
> ==3356== 79218 bytes in 350 blocks are still reachable in loss record 6 of 6
> ==3356== at 0x40013A09: __builtin_new (vg_replace_malloc.c:172)
> ==3356== by 0x40013A60: operator new(unsigned) (vg_replace_malloc.c:185)
> ==3356== by 0x402F253F: std::__default_alloc_template<true,
> 0>::_S_chunk_alloc(unsigned, int&)
> (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:109)
> ==3356== by 0x402F2448: std::__default_alloc_template<true,
> 0>::_S_refill(unsigned)
> (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:561)
>
> I can't see where they originate.. Should I worry about this, or is this just
> an internal libstdc++ cleanup issue?
>
> Command line:
>
> valgrind -v --leak-check=yes --show-reachable=yes
> --suppressions=/usr/il/ismncc/rob.supp /usr/il/ismncc/ismncc
Add --num-callers=30 and run again. Increase number if needed.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Greg H.
|
After rooting through the valgrind source, I discovered that I am
blind, and the address info I coveted is displayed between two partial
stack traces:
==6579== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
==6579== at 0x40181C24: vgAllRoadsLeadToRome_writev (vg_intercept.c:108)
==6579== by 0x40181C60: __writev (vg_intercept.c:732)
==6579== by 0x407C311D: (within /usr/lib/liblinc.so.1.0.0)
==6579== by 0x407C32AB: linc_connection_writev (in /usr/lib/liblinc.so.1.0.0)
==6579== Address 0x4402E83E is 10 bytes inside a block of size 2048 alloc'd
==6579== at 0x4002942A: malloc (vg_replace_malloc.c:153)
==6579== by 0x4112F558: g_malloc (in /usr/lib/libglib-2.0.so.0.200.1)
==6579== by 0x4078531E: get_next_indirect (giop-send-buffer.c:273)
==6579== by 0x407853E3: giop_send_buffer_append_copy (giop-send-buffer.c:295)
I think I would have been less likely to have missed it if the
"Address 0x4402E83E" line weren't indented. Here's a trivial patch to
de-indent address-info headers if the powers that be agree with me.
--- mac_needs.c 2003-07-24 19:43:11.000000000 -0400
+++ mac_needs.c.new 2003-08-06 02:11:03.000000000 -0400
@@ -226,19 +226,19 @@
switch (ai->akind) {
case Stack:
VG_(message)(Vg_UserMsg,
- " Address 0x%x is on thread %d's stack",
+ "Address 0x%x is on thread %d's stack",
a, ai->stack_tid);
break;
case Unknown:
if (ai->maybe_gcc) {
VG_(message)(Vg_UserMsg,
- " Address 0x%x is just below %%esp. Possibly a bug in GCC/G++",
+ "Address 0x%x is just below %%esp. Possibly a bug in GCC/G++",
a);
VG_(message)(Vg_UserMsg,
- " v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes");
+ "v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes");
} else {
VG_(message)(Vg_UserMsg,
- " Address 0x%x is not stack'd, malloc'd or free'd", a);
+ "Address 0x%x is not stack'd, malloc'd or free'd", a);
}
break;
case Freed: case Mallocd: case UserG: {
@@ -255,7 +255,7 @@
relative = "inside";
}
VG_(message)(Vg_UserMsg,
- " Address 0x%x is %d bytes %s a block of size %d %s",
+ "Address 0x%x is %d bytes %s a block of size %d %s",
a, delta, relative,
ai->blksize,
ai->akind==Mallocd ? "alloc'd"
|
|
From: Rob K. <ro...@st...> - 2003-08-06 04:11:53
|
Hi, When valgrinding my program, I get the following 2 loss records (sorry for lousy wrapping): ==3356== 22248 bytes in 9 blocks are possibly lost in loss record 5 of 6 ==3356== at 0x40013A09: __builtin_new (vg_replace_malloc.c:172) ==3356== by 0x40013A60: operator new(unsigned) (vg_replace_malloc.c:185) ==3356== by 0x402F253F: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:109) ==3356== by 0x402F2448: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:561) ==3356== ==3356== ==3356== 79218 bytes in 350 blocks are still reachable in loss record 6 of 6 ==3356== at 0x40013A09: __builtin_new (vg_replace_malloc.c:172) ==3356== by 0x40013A60: operator new(unsigned) (vg_replace_malloc.c:185) ==3356== by 0x402F253F: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:109) ==3356== by 0x402F2448: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (/home/rob/gcc/build/i486-suse-linux/libstdc++-v3/include/bits/stl_alloc.h:561) I can't see where they originate.. Should I worry about this, or is this just an internal libstdc++ cleanup issue? Command line: valgrind -v --leak-check=yes --show-reachable=yes --suppressions=/usr/il/ismncc/rob.supp /usr/il/ismncc/ismncc Cheers, Rob |
|
From: Ranko Z. <ra...@sp...> - 2003-08-06 01:58:54
|
How about:
valgrind --gdb-attach=3Dyes your_prog
You can examine your code, backtrace and everything else before it genera=
tes
the core.
R.
> -----Original Message-----
> From: val...@li...
> [mailto:val...@li...]On Behalf Of
> Bor...@pd...
> Sent: 05 August 2003 11:16
> To: nj...@ca...
> Cc: val...@li...
> Subject: AW: [Valgrind-users] core for null pointer access
>
>
> I think a correct behaviour would be something to ask the user if he wa=
nts
> to get a core, wants to end the program, or continue with the execution
> beside the printing of the errortext together with a the stack output.
> The way valgrind handles this situation now, seems like a not well defi=
ned
> behaviour of valgrind in itself. With the above mentioned method, the u=
ser
> would be sure, that this is a bug of his program and not one of
> valgrind...which is really usefull, when the scenario for the Null-Poin=
ter
> Access gets much more complicated than my little example programm. For
> example by passing of an NULL pointer as function parameter through som=
e
> function calls. If you than only get a core for valgrind, I don't think
> every user will see the bug.
>
> Sincerely Borg Enders
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Nicholas Nethercote [mailto:nj...@ca...]
> Gesendet: Dienstag, 5. August 2003 10:08
> An: Enders, Borg
> Cc: val...@li...
> Betreff: Re: [Valgrind-users] core for null pointer access
>
>
> On Tue, 5 Aug 2003 Bor...@pd... wrote:
>
> > The following programm causes a core:
> > int main( int argc, char** argv )
> > {
> > int *a =3D NULL;
> >
> > int b =3D *a;
> >
> > return 0;
> > }
> >
> > Valgrind output:
> > =3D=3D26211=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector =
for
> > x86-linux. =3D=3D26211=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, =
by Julian
> > Seward. =3D=3D26211=3D=3D Using valgrind-20030725, a program supervis=
ion
> > framework for x86-linux. =3D=3D26211=3D=3D Copyright (C) 2000-2003, a=
nd GNU
> > GPL'd, by Julian Seward. =3D=3D26211=3D=3D Estimated CPU clock rate i=
s 699 MHz
> > =3D=3D26211=3D=3D For more details, rerun with: -v
> > =3D=3D26211=3D=3D
> > =3D=3D26211=3D=3D Invalid read of size 4
> > =3D=3D26211=3D=3D at 0x804844A: main (speicher_test.cc:23)
> > =3D=3D26211=3D=3D by 0x8048340: (within /home/benders/val2/tst/a.o=
ut)
> > =3D=3D26211=3D=3D Address 0x0 is not stack'd, malloc'd or free'd
> > Memory fault(coredump)
> >
> >
> > I think valgrind, should handle this problem correctly and not core b=
y
> > it's self.
>
> Really? What do you think would be the right way to handle this proble=
m
> correctly?
>
> N
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072
> 303_01/01
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Greg H.
|
This question doesn't seem to be addressed in the FAQ, and the list
archive appears to be broken right now ("Either your mailing list name
was misspelled or your mailing list has not been archived yet"), so I
will ask it here.
My question: how can I determine which bytes are uninitialized when I
see a "System call param writev(vector[...]) contains uninitialized or
unaddressable bytes(s)" message? If I can't determine that after the
fact, is there any way I can generate errors on uninitialized memory
copies and sort through those? Tweaking the valgrind source code is a
workable option for me, since I'm not using a prebuilt binary or
anything.
The background: I've been trying to run evolution 1.4 (compiled from
source with gcc 3.2.2 on a Red Hat 9 system) under valgrind 20030725,
to help diagnose some sporadic crashes which appear to result from
memory corruption. But I've run into an intermediate problem; right
when GConf2 starts up and tries to ping the existing gconfd using
ORBit2, I see:
==6351== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
If I attach to the process with gdb, I find that the iovecs parameter
contains two iovecs, one with 12 bytes and one with 84 bytes. Looking
at the code, the 96 bytes of data in the iovecs are assembled from a
wide variety of sources, all of which appear to be kosher, but it's
hard to be sure. If I continue past this point, the evolution
behavior under valgrind quickly departs from the normal observed
behavior--the gconf_engine_connect() db variable receives an
uninitialized value and I get a crash, where normally that variable
receives a valid value and evolution starts up fine. My guess is that
the uninitialized data in the iovecs (assuming there is any) is
receiving different values under valgrind, causing different behavior.
Thanks for all the good work.
|
|
From: Jeremy F. <je...@go...> - 2003-08-06 00:15:35
|
On Tue, 2003-08-05 at 15:44, Guilherme Lima wrote: > 1) Does "still reachable" report a real memory leak? I'm pretty sure this is a FAQ. The c++ library holds onto references to things, even after you call delete on them. So it isn't really a leak (especially since there's still a reference to the memory; no reference means "definitely lost"). > 2) Do "definitely lost" and "possibly lost" reports > always mean memory leaks? "Definitely lost" means that Valgrind couldn't find a pointer to the memory. It is possible to hide references which would confuse Valgrind, but its rarely a good idea. The most notorious example is using an "optimised" doubly-linked list where the forward and back pointers are xor'd together. > 3) Are there situations when "possibly lost" does not > come from a memory leak? If so, can someone post > a code snippet where such a situation has been > isolated? "Possibly lost" means that Valgrind found a pointer into the middle of an allocated block. This may or may not mean that the program knows how to release that memory, so it may or may not be a real leak. There are plenty of legitimate uses for pointers into the middle of a block. I think the C++ compiler uses it when you're dealing with multiple inheritance. Many private allocator implementations will allocate a block, stash some info at the beginning and then return a pointer to the rest of the block. It knows how to free this because it knows the allocated block starts at ptr-N, where N is the size of its header data. J |
|
From: Guilherme L. <li...@fn...> - 2003-08-05 22:44:32
|
Hi,
I am using valgrind 1.9.6 to analyse a small program:
----------------
1 #include <string>
2 using std::string;
3 int main() {
4 string leak("Does this cause a memory leak?");
5 string* ok = new string("This does not cause any memory leaks");
6 delete ok;
7 return 0;
8 }
-----------------
The commands:
> g++ -g -o test test.cpp
> valgrind --leak-check=yes --show-reachable=yes ./test
Shows:
----------------
...(removed)...
==3406== LEAK SUMMARY:
==3406== definitely lost: 0 bytes in 0 blocks.
==3406== possibly lost: 0 bytes in 0 blocks.
==3406== still reachable: 1920 bytes in 1 blocks.
==3406== suppressed: 0 bytes in 0 blocks.
----------------
The traceback points to line 4 in test.cpp source file.
The questions are:
1) Does "still reachable" report a real memory leak?
2) Do "definitely lost" and "possibly lost" reports
always mean memory leaks?
3) Are there situations when "possibly lost" does not
come from a memory leak? If so, can someone post
a code snippet where such a situation has been
isolated?
Thanks,
Guilherme
|
|
From: Jeremy F. <je...@go...> - 2003-08-05 16:50:12
|
On Tue, 2003-08-05 at 04:32, Nicholas Nethercote wrote: > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Valgrind caught a segmentation fault in your program, see last error > message for an explanation of what caused it; aborting. > > ? > > Presumably, if the client program has its own SIGSEGV handler, Valgrind > couldn't do this. Right, but it presumably has a good reason for having a SEGV handler. > One possible downside -- by not dumping core naturally, could you be > losing useful information (eg. where it happened) from the core file? I'm > not sure. Core dumps for seg faults within a client app running under > Valgrind are usually useless, though, as they occur in generated code. > Hmm. I actually do this in the syscall/signal patch. I set up a handler for all the signals which are SIG_DFL, and print a message if the result will be fatal. The obvious extension to this is to also print a stacktrace if it is a terminate w/ core signal (maybe a trace of all threads' stacks). You still need to take the signal so the process exits with the right exit code. The parent process may be relying on it. Obviously the coredump generated will be basically useless, since it is a coredump of your code as run by Valgrind, so gdb will have no idea of what to make of it. But the trace should help, along with previous messages. J |
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 15:04:01
|
On 5 Aug 2003, Paul A. Clarke wrote:
> I'd suggest that these recent threads about Valgrind not
> detecting/reporting invalid write attempts to read-only memory are at
> least justifications for adding something either to the FAQ or to the
> documentation (section 2.12, "Limitations"?), or both.
>
> I could take a stab at it, if someone in the project thinks it
> worthwhile, and nobody volunteers. (I'm not an expert in the area, but
> this is probably only a couple of sentences, right?)
Yep... how about this:
Q. My program dies with a segmentation fault, but Valgrind doesn't give
any error messages before it, or none that look related.
A. The one kind of segmentation fault that Valgrind won't give any
warnings about is writes to read-only memory. Maybe your program is
writing to a static string like this:
char* s = "hello";
s[0] = 'j';
or something similar.
Seem reasonable?
----
I've said that it's very hard/impossible to add such read-only write
checking to Valgrind's memory checker (Memcheck) without adding much
complexity and slowing it down more. However, it would be pretty easy to
write a new skin that checks specifically for this. It could be used as a
backup for Memcheck -- when you get a seg fault that Memcheck doesn't
diagnose, you could run your program through the new skin and (hopefully)
it would tell you where you wrote to read-only memory.
All this assumes that read-only writes are the only seg fault-causing
operations that Valgrind doesn't watch out for. I think this is true, but
not 100% certain.
N
|
|
From: Paul A. C. <pa...@us...> - 2003-08-05 14:48:50
|
I'd suggest that these recent threads about Valgrind not detecting/reporting invalid write attempts to read-only memory are at least justifications for adding something either to the FAQ or to the documentation (section 2.12, "Limitations"?), or both. I could take a stab at it, if someone in the project thinks it worthwhile, and nobody volunteers. (I'm not an expert in the area, but this is probably only a couple of sentences, right?) Regards, Paul Clarke On Tue, 2003-08-05 at 05:02, Nicholas Nethercote wrote: > It's actually the assignment to x[5] that cause the seg fault. Run your > core file through gdb to see. The reason is that you're writing to > read-only memory. There was a thread on this mailing list about this just > the other day called "detect writing to TOC(?)". The (well, my) > conclusion was that, yes, writing to read-only memory can cause seg > faults, but they're rare and detecting them would have a big performance > cost, so it's not worth it. AFAIK, writing to read-only memory is the > only way a program can seg fault without Valgrind giving a warning first. ... > As I said, the dump for the program above is caused by writing to > read-only memory. On Tue, 2003-08-05 at 09:10, Igmar Palsenberg wrote: > I've already requested this feature, since writing to read-only memory in > threads isn't debuggable by both gdb and valgrind. At least telling me > that the write is to read-only memory would help :) |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 14:10:37
|
> char* x = "test";
>
> x[5] = 'x'; // the same as above
>
> printf("%s\n", x ); // causes memory dump
No, it doesn't. The cause is the x[5] = 'x';, since that is a read-only
segment in memory. I never reaches the printf(), which gdb would tell you.
I've already requested this feature, since writing to read-only memory in
threads isn't debuggable by both gdb and valgrind. At least telling me
that the write is to read-only memory would help :)
Igmar
|
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:57:44
|
> > void f()
> > {
> > char a[4];
> > int *b;
> > int c;
> > b = &c;
> > a[5] = 123;
> > *b = 456;
> > }
> >
> > valgrind will tell you that the write through b is a problem,
> > but the real reason is the array overrun which valgrind cannot
> > detect, but which (indirectly) causes an array overrun.
>
> I just tried it, without problems, but that's probably due to GCC adding
> random padding between 'a' and 'b'.
GCC 3.x adds far more padding and alignment than 2.95.x does. No idea what
the reason is, but I observed that when debugging with code generated by
gcc -S
> You're right, I should have been more precise: if you get a seg fault due
> to an array overrun, Valgrind will always give you some related error
> message before the seg fault happens. Any objections to that statement? :)
I've seen a number of occasions when valgrind is totally of the track, all
of them with threaded apps screwing up each other stack. Gives nice
extremely hard to track problems :)
Igmar
|
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:54:02
|
> And that's the point, in this case valgrind knows, that the access after > this invalid read will cause a > Core dump, because you try to access a Null-Pointer and that it should tell > the user. Why all this trouble for a NULL pointer dereference ? If you can't debug those, you can't debug the rest. Most weird cores happen when doing something else, like double free()'s, screwing up TLS when using pthread's, etc. Adding code if thing would core is a a huge job to do. Most valgrind related core's I've seen come after a valgrind assert. > I really think valgrind is as great a memory checker as there is for free to > get, but it needs on some > Edges a little bit more work. > I'am working in a medium sized firm, and have installed valgrind for all of > our programmers, but some of them would always seek the fault by someone > else, before thinking that they could have made a fault... Reeducate your programmers. Take my word, valgrind cores are rare and mostly obvious. It it cores with valgrind, it usually also does without. Igmar |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:45:57
|
> I think a correct behaviour would be something to ask the user if he wants > to get a core, wants to end the program, or continue with the execution > beside the printing of the errortext together with a the stack output. That changes program behaviour, that's bad. After a core the program's state is undefined, so I see no reason to ask questions. The program will core, with or without valgrind. > The way valgrind handles this situation now, seems like a not well defined > behaviour of valgrind in itself. With the above mentioned method, the user > would be sure, that this is a bug of his program and not one of > valgrind...which is really usefull, when the scenario for the Null-Pointer > Access gets much more complicated than my little example programm. For > example by passing of an NULL pointer as function parameter through some > function calls. If you than only get a core for valgrind, I don't think > every user will see the bug. I debug complicated programs, and the above is the least of your programs, especially when threads are involved. Igmar |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 13:42:30
|
> The following programm causes a core:
> int main( int argc, char** argv )
> {
> int *a = NULL;
>
> int b = *a;
>
> return 0;
> }
It does. It should.
> Valgrind output:
> ==26211== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==26211== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==26211== Using valgrind-20030725, a program supervision framework for
> x86-linux.
> ==26211== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
> ==26211== Estimated CPU clock rate is 699 MHz
> ==26211== For more details, rerun with: -v
> ==26211==
> ==26211== Invalid read of size 4
> ==26211== at 0x804844A: main (speicher_test.cc:23)
> ==26211== by 0x8048340: (within /home/benders/val2/tst/a.out)
> ==26211== Address 0x0 is not stack'd, malloc'd or free'd
> Memory fault(coredump)
>
>
> I think valgrind, should handle this problem correctly and not core by it's
> self.
Valgrind is a part of your apps's addresspace. Valgrind doesn't core, your
app does. The current behaviour is correct, I can't think of any reason
to change it.
Igmar
|
|
From: Josef W. <Jos...@gm...> - 2003-08-05 12:08:57
|
On Tuesday 05 August 2003 13:32, Nicholas Nethercote wrote: > On Tue, 5 Aug 2003, Josef Weidendorfer wrote: > > Back to Valgrind: > > Valgrind's SEGFAULT handler should give out a precise error message after > > a SEGFAULT is catched, that this was because of application code. > > Obviously, Valgrind already contains such a message when the SEGFAULT > > appears in Valgrind code. The addition should be easy. > > Ok, would you (and Borg) be happy if instead of saying this: For me personally, this is no big issue. I'm totally fine with the current situation (I'm not using Valgrind that often, mainly because I can't use Valgrind in my Valgrind skin ;-). But IMHO, the error message below is much more user friendly. > > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Segmentation fault (core dumped) > > Valgrind said something like: > > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Valgrind caught a segmentation fault in your program, see last error > message for an explanation of what caused it; aborting. > > ? > > Presumably, if the client program has its own SIGSEGV handler, Valgrind > couldn't do this. Isn't it possible to inject some trap into the programs SIGSEGV handler, to allow for the error message? Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 11:32:33
|
On Tue, 5 Aug 2003, Josef Weidendorfer wrote: > Back to Valgrind: > Valgrind's SEGFAULT handler should give out a precise error message after a > SEGFAULT is catched, that this was because of application code. Obviously, > Valgrind already contains such a message when the SEGFAULT appears in Valgrind > code. The addition should be easy. Ok, would you (and Borg) be happy if instead of saying this: ==8968== Invalid write of size 4 ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) ==8968== by 0x8048264: ??? (start.S:81) ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd Segmentation fault (core dumped) Valgrind said something like: ==8968== Invalid write of size 4 ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) ==8968== by 0x8048264: ??? (start.S:81) ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd Valgrind caught a segmentation fault in your program, see last error message for an explanation of what caused it; aborting. ? Presumably, if the client program has its own SIGSEGV handler, Valgrind couldn't do this. One possible downside -- by not dumping core naturally, could you be losing useful information (eg. where it happened) from the core file? I'm not sure. Core dumps for seg faults within a client app running under Valgrind are usually useless, though, as they occur in generated code. Hmm. I'm not saying the change will happen, BTW -- lots of people have used Valgrind without finding the current situation problematic. But it's good to know what is the minimum change that would fix the perceived problem :) N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-05 10:55:26
|
> a good sign, but there are other, weirder ways of entering a function, > like jumps (used by dynamically linked libraries a lot) and > things like > pushing a functions start address and doing 'ret', and other horrible > things. The best way, AFAIK, is to rely on the symbol information. You got me thinking... I could think of setting a signal handler to the routine we want to call, raising that signal, and then modifying the stack and returning. Hmmm, I don't think I want to try that :) -- Vincent Penquerc'h |
|
From: Erik C. <er...@ar...> - 2003-08-05 10:53:33
|
On Tue, Aug 05, 2003 at 11:29:39AM +0100, Nicholas Nethercote wrote:
> >
> > void f()
> > {
> > char a[4];
> > int *b;
> > int c;
> > b = &c;
> > a[5] = 123;
> > *b = 456;
> > }
> >
> > valgrind will tell you that the write through b is a problem,
> > but the real reason is the array overrun which valgrind cannot
> > detect, but which (indirectly) causes an array overrun.
>
> I just tried it, without problems, but that's probably due to GCC adding
> random padding between 'a' and 'b'.
I think it could be because I got the stack growth direction wrong.
This one crashes like it should.
void main()
{
int *b;
char a[4];
int c;
b = &c;
a[7] = 123; // Oops!
*b = 456; // Boom!
}
> You're right, I should have been more precise: if you get a seg fault due
> to an array overrun, Valgrind will always give you some related error
> message before the seg fault happens. Any objections to that statement? :)
No objection. Valgrind gives an error message before the seg fault.
Unfortunately the error message relates to the "Boom" and not the
"Oops" line, so it's not very useful in this sort of case. The
only answer is a version of gcc with fat pointers like the one I
linked to.
By the way, I don't think Purify or Electric Fence can catch this
one either, and the nasty thing about it is that it's often a latent
bug that waits for the right (wrong) input, so you can't catch it
except by sitting down and reasoning about the program. That applies
even to Java, where you can easily get the array bounds exception far
too late (after the program started being used for real work).
--
Erik Corry er...@ar...
|