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
(8) |
2
(1) |
3
(3) |
4
(3) |
|
5
(2) |
6
(7) |
7
(1) |
8
(9) |
9
(7) |
10
(9) |
11
(2) |
|
12
(5) |
13
(8) |
14
(19) |
15
(8) |
16
(25) |
17
(9) |
18
(6) |
|
19
(11) |
20
(2) |
21
(10) |
22
(13) |
23
(7) |
24
(6) |
25
(3) |
|
26
|
27
(2) |
28
(1) |
29
(4) |
30
(7) |
31
(5) |
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-12 17:16:55
|
On Thu, 25 Sep 2003, Dirk Mueller wrote: > On Thursday 25 September 2003 13:12, Szabo Peter wrote: > > > Please implement the ENTER and LEAVE assembly instructions. > > LEAVE is already implemented, however ENTER is indeed missing. I'm not sure if this was announced: ENTER was implemented in the CVS HEAD a couple of weeks ago. Thanks to Dirk Mueller for doing it. N |
|
From: Tom H. <th...@cy...> - 2003-10-11 23:07:55
|
In message <Pin...@jd...>
Derick Rethans <d.r...@jd...> wrote:
> On Mon, 6 Oct 2003, Tom Hughes wrote:
>
> > Either upgrade to a more recent version or set LD_ASSUME_KERNEL to
> > 2.4.1 in your environment and it should work.
>
> I upgraded to the latest available download (20030725) which seems to
> work when I set the LD_ASSUME_KERNEL env var. Thanks.
The latest versions should set LD_ASSUME_KERNEL for you anyway.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Derick R. <d.r...@jd...> - 2003-10-11 21:34:30
|
On Mon, 6 Oct 2003, Tom Hughes wrote: > Either upgrade to a more recent version or set LD_ASSUME_KERNEL to > 2.4.1 in your environment and it should work. I upgraded to the latest available download (20030725) which seems to work when I set the LD_ASSUME_KERNEL env var. Thanks. reagrds, Derick -- ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ International PHP Magazine http://www.php-mag.net/ ------------------------------------------------------------------------- |
|
From: Geoff A. <gal...@nc...> - 2003-10-10 20:41:18
|
> I'm running Redhat Linux 7.1 (2.4.2-2) and was using the > GNUpro 03r1 compiler (a "commerical" version of gcc 3.2 > -- since I'm under Redhat 7.1, it uses gnulibc2.2). It looks like the #ifdef problem in vg_intercept.c that I originally = reported on 07/16/03 . You need to replace #ifdef GLIBC_2_1 #include <sys/time.h> #endif with #include <sys/time.h> Geoff Alexander |
|
From: Nicholas N. <nj...@ca...> - 2003-10-10 15:46:38
|
On Fri, 10 Oct 2003 e1-...@em... wrote: > Question: how do I suppress this error in my logs? I can't seem to > figure out the right incantation to get Valgrind to ignore this error. See FAQ #17 N |
|
From: <e1-...@em...> - 2003-10-10 15:35:54
|
Hi,
Valgrind-20030725 gives me the following output when I run my program through it:
==23303== Thread 5:
==23303== Syscall param socketcall.setsockopt(optval) contains uninitialised or unaddressable byte(s)
==23303== at 0x420E8472: setsockopt (in /lib/i686/libc-2.2.5.so)
==23303== by 0x8066488: set_pcap_filter__13LwxCdbHandler (CdbHandler.cc:367)
==23303== by 0x806631E: open_pcap__13LwxCdbHandler (CdbHandler.cc:331)
==23303== by 0x8065CB3: __13LwxCdbHandlerPC6StringUi18LwxIfEffectiveType (CdbHandler.cc:140)
==23303== by 0x8054119: handle_new_if__9IfHandlerP9IfhIfInfo (ifhandler.cc:767)
==23303== by 0x8053550: compare_if_list_diffs__9IfHandler (ifhandler.cc:432)
==23303== by 0x8052F0F: if_loop__9IfHandler (ifhandler.cc:232)
==23303== by 0x8052C06: pthread_if_loop (ifhandler.cc:159)
==23303== by 0x4026E6C3: thread_wrapper (vg_libpthread.c:667)
==23303== by 0x40174943: (within /usr/local/lib/valgrind/valgrind.so)
==23303== Address 0x41BC4CFE is on thread 5's stack
My program is written in C++, and what you are seeing are the demangled symbols. Also, my program is using the well-known "pcap" library for low level packet handling.
(other programs that use libpcap seem to exhibit this problem as well).
Question: how do I suppress this error in my logs? I can't seem to figure out the right incantation to get Valgrind to ignore this error. My best guess so far is this:
{
this_is_just_a_comment
Addrcheck,Memcheck:Param
socketcall.setsockopt(optval)
fun:set_pcap_filter__13LwxCdbHandler
fun:open_pcap__13LwxCdbHandler
fun:*
}
I have to confess that I don't totally understand the syntax of Valgrind's suppression file format yet.
Thanks for any help!
--kevin
|
|
From: Olly B. <ol...@su...> - 2003-10-10 15:17:12
|
On Fri, Oct 10, 2003 at 04:00:17PM +0100, Nicholas Nethercote wrote:
> Could you be leaking zero-sized heap blocks? If you do leak a zero-sized
> block, you really are losing memory because every heap block has
> administration bytes at the start and end.
It occurs to me that VALGRIND_COUNT_LEAKS has a flaw, as it tells you
how many bytes were leaked, not how many blocks. So it'll effectively
ignore leaks of zero-sized blocks...
Cheers,
Olly
|
|
From: Lee K. <lki...@cs...> - 2003-10-10 15:10:19
|
Russ Fink writes:
> Semantically, if I lose zero bytes, then I'm not leaking. I don't believe
> my logic, though - I believe a leak is taking place, but for some reason,
> Valgrind is unable to quantify the amount being leaked.
Because it's perfectly valid (if non-portable) to allocate memory of a
size 0 bytes! Such an allocation still consumes system resources
(i.e. the list of memory blocks alloacted). Consider the program:
#include <stdlib.h>
#include <stdio.h>
void main(void)
{
void *ptr = malloc(0);
printf("%p\n", ptr);
}
And the Valgrind run:
==11300== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==11300== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==11300== Using valgrind-20030725, a program supervision framework for x86-linux.
==11300== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==11300== Estimated CPU clock rate is 1911 MHz
==11300== For more details, rerun with: -v
==11300==
0x411ba024
==11300==
==11300== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==11300== malloc/free: in use at exit: 0 bytes in 1 blocks.
==11300== malloc/free: 1 allocs, 0 frees, 0 bytes allocated.
==11300== For counts of detected errors, rerun with: -v
==11300== searching for pointers to 1 not-freed blocks.
==11300== checked 3635076 bytes.
==11300==
==11300== 0 bytes in 1 blocks are definitely lost in loss record 1 of 1
==11300== at 0x4002942A: malloc (vg_replace_malloc.c:153)
==11300== by 0x8048375: main (test.c:6)
==11300== by 0x40257A46: __libc_start_main (in /lib/libc-2.3.2.so)
==11300== by 0x80482CC: ??? (start.S:81)
==11300==
==11300== LEAK SUMMARY:
==11300== definitely lost: 0 bytes in 1 blocks.
==11300== possibly lost: 0 bytes in 0 blocks.
==11300== still reachable: 0 bytes in 0 blocks.
==11300== suppressed: 0 bytes in 0 blocks.
==11300== Reachable blocks (those to which a pointer was found) are not shown.
==11300== To see them, rerun with: --show-reachable=yes
==11300==
Does this clear things up?
L.
|
|
From: Derick R. <d.r...@jd...> - 2003-10-10 15:08:32
|
On Fri, 10 Oct 2003, Joshua Moore-Oliva wrote: > I think the source of your problems comes from this bit > > <snip> > > ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. > </snip> > > try fixing that up first and I think the second error should go away :). You > have more frees than allocs. 24202 - 20972 is still greater than 0 for me ;-) Derick -- ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ International PHP Magazine http://www.php-mag.net/ ------------------------------------------------------------------------- |
|
From: Joshua Moore-O. <jo...@ch...> - 2003-10-10 15:02:52
|
I think the source of your problems comes from this bit <snip> > ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. </snip> try fixing that up first and I think the second error should go away :). You have more frees than allocs. Josh. |
|
From: Nicholas N. <nj...@ca...> - 2003-10-10 15:00:20
|
On Fri, 10 Oct 2003, Russ Fink wrote: > I'm a semi-newbie to valgrind, and a positive newbie to the application I'm > debugging. I'm getting a message from Valgrind that I don't understand; can > you help me? > > I'm running with --leak-check=yes, --show-reachable=yes. Valgrind is > saying: > > ==5843== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==5843== malloc/free: in use at exit: 3036062 bytes in 3230 blocks. > ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. > ==5843== For counts of detected errors, rerun with: -v > ==5843== searching for pointers to 3230 not-freed blocks. > ==5843== checked 6748468 bytes. > ==5843== > ==5843== 0 bytes in 383 blocks are definitely lost in loss record 1 of 9 > ==5843== at 0x4002B905: malloc (vg_replace_malloc.c:153) > ==5843== by 0x80507F8: ... > > What does it mean, "0 bytes in 383 blocks are definitely lost?" > Semantically, if I lose zero bytes, then I'm not leaking. I don't believe > my logic, though - I believe a leak is taking place, but for some reason, > Valgrind is unable to quantify the amount being leaked. Could you be leaking zero-sized heap blocks? If you do leak a zero-sized block, you really are losing memory because every heap block has administration bytes at the start and end. N |
|
From: Russ F. <rus...@ho...> - 2003-10-10 14:47:59
|
I'm a semi-newbie to valgrind, and a positive newbie to the application I'm debugging. I'm getting a message from Valgrind that I don't understand; can you help me? I'm running with --leak-check=yes, --show-reachable=yes. Valgrind is saying: ==5843== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==5843== malloc/free: in use at exit: 3036062 bytes in 3230 blocks. ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. ==5843== For counts of detected errors, rerun with: -v ==5843== searching for pointers to 3230 not-freed blocks. ==5843== checked 6748468 bytes. ==5843== ==5843== 0 bytes in 383 blocks are definitely lost in loss record 1 of 9 ==5843== at 0x4002B905: malloc (vg_replace_malloc.c:153) ==5843== by 0x80507F8: ... What does it mean, "0 bytes in 383 blocks are definitely lost?" Semantically, if I lose zero bytes, then I'm not leaking. I don't believe my logic, though - I believe a leak is taking place, but for some reason, Valgrind is unable to quantify the amount being leaked. Has this been seen before? If so, what does it mean, and what more should I do to my application to get clearer results? Thanks, Russ Fink _________________________________________________________________ Express yourself with MSN Messenger 6.0 -- download now! http://www.msnmessenger-download.com/tracking/reach_general |
|
From: John R. <joh...@cr...> - 2003-10-09 17:57:48
|
Thanks! The patch works, the thing builds now. John Roberts joh...@cr... > X-pair-Authenticated: 24.126.73.164 > Date: Thu, 09 Oct 2003 10:35:12 -0700 > From: Dan Kegel <da...@ke...> > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 > X-Accept-Language: de-de, en > MIME-Version: 1.0 > To: John Roberts <joh...@cr...> > Cc: val...@li... > Subject: [patch] autoconfisticate vg_intercept.c a bit more (was: problems building Valgrind 20030725 snapshot) > Content-Transfer-Encoding: 7bit > X-BigFish: pcs-20(z335R60ei533jba6iz98dW122eH166cizzzzz)v > > John Roberts wrote: > > I'm running Redhat Linux 7.1 (2.4.2-2) and was using the > > GNUpro 03r1 compiler (a "commerical" version of gcc 3.2 > > -- since I'm under Redhat 7.1, it uses gnulibc2.2). > > ... > > ../../valgrind-20030725/coregrind/vg_intercept.c:284: sizeof applied to an > > incomplete type > > I bet the problem is vg_intercept.c should include <sys/time.h>, > but doesn't always. Try this patch and let us know if it helps. > > --- valgrind-20030725/coregrind/vg_intercept.c.old Thu Oct 9 09:09:38 2003 > +++ valgrind-20030725/coregrind/vg_intercept.c Thu Oct 9 09:10:24 2003 > @@ -65,7 +65,7 @@ > #include <sys/poll.h> > #include <sys/socket.h> > #include <sys/uio.h> > -#ifdef GLIBC_2_1 > +#ifdef HAVE_SYS_TIME_H > #include <sys/time.h> > #endif > > > - Dan > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > |
|
From: Dan K. <da...@ke...> - 2003-10-09 16:58:58
|
John Roberts wrote: > I'm running Redhat Linux 7.1 (2.4.2-2) and was using the > GNUpro 03r1 compiler (a "commerical" version of gcc 3.2 > -- since I'm under Redhat 7.1, it uses gnulibc2.2). > ... > ../../valgrind-20030725/coregrind/vg_intercept.c:284: sizeof applied to an > incomplete type I bet the problem is vg_intercept.c should include <sys/time.h>, but doesn't always. Try this patch and let us know if it helps. --- valgrind-20030725/coregrind/vg_intercept.c.old Thu Oct 9 09:09:38 2003 +++ valgrind-20030725/coregrind/vg_intercept.c Thu Oct 9 09:10:24 2003 @@ -65,7 +65,7 @@ #include <sys/poll.h> #include <sys/socket.h> #include <sys/uio.h> -#ifdef GLIBC_2_1 +#ifdef HAVE_SYS_TIME_H #include <sys/time.h> #endif - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Nicholas N. <nj...@ca...> - 2003-10-09 16:44:31
|
On Thu, 9 Oct 2003, John Roberts wrote: > I'm new to Valgrind-land and I downloaded the 20030725 > snapshot and tried to build it, but got compile errors. > (See end of message.) > > I'm running Redhat Linux 7.1 (2.4.2-2) and was using the > GNUpro 03r1 compiler (a "commerical" version of gcc 3.2 > -- since I'm under Redhat 7.1, it uses gnulibc2.2). Can you try a more normal version of GCC? AFAIK, nobody else has had problems... N |
|
From: John R. <joh...@cr...> - 2003-10-09 16:13:59
|
Hi, I'm new to Valgrind-land and I downloaded the 20030725 snapshot and tried to build it, but got compile errors. (See end of message.) I'm running Redhat Linux 7.1 (2.4.2-2) and was using the GNUpro 03r1 compiler (a "commerical" version of gcc 3.2 -- since I'm under Redhat 7.1, it uses gnulibc2.2). Any suggestions? thanks, John Roberts joh...@cr... ---------------------------------------------------------- if gcc -DHAVE_CONFIG_H -I. -I../../valgrind-20030725/coregrind -I.. -I../../valgrind-20030725/coregrind/demangle -I../../valgrind-20030725/include -DVG_LIBDIR="\"/export/home/valgrind/lib"\" -Winline -Wall -Wshadow -O -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -mpreferred-stack-boundary=2 -fno-omit-frame-pointer -MT vg_intercept.o -MD -MP -MF ".deps/vg_intercept.Tpo" \ -c -o vg_intercept.o `test -f '../../valgrind-20030725/coregrind/vg_intercept.c' || echo '../../valgrind-20030725/coregrind/'`../../valgrind-20030725/coregrind/vg_interc ept.c; \ then mv ".deps/vg_intercept.Tpo" ".deps/vg_intercept.Po"; \ else rm -f ".deps/vg_intercept.Tpo"; exit 1; \ fi ../../valgrind-20030725/coregrind/vg_intercept.c: In function `vgAllRoadsLeadToRome_poll': ../../valgrind-20030725/coregrind/vg_intercept.c:284: sizeof applied to an incomplete type ../../valgrind-20030725/coregrind/vg_intercept.c: In function `vgAllRoadsLeadToRome_select': ../../valgrind-20030725/coregrind/vg_intercept.c:562: sizeof applied to an incomplete type ../../valgrind-20030725/coregrind/vg_intercept.c:573: dereferencing pointer to incomplete type ../../valgrind-20030725/coregrind/vg_intercept.c:573: dereferencing pointer to incomplete type ../../valgrind-20030725/coregrind/vg_intercept.c:593: dereferencing pointer to incomplete type ../../valgrind-20030725/coregrind/vg_intercept.c:594: dereferencing pointer to incomplete type make[3]: *** [vg_intercept.o] Error 1 make[3]: Leaving directory `/export/home/valgrind-build/coregrind' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/export/home/valgrind-build/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/home/valgrind-build' make: *** [all] Error 2 |
|
From: Nicholas N. <nj...@ca...> - 2003-10-09 15:41:08
|
On Thu, 9 Oct 2003, Sven Verdoolaege wrote:
> I have a problem with valgrind reporting a mismatched free / delete /
> delete[]
>
> This is a small example:
> > cat testnew.cc
> #include <new>
>
> int main()
> {
> int * a = new (std::nothrow) int[5];
> delete [] a;
> }
>
> > valgrind ./testnew
> ==22317== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==22317== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==22317== Using valgrind-20030725, a program supervision framework for x86-linux.
> ==22317== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
> ==22317== Estimated CPU clock rate is 1343 MHz
> ==22317== For more details, rerun with: -v
> ==22317==
> ==22317== Mismatched free() / delete / delete []
> ==22317== at 0x4002BB42: __builtin_vec_delete (vg_replace_malloc.c:252)
> ==22317== by 0x4002BB6D: operator delete[](void*) (vg_replace_malloc.c:261)
> ==22317== by 0x804846B: main (in /home/skimo/obj/barvinok/testnew)
> ==22317== by 0x403599EC: __libc_start_main (in /lib/libc.so.6)
> ==22317== Address 0x414A60D4 is 0 bytes inside a block of size 20 alloc'd
> ==22317== at 0x4002B721: malloc (vg_replace_malloc.c:153)
> ==22317== by 0x402E7F9A: operator new(unsigned, std::nothrow_t const&) (../../../../../src/gcc-3.3.1/libstdc++-v3/libsupc++/new_opnt.cc:47)
> ==22317== by 0x402E8065: operator new[](unsigned, std::nothrow_t const&) (../../../../../src/gcc-3.3.1/libstdc++-v3/libsupc++/new_opvnt.cc:36)
> ==22317== by 0x8048457: main (in /home/skimo/obj/barvinok/testnew)
>
> Is this a bug in gcc or in my program ?
Neither; it's a problem with Valgrind. Valgrind should be overriding
'operator new[](unsigned, std::nothrow_t)'.
> Is there a work-around ?
I've just committed a fix to CVS HEAD. Grab it using the instructions in
README. Note that the SF.net CVS server is very unreliable, you might
need multiple attempts to check it out successfully.
N
|
|
From: Roberto S. <ro...@mu...> - 2003-10-09 12:05:02
|
I forgot to attach the test program -- Roberto Sebastiano <ro...@mu...> |
|
From: Wim G. <wim...@ua...> - 2003-10-09 07:41:28
|
Got the same result (i.e. nothing) on the following system redhat 7.2 kernel 2.4.17 glibc 2.2.4-19.3 gcc-2.96 with valgrind 1.0.4 valgrind 1.9.6 needs at least glibc 2.3 so won't install On Wed, 2003-10-08 at 17:47, Ivan Pulleyn wrote: > Are you running valgrind with -v --leak-check=yes --show-reachable=yes > flags? > > Ivan... > > On Wed, 2003-10-08 at 08:22, Wim Glassee wrote: > > Thanks for testing Olly. > > > > I'm using gcc 3.2.2 (the latest redhat kind) > > glibc 2.3.2-27.9 > > > > > > compiled without optimisation: gcc -o test test.c > > > > Just tried with valgrind 1.0.4, but it won't run, it complains that it > > couldn't find couldn't find 'client's argc/argc/envp' > > > > Wim > > > > On Wed, 2003-10-08 at 16:41, Olly Betts wrote: > > > On Wed, Oct 08, 2003 at 04:17:32PM +0200, Wim Glassee wrote: > > > > valgrind --leak-check=yes --leak-resolution=high > > > > > > What version of valgrind? What version of gcc? What gcc command line > > > options did you use? What version of glibc? > > > > > > I can't reproduce your problem with valgrind-20030725 and gcc 2.95.4 or > > > 3.3, with -O, -O2, -O3 or without optimisation. That's using glibc 2.2.5. > > > > > > I get output from the program and memory leaks reported. > > > > > > Cheers, > > > Olly > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > SourceForge.net hosts over 70,000 Open Source Projects. > > See the people who have HELPED US provide better services: > > Click here: http://sourceforge.net/supporters.php > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dirk M. <dm...@gm...> - 2003-10-08 20:36:51
|
On Wednesday 08 October 2003 17:22, Wim Glassee wrote: > We might be on to something here well, your report shows that valgrind was not able to hook into your memory allocator. All people I've heard of with this problem were using the (broken) RH 9. does it work when you export LD_ASSUME_KERNEL=2.4.1 ? |
|
From: Roberto S. <ro...@mu...> - 2003-10-08 17:34:22
|
I did some tests to isolate the problem
In fact, the first program against tested with valgrind had a problem of
uninitialized memory on the first run of the loop
That problem triggers another problem, this one inside valgrind it
seems; recalling the output of gdb:
==8200== Conditional jump or move depends on uninitialised value(s)
==8200== at 0x804C031: main (lookt2.c:1243)
==8200== by 0x40267DBD: __libc_start_main (in /lib/libc-2.3.2.so)
==8200== by 0x8048D60: (within /pub/dev/lookthrough/new/lookt2)
==8200==
==8200== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==8200== starting GDB with cmd: /usr/bin/gdb -nw /proc/8200/exe 8200
GNU gdb 5.3.90_2003-08-24-cvs-debian
...
vg_do_syscall3 (syscallno=4294966784, arg1=8228, arg2=0, arg3=0)
at vg_mylibc.c:92
92 vg_mylibc.c: No such file or directory.
in vg_mylibc.c
(gdb) bt
#0 vg_do_syscall3 (syscallno=4294966784, arg1=8228, arg2=0, arg3=0)
at vg_mylibc.c:92
#1 0x40191b7d in vgPlain_system (
cmd=0xbffff830 "/usr/bin/gdb -nw /proc/8200/exe 8200") at
vg_mylibc.c:1277
#2 0x4018d727 in vgPlain_start_GDB_whilst_on_client_stack () at
vg_main.c:1821
#3 0x40194e48 in vgPlain_swizzle_esp_then_start_GDB ()
from /usr/lib/valgrind/valgrind.so
#4 0xbffff938 in ?? ()
#5 0x0804c031 in main (argc=134534236, argv=0x0) at lookt2.c:1243
As you see, the frame n#5 has argc screwed up, and frame n#4 is
sospicious
Debugging from now on leads to unpredictable results
It turns out that any gdb session attached from valgrind is non-usable
The simple program attached here when debugged under valgrind has this
back trace:
#0 vg_do_syscall3 (syscallno=4294966784, arg1=2284, arg2=0, arg3=0)
at vg_mylibc.c:92
#1 0x40191b7d in vgPlain_system (
cmd=0xbffff7d0 "/usr/bin/gdb -nw /proc/2283/exe 2283") at
vg_mylibc.c:1277
#2 0x4018d727 in vgPlain_start_GDB_whilst_on_client_stack () at
vg_main.c:1821
#3 0x40194e48 in vgPlain_swizzle_esp_then_start_GDB ()
from /usr/lib/valgrind/valgrind.so
#4 0xbffff998 in ?? ()
#5 0x40021dca in strcpy (dst=0x0, src=0x0) at mac_replace_strmem.c:173
Previous frame identical to this frame (corrupt stack?)
That turns out to be bug 1406 already filled in at
http://sources.redhat.com/cgi-bin/gnatsweb.pl
This happens also on debian unstable with
gdb 5.3.90_2003-08-24-cvs-debian, valgrind 20030725-5 and libc 2.3.2-8
Along with the bug report, there's a suggestion from Mark Kettenis for a
fix in valgrind:
"There's something rather suspicious about frame #4; I doubt that
you're really executing code on the stack. It's defenitely more
likely that GDB is unable to properly unwind frame #3. I took a quick
look at valgrind, and vgPlain_swizzle_esp_then_start_GDB() is
hand-coded assembler that fiddles with the stack. I'm not surprised
that GDB chockes on this, and teaching GDB to properly unwind this
particular frame is very difficult. It's properly a better idea to
ask the author of valgrind to add DWARF Call Frame Info (DWARF CFI) to
this particular bit of code."
It would be a waste to have a tool like this not working on debian
Hope that helps
--
Roberto Sebastiano <ro...@mu...>
|
|
From: Wim G. <wim...@ua...> - 2003-10-08 15:23:34
|
Thanks for testing Olly. I'm using gcc 3.2.2 (the latest redhat kind) glibc 2.3.2-27.9 compiled without optimisation: gcc -o test test.c Just tried with valgrind 1.0.4, but it won't run, it complains that it couldn't find couldn't find 'client's argc/argc/envp' Wim On Wed, 2003-10-08 at 16:41, Olly Betts wrote: > On Wed, Oct 08, 2003 at 04:17:32PM +0200, Wim Glassee wrote: > > valgrind --leak-check=yes --leak-resolution=high > > What version of valgrind? What version of gcc? What gcc command line > options did you use? What version of glibc? > > I can't reproduce your problem with valgrind-20030725 and gcc 2.95.4 or > 3.3, with -O, -O2, -O3 or without optimisation. That's using glibc 2.2.5. > > I get output from the program and memory leaks reported. > > Cheers, > Olly |
|
From: Wim G. <wim...@ua...> - 2003-10-08 15:23:09
|
Tried changing the number to 10 with the same result
I tried with valgrind 1.9.6, and with the latest, i.e. 20030725
On redhat linux 2.4.20-19.9
I'll try to test with an older version.
We might be on to something here
On Wed, 2003-10-08 at 16:32, Gao, Jiafu wrote:
> It works for me. I changed the big number to 10, valgrind gives "definitely
> lost of 160 bytes". It is precisely correct.
>
> I am using an old valgrind 1.0.4, linux 2.4.20.
>
> Did you try change the big number to a smaller one? Maybe it is a
> integer/float overflow problem.
>
> Jiafu
>
> -----Original Message-----
> From: Wim Glassee [mailto:wim...@ua...]
> Sent: Wednesday, October 08, 2003 10:18 AM
> To: val...@li...
> Subject: [Valgrind-users] strdup unnoticed
>
>
> Hi all,
>
> I seem to be having a problem.
>
> Running the code:
>
> #include <string.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> void test()
> {
> char * test = "ABCDEFGHIJKLMNO";
> char * piep;
>
> piep = strdup(test);
> piep = strdup(test);
> printf( "%s\n", piep );
> free(piep);
> }
>
> int main( int argc, char ** argv )
> {
> int i;
> for( i = 0; i < 10000000; i++ )
> {
> test();
> }
> return 0;
> }
>
> should print out the abc... string a zillion times to the screen, while
> creating memory leaks on the way.
>
> Running this in valgrind doesn't give ANY program output, and says no leaks
> are possible seeing as no malloc has been done. Apparently it doesn't check
> inside strdup. This doesn't explain for the no-output problem though.
>
> I used:
>
> valgrind --leak-check=yes --leak-resolution=high
>
> Anybody have any ideas?
>
> Thanks in advance,
>
> Wim
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf _______________________________________________
> Valgrind-users mailing list Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited.
>
|
|
From: Olly B. <ol...@su...> - 2003-10-08 14:41:43
|
On Wed, Oct 08, 2003 at 04:17:32PM +0200, Wim Glassee wrote:
> valgrind --leak-check=yes --leak-resolution=high
What version of valgrind? What version of gcc? What gcc command line
options did you use? What version of glibc?
I can't reproduce your problem with valgrind-20030725 and gcc 2.95.4 or
3.3, with -O, -O2, -O3 or without optimisation. That's using glibc 2.2.5.
I get output from the program and memory leaks reported.
Cheers,
Olly
|
|
From: Gao, J. <JG...@se...> - 2003-10-08 14:33:06
|
It works for me. I changed the big number to 10, valgrind gives "definitely
lost of 160 bytes". It is precisely correct.
I am using an old valgrind 1.0.4, linux 2.4.20.
Did you try change the big number to a smaller one? Maybe it is a
integer/float overflow problem.
Jiafu
-----Original Message-----
From: Wim Glassee [mailto:wim...@ua...]
Sent: Wednesday, October 08, 2003 10:18 AM
To: val...@li...
Subject: [Valgrind-users] strdup unnoticed
Hi all,
I seem to be having a problem.
Running the code:
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
void test()
{
char * test = "ABCDEFGHIJKLMNO";
char * piep;
piep = strdup(test);
piep = strdup(test);
printf( "%s\n", piep );
free(piep);
}
int main( int argc, char ** argv )
{
int i;
for( i = 0; i < 10000000; i++ )
{
test();
}
return 0;
}
should print out the abc... string a zillion times to the screen, while
creating memory leaks on the way.
Running this in valgrind doesn't give ANY program output, and says no leaks
are possible seeing as no malloc has been done. Apparently it doesn't check
inside strdup. This doesn't explain for the no-output problem though.
I used:
valgrind --leak-check=yes --leak-resolution=high
Anybody have any ideas?
Thanks in advance,
Wim
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Valgrind-users mailing list Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.
|