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
(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: 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 |