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: Wim G. <wim...@ua...> - 2003-10-08 14:18:30
|
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
|
|
From: Durai B.
|
----- Original Message ----- From: "Tom Hughes" <th...@cy...> To: <val...@li...> Sent: Monday, October 06, 2003 12:40 AM Subject: Re: [Valgrind-users] Invalid free/delete/delete[]? > In message <00bc01c38bda$5dc5a070$6501a8c0@guindy> > Durai Balusamy <durai.balusamy@Sun.COM> wrote: > > > What does 'invalid free()/delete/delete[]' mean in valgrind output. > > Is it a memory corruption or stack overflow or double free? > > It means that the pointer passed to free/delete is not one that was > previously returned from malloc/new, or if it is then it has already > been freed. valgrind reported it correct and it turned out to be a pointer casting issue. > > > If it is a memory corruption or a double free, is there a way to > > find out which part of the code causes this crash? > > That depends on the cause - if it's a double free then you'll have > to try and catch the allocation in the debugger based on valgrind's > information about the block and then try and break on frees of that > block so you find the first and second frees. > > If it's just that you are trying to free a bogus pointer then you'll > have to use valgrind's information about both the location of the free > and the pointer being freed to track back to the source of the problem. > > > Also I have to use libpthead provided by valgrind package. Initially > > I ran without valgrind's libpthread and it reported the Invalid read > > errors. But when I used libpthread, it did not report those invalid > > read errors? Am I doing anything wrong? > > I'm astonished that anything worked at all if you didn't use valgrind's > libpthread, as the real one will call the clone system call which valgrind > is not able to handle. Yes you are correct. What I was trying to say is that it reported many invalid read errors without valgrind libpthread library but exited the process to link with valgrind libpthread library. When I ran my program thru' valgrind libpthread, it didnt complain about the invalid read errors. -durai. > > > ==7857== Invalid free() / delete / delete[] > > ==7857== at 0x4002BCB7: __builtin_delete (vg_replace_malloc.c:233) > > ==7857== by 0x4064D938: String::~String(void) (XSLString.cpp:356) > > ==7857== by 0x40611791: PathExpr::~PathExpr(void) (PathExpr.cpp:51) > > ==7857== by 0x4064C70E: NamedMap::clear(int) (NamedMap.cpp:115) > > ==7857== Address 0x5E5AF728 is 12 bytes inside a block of size 28 alloc'd > > ==7857== at 0x4002BA38: __builtin_new (vg_replace_malloc.c:172) > > ==7857== by 0x40608A0B: ExprParser::createExpr(ExprLexer &) (ExprParser.cpp:319) > > ==7857== by 0x40607A4B: ExprParser::createExpr(String const &) (ExprParser.cpp:160) > > ==7857== by 0x405E6568: ProcessorState::getExpr(String const &) (ProcessorState.cpp:450) > > So valgrind is reporting here that you are freeing a pointer that > doesn't point to the start of a block, but rather 12 bytes inside > one. That might mean that you have got confused and are trying to > free the wrong thing or you might be trying to free a stale pointer > that has already been freed and reused, although valgrind tries to > delay reusing memory to avoid that case as much as possible. > > > ==7857== Warning: noted but unhandled ioctl 0x3 with no size/direction hints > > ==7857== This could cause spurious value errors to appear. > > ==7857== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. > > That looks like a very odd ioctl... > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > 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 > |
|
From: Geoff A. <gal...@nc...> - 2003-10-08 02:12:49
|
Looks like this may be Q14 in the valgrind FAQ (http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt). Geoff Alexander ----- Original Message ----- From: "strk" <st...@ke...> To: <val...@li...> Cc: <db...@re...> Sent: Tuesday, October 07, 2003 5:29 PM Subject: [Valgrind-users] still reachable from basic_string (C++) > Does the following valgrind detect a memory leak in the libstdc++ ? > > ==2410== 114048 bytes in 26 blocks are still reachable in loss record 14 of 14 > ==2410== at 0x4002A9A4: malloc (vg_replace_malloc.c:153) > ==2410== by 0x804BB6E: __default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &) (/usr/include/g++-3/stl_alloc.h:490) > ==2410== by 0x804B95B: __default_alloc_template<true, 0>::_S_refill(unsigned int) (/usr/include/g++-3/stl_alloc.h:531) > ==2410== by 0x402F092B: basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::replace(unsigned int, unsigned int, char const *, unsigned int) (/usr/include/g++-3/stl_alloc.h:332) > ==2410== by 0x402E78C7: __static_initialization_and_destruction_0 (/usr/include/g++-3/std/bastring.h:223) > ==2410== by 0x402E7D69: geos::TopologyValidationError::TopologyValidationError(int, geos::Coordinate) (/usr/include/g++-3/stl_map.h:76) > ==2410== by 0x402EFB04: (within /extra/geos/lib/libgeos.so.1.0.0) > ==2410== by 0x40286855: (within /extra/geos/lib/libgeos.so.1.0.0) > ==2410== by 0x4000D1D8: _dl_init (dl-init.c:70) > ==2410== by 0x40001DB0: (within /lib/ld-2.2.2.so) > > > > ------------------------------------------------------- > 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 |
|
From: strk <st...@ke...> - 2003-10-07 21:29:49
|
Does the following valgrind detect a memory leak in the libstdc++ ? ==2410== 114048 bytes in 26 blocks are still reachable in loss record 14 of 14 ==2410== at 0x4002A9A4: malloc (vg_replace_malloc.c:153) ==2410== by 0x804BB6E: __default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &) (/usr/include/g++-3/stl_alloc.h:490) ==2410== by 0x804B95B: __default_alloc_template<true, 0>::_S_refill(unsigned int) (/usr/include/g++-3/stl_alloc.h:531) ==2410== by 0x402F092B: basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::replace(unsigned int, unsigned int, char const *, unsigned int) (/usr/include/g++-3/stl_alloc.h:332) ==2410== by 0x402E78C7: __static_initialization_and_destruction_0 (/usr/include/g++-3/std/bastring.h:223) ==2410== by 0x402E7D69: geos::TopologyValidationError::TopologyValidationError(int, geos::Coordinate) (/usr/include/g++-3/stl_map.h:76) ==2410== by 0x402EFB04: (within /extra/geos/lib/libgeos.so.1.0.0) ==2410== by 0x40286855: (within /extra/geos/lib/libgeos.so.1.0.0) ==2410== by 0x4000D1D8: _dl_init (dl-init.c:70) ==2410== by 0x40001DB0: (within /lib/ld-2.2.2.so) |
|
From: julien p. <Jul...@gm...> - 2003-10-06 15:55:10
|
I do have the same problem, which is described at bug 1406 at http://sources.redhat.com/cgi-bin/gnatsweb.pl I first thought it was gdb dependant since it only appeared with recent releases of gdb, but according to the audit trail, it is valgrind that should supply a "better" stack to gdb -- julien |
|
From: Tom H. <th...@cy...> - 2003-10-06 13:48:01
|
In message <Pin...@jd...>
Derick Rethans <de...@ph...> wrote:
> While debugging a program Valgrind (1.9.6) gave me the following error:
[ snipped banner ]
> valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed.
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==15995== at 0x42029E51: __new_exitfn (in /lib/tls/libc-2.3.2.so)
> ==15995== by 0x42029E08: __cxa_atexit_internal (in /lib/tls/libc-2.3.2.so)
> ==15995== by 0x40837727: (within /usr/lib/libstdc++.so.5.0.3)
> ==15995== by 0x40837779: (within /usr/lib/libstdc++.so.5.0.3)
>
> The program uses wxWindows, and was compiled with 3.2.2 on RedHat 9.
> Does anybody knows what might be wrong?
Yes. That assertion fires if the program tries to use a segment
register that refers to the GDT rather than the LDT. The normal
reason for that is that you're on a system that uses NPTL rather
than linux threads.
Recent versions of valgrind set LD_ASSUME_KERNEL in order to force
the system to fall back to linux threads, but you're using a fairly
old version which presumably doesn't.
Either upgrade to a more recent version or set LD_ASSUME_KERNEL to
2.4.1 in your environment and it should work.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sebastian <sc...@nb...> - 2003-10-06 13:37:26
|
Hi, On Mon, Oct 06, 2003 at 01:04:26PM +0100, jon...@ph... wrote: > > What is it that you are reading from? Could it be a separate or > > subprocess which exits after sending the data? > This is an X-like graphics server and client talking to each other over > UNIX-domain sockets. Neither exits. (It's Nano-X from > http://www.microwindows.org/ ). I have also had the same problem reading > from character-special devices. Can you check if the value of errno changed? (That is, adding errno = 0 before the read() and checking it after). I remember having some weird issue with read() a few years back, when it returned zero (without valgrind, and on Solaris). > Thanks & regards, > Jon Foster ciao, Sebastian -- -. sc...@nb... -. + http://segfault.net/~scut/ `--------------------. -' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07 `- W88 heads sold. 4 payloads ready, payment due. hi echelon! ---------------' |
|
From: Derick R. <de...@ph...> - 2003-10-06 13:24:15
|
Hello, While debugging a program Valgrind (1.9.6) gave me the following error: ==15995== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==15995== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==15995== Using valgrind-1.9.6, a program instrumentation system for x86-linux. ==15995== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==15995== Estimated CPU clock rate is 999 MHz ==15995== For more details, rerun with: -v ==15995== valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed. sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==15995== at 0x42029E51: __new_exitfn (in /lib/tls/libc-2.3.2.so) ==15995== by 0x42029E08: __cxa_atexit_internal (in /lib/tls/libc-2.3.2.so) ==15995== by 0x40837727: (within /usr/lib/libstdc++.so.5.0.3) ==15995== by 0x40837779: (within /usr/lib/libstdc++.so.5.0.3) The program uses wxWindows, and was compiled with 3.2.2 on RedHat 9. Does anybody knows what might be wrong? regards, Derick -- ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ International PHP Magazine http://www.php-mag.net/ ------------------------------------------------------------------------- |
|
From: <jon...@ph...> - 2003-10-06 12:08:58
|
Hi, Dirk Mueller <dm...@gm...> wrote: >> I have some code that behaves incorrectly when run under recent >> versions of Valgrind. When run under old versions of Valgrind, >> or without Valgrind, it works. > >hmm. do you know when this problem was introduced for you? >do you use CVS HEAD or the 2_0 branch? Release 1.0.4 worked. CVS HEAD as of 25 July 2003 did not work. "Paul A. Clarke" <pa...@us...> wrote: > What is it that you are reading from? Could it be a separate or > subprocess which exits after sending the data? This is an X-like graphics server and client talking to each other over UNIX-domain sockets. Neither exits. (It's Nano-X from http://www.microwindows.org/ ). I have also had the same problem reading from character-special devices. Thanks & regards, Jon Foster -- |
|
From: Tom H. <th...@cy...> - 2003-10-06 07:41:23
|
In message <00bc01c38bda$5dc5a070$6501a8c0@guindy>
Durai Balusamy <durai.balusamy@Sun.COM> wrote:
> What does 'invalid free()/delete/delete[]' mean in valgrind output.
> Is it a memory corruption or stack overflow or double free?
It means that the pointer passed to free/delete is not one that was
previously returned from malloc/new, or if it is then it has already
been freed.
> If it is a memory corruption or a double free, is there a way to
> find out which part of the code causes this crash?
That depends on the cause - if it's a double free then you'll have
to try and catch the allocation in the debugger based on valgrind's
information about the block and then try and break on frees of that
block so you find the first and second frees.
If it's just that you are trying to free a bogus pointer then you'll
have to use valgrind's information about both the location of the free
and the pointer being freed to track back to the source of the problem.
> Also I have to use libpthead provided by valgrind package. Initially
> I ran without valgrind's libpthread and it reported the Invalid read
> errors. But when I used libpthread, it did not report those invalid
> read errors? Am I doing anything wrong?
I'm astonished that anything worked at all if you didn't use valgrind's
libpthread, as the real one will call the clone system call which valgrind
is not able to handle.
> ==7857== Invalid free() / delete / delete[]
> ==7857== at 0x4002BCB7: __builtin_delete (vg_replace_malloc.c:233)
> ==7857== by 0x4064D938: String::~String(void) (XSLString.cpp:356)
> ==7857== by 0x40611791: PathExpr::~PathExpr(void) (PathExpr.cpp:51)
> ==7857== by 0x4064C70E: NamedMap::clear(int) (NamedMap.cpp:115)
> ==7857== Address 0x5E5AF728 is 12 bytes inside a block of size 28 alloc'd
> ==7857== at 0x4002BA38: __builtin_new (vg_replace_malloc.c:172)
> ==7857== by 0x40608A0B: ExprParser::createExpr(ExprLexer &) (ExprParser.cpp:319)
> ==7857== by 0x40607A4B: ExprParser::createExpr(String const &) (ExprParser.cpp:160)
> ==7857== by 0x405E6568: ProcessorState::getExpr(String const &) (ProcessorState.cpp:450)
So valgrind is reporting here that you are freeing a pointer that
doesn't point to the start of a block, but rather 12 bytes inside
one. That might mean that you have got confused and are trying to
free the wrong thing or you might be trying to free a stale pointer
that has already been freed and reused, although valgrind tries to
delay reusing memory to avoid that case as much as possible.
> ==7857== Warning: noted but unhandled ioctl 0x3 with no size/direction hints
> ==7857== This could cause spurious value errors to appear.
> ==7857== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
That looks like a very odd ioctl...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Durai B.
|
My program crashes on linux with the following stack trace...
#0 0x40a3455e in free () from /lib/libc.so.6
(gdb) where
#0 0x40a3455e in free () from /lib/libc.so.6
#1 0x40a344e4 in free () from /lib/libc.so.6
#2 0x4072b716 in __builtin_delete (ptr=0xbc1973c) at ../../gcc/cp/new2.cc:-1
#3 0x40431939 in String::~String (this=0xbc1973c, __in_chrg=3) at XSLString.cpp:356
#4 0x403f5792 in PathExpr::~PathExpr (this=0xbc19670, __in_chrg=3) at PathExpr.cpp:51
#5 0x4043070f in NamedMap::clear (this=0xbf5f9528, deleteObjects=1) at NamedMap.cpp:115
#6 0x4043066e in NamedMap::clear (this=0xbf5f9528) at NamedMap.cpp:98
#7 0x40430601 in NamedMap::~NamedMap (this=0xbf5f9528, __in_chrg=2) at NamedMap.cpp:86
#8 0x403c9226 in ProcessorState::~ProcessorState (this=0xbf5f942c, __in_chrg=2) at ProcessorState.cpp:123
#9 0x403c1f77 in XSLProcessor::process (this=0xbf5f998c, xmlDocument=@0xbc06fa0, xslDocument=@0x82dd5a8, out=@0xbc179ec,
documentBase=@0xbf5f996c) at XSLProcessor.cpp:789
.....
So I ran my program under valgrind and it reported invalid free .. in the same place
as where it crashed.
What does 'invalid free()/delete/delete[]' mean in valgrind output.
Is it a memory corruption or stack overflow or double free?
If it is a memory corruption or a double free, is there a way to find out which part of
the code causes this crash?
Also I have to use libpthead provided by valgrind package. Initially I ran without
valgrind's libpthread and it reported the Invalid read errors. But when I used
libpthread, it did not report those invalid read errors? Am I doing anything wrong?
OS: Linux AS 2.1 Edition
Compiler: gcc/g++ 2.96 version.
Valgrind version: 20030725.
==7857== Invalid free() / delete / delete[]
==7857== at 0x4002BCB7: __builtin_delete (vg_replace_malloc.c:233)
==7857== by 0x4064D938: String::~String(void) (XSLString.cpp:356)
==7857== by 0x40611791: PathExpr::~PathExpr(void) (PathExpr.cpp:51)
==7857== by 0x4064C70E: NamedMap::clear(int) (NamedMap.cpp:115)
==7857== Address 0x5E5AF728 is 12 bytes inside a block of size 28 alloc'd
==7857== at 0x4002BA38: __builtin_new (vg_replace_malloc.c:172)
==7857== by 0x40608A0B: ExprParser::createExpr(ExprLexer &) (ExprParser.cpp:319)
==7857== by 0x40607A4B: ExprParser::createExpr(String const &) (ExprParser.cpp:160)
==7857== by 0x405E6568: ProcessorState::getExpr(String const &) (ProcessorState.cpp:450)
==7857== Warning: noted but unhandled ioctl 0x3 with no size/direction hints
==7857== This could cause spurious value errors to appear.
==7857== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==7857== valgrind's libpthread.so: IGNORED call to: pthread_attr_destroy
==7857==
==7857== Thread 3:
==7857== Invalid free() / delete / delete[]
==7857== at 0x4002BCB7: __builtin_delete (vg_replace_malloc.c:233)
==7857== by 0x4064D938: String::~String(void) (XSLString.cpp:356)
==7857== by 0x40611791: PathExpr::~PathExpr(void) (PathExpr.cpp:51)
==7857== by 0x40612BE8: RelationalExpr::~RelationalExpr(void) (RelationalExpr.cpp:46)
==7857== Address 0x5E28178C is 12 bytes inside a block of size 28 alloc'd
==7857== at 0x4002BA38: __builtin_new (vg_replace_malloc.c:172)
==7857== by 0x40608A0B: ExprParser::createExpr(ExprLexer &) (ExprParser.cpp:319)
==7857== by 0x40607A4B: ExprParser::createExpr(String const &) (ExprParser.cpp:160)
==7857== by 0x405E6568: ProcessorState::getExpr(String const &) (ProcessorState.cpp:450)
Any idea?
Thanks,
durai.
|
|
From: Roberto S. <ro...@mu...> - 2003-10-05 15:44:58
|
Il sab, 2003-10-04 alle 21:25, Dirk Mueller ha scritto: > On Saturday 04 October 2003 19:12, Roberto Sebastiano wrote: > > > I have a problem when running a program under valgrind > > under which version of valgrind? dpkg -l valgrind ii valgrind 20030725-5 > > The program runs just fine without valgrind. > > Great. do you have a compileable testcase that reproduces the problem for you? > then its pretty trivial to figure it out. No, I only have the entire program in source form I'll try to build a testcase that triggers the problem ASAP Cheers, -- Roberto Sebastiano <ro...@mu...> |
|
From: Dirk M. <dm...@gm...> - 2003-10-05 12:33:32
|
On Saturday 04 October 2003 19:12, Roberto Sebastiano wrote: > I have a problem when running a program under valgrind under which version of valgrind? > The program runs just fine without valgrind. Great. do you have a compileable testcase that reproduces the problem for you? then its pretty trivial to figure it out. |
|
From: Roberto S. <ro...@mu...> - 2003-10-04 17:41:24
|
Il sab, 2003-10-04 alle 19:58, Dan Kegel ha scritto: > Roberto Sebastiano wrote: > > #5 0x0804c031 in main (argc=134534236, argv=0x0) at lookt2.c:1243 > > Yikes, why is it confused about argc? > I don't know, printing it the line before it stops shows "5", that is the correct value I argue stack corruption Cheers, -- Roberto Sebastiano <ro...@mu...> |
|
From: Dan K. <da...@ke...> - 2003-10-04 17:23:49
|
Roberto Sebastiano wrote: > #5 0x0804c031 in main (argc=134534236, argv=0x0) at lookt2.c:1243 Yikes, why is it confused about argc? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Roberto S. <ro...@mu...> - 2003-10-04 17:13:31
|
I have a problem when running a program under valgrind
The program runs just fine without valgrind.
Under valgrind, it complains about two places in the code.
This two sections are similar, so I show only the first one:
#define F_CONNECTING 2
...
for(i=0; i < 200; i++) {
...
if(connection[i].flags == F_CONNECTING)
{
printf("connection[%i].flags=%i\n", i, connection[i].flags);
=> if(pollfds[connection[i].pollidx].revents & POLLERR ||
pollfds[connection[i].pollidx].revents & POLLHUP ||
pollfds[connection[i].pollidx].revents & POLLNVAL) { do something .. }
the line with => is line number 1243
when running under valgrind:
connection[0].flags=2
==8200==
==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
(gdb) frame 5
#5 0x0804c031 in main (argc=134534236, argv=0x0) at lookt2.c:1243
1243 if(pollfds[connection[i].pollidx].revents & POLLERR ||
pollfds[connection[i].pollidx].revents & POLLHUP ||
pollfds[connection[i].pollidx].revents & POLLNVAL)
(gdb) print i
$1 = 202
As you see, here the counter "i" is 202, while just one line before
stopping, the program printed connection[0].flags=2 (where "i" is 0,
which is the correct value)
The above error repeats with a different but similar region of code.
Any idea ?
If that matters, I'm running debian unstable
Thanks,
--
Roberto Sebastiano <ro...@mu...>
|
|
From: Dirk M. <dm...@gm...> - 2003-10-03 23:05:37
|
On Friday 03 October 2003 20:16, jon...@ph... wrote: > I have some code that behaves incorrectly when run under recent > versions of Valgrind. When run under old versions of Valgrind, > or without Valgrind, it works. hmm. do you know when this problem was introduced for you? do you use CVS HEAD or the 2_0 branch? > |
|
From: Paul A. C. <pa...@us...> - 2003-10-03 20:37:18
|
What is it that you are reading from? Could it be a separate or
subprocess which exits after sending the data? (I don't believe there's
any guarantee that data sent but not received before the sending process
exits will necessarily ever be received.) Perhaps the newer version of
Valgrind is slowing the receiving process down enough that the sender is
gone before the read() is attempted?
Just a guess.
Paul Clarke
On Fri, 2003-10-03 at 13:16, jon...@ph... wrote:
> Hi,
> I have some code that behaves incorrectly when run under recent
> versions of Valgrind. When run under old versions of Valgrind,
> or without Valgrind, it works.
>
> Here's the code, which is trying to read a fixed-size record from
> a socket:
>
> char * buf_ptr = buf;
> while (bytes_to_read > 0) {
>
> int num_read = read(fd, buf_ptr, bytes_to_read);
>
> assert (num_read != 0); // <<<====
>
> if (num_read < 0) {
> ... handle errors ...
> } else {
> bytes_to_read -= num_read;
> buf_ptr += num_read;
> }
> }
>
> The problem is that the assertion is being triggered. If I remove
> the assertion, then the code works fine (so at least some of the
> subsequent read()s must be succeeding).
>
> There is not an EOF condition, and number_of_bytes_to_read is a
> small nonzero positive integer, so according to the man page
> there is no way that read() should return zero.
>
> Has anyone else seen this behaviour? Has anyone found a fix?
>
> Please CC me on replies - I'm not subscribed to the list.
>
> Kind regards,
>
> Jon Foster
> --
>
>
>
>
>
> -------------------------------------------------------
> 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
>
|
|
From: <jon...@ph...> - 2003-10-03 18:20:36
|
Hi,
I have some code that behaves incorrectly when run under recent
versions of Valgrind. When run under old versions of Valgrind,
or without Valgrind, it works.
Here's the code, which is trying to read a fixed-size record from
a socket:
char * buf_ptr = buf;
while (bytes_to_read > 0) {
int num_read = read(fd, buf_ptr, bytes_to_read);
assert (num_read != 0); // <<<====
if (num_read < 0) {
... handle errors ...
} else {
bytes_to_read -= num_read;
buf_ptr += num_read;
}
}
The problem is that the assertion is being triggered. If I remove
the assertion, then the code works fine (so at least some of the
subsequent read()s must be succeeding).
There is not an EOF condition, and number_of_bytes_to_read is a
small nonzero positive integer, so according to the man page
there is no way that read() should return zero.
Has anyone else seen this behaviour? Has anyone found a fix?
Please CC me on replies - I'm not subscribed to the list.
Kind regards,
Jon Foster
--
|
|
From: <ar...@de...> - 2003-10-02 20:43:52
|
Hi. I've written a valgrind manpage based on the valgrind's HTML manual. It has some Debianized entries but can be modified for another GNU/Linux system. I hope this helps somehow the valgrind project :) |
|
From: Erik C. <er...@ar...> - 2003-10-01 19:17:18
|
On Wed, Oct 01, 2003 at 06:54:20PM +0100, Nicholas Nethercote wrote: > On Wed, 1 Oct 2003, Jeremy Fitzhardinge wrote: > > > > * If you generate a new pointer/integer by math between two operands > > > with different malloc-area sets then the new integer gets the union > > > of the sets. > > > > Yep, this is what I suggested. > > But the sets become huge (eg. 1000s of entries), which slows things down > horrifically. If a pointer is dereferenced then you can reduce that set to one single segment, namely the segment it points at when it is dereferenced. > Besides, when you do the pointer subtraction, that > "connection" between them is really a property of the ptrdiff, not a > property of the segments, so putting the two segments into the same set > isn't a true reflection of what's happening. > > These two reasons are why I think having a dedicated ptrdiff type is a > better solution. For the record, that is what I was suggesting in the "simple" suggestion snipped above. It's the new integer (ptrdiff) that is assigned the union of the sets, not all pointers into the sets. > Although I haven't implemented it yet, so I'm yet to see > how it works in practice. The idea you explained the other day is a more complex (accurate) version of the "just taking the union" idea above. The question is whether it gives too many false alarms. -- Erik Corry er...@ar... A: Because it messes up the order in which people normally read text. Q: Why is top-replying such a bad thing? A: Top-replying. Q: What is the most annoying thing in email? |
|
From: Nicholas N. <nj...@ca...> - 2003-10-01 17:55:29
|
On Wed, 1 Oct 2003, Jeremy Fitzhardinge wrote: > > * If you generate a new pointer/integer by math between two operands > > with different malloc-area sets then the new integer gets the union > > of the sets. > > Yep, this is what I suggested. But the sets become huge (eg. 1000s of entries), which slows things down horrifically. Besides, when you do the pointer subtraction, that "connection" between them is really a property of the ptrdiff, not a property of the segments, so putting the two segments into the same set isn't a true reflection of what's happening. These two reasons are why I think having a dedicated ptrdiff type is a better solution. Although I haven't implemented it yet, so I'm yet to see how it works in practice. N |
|
From: Jeremy F. <je...@go...> - 2003-10-01 17:40:04
|
On Mon, 2003-09-29 at 18:20, Erik Corry wrote: > * Each integer/pointer is associated with a possibly empty set > of malloc-areas. > * Obviously each pointer is initially associated with exactly > one malloc-area. > * If you generate a new pointer/integer by math between two operands > with different malloc-area sets then the new integer gets the union > of the sets. > * Unary ops don't change the malloc area associated (neg handling) > * As an optimisation, if you subtract two pointers and they each have > only one malloc-area associated and it's the same malloc-area then > you get an integer with no malloc-areas associated. Yep, this is what I suggested. The tricky thing is dealing with pointers to things which aren't malloced, like things in data/bss. If you have a statically-initialized pointer in data, then annelid can't tell it is a pointer. J |
|
From: Jeremy F. <je...@go...> - 2003-10-01 17:40:04
|
On Mon, 2003-09-29 at 17:27, Nicholas Nethercote wrote: > Interesting... were they allowing for the possibility of a non-flat > address space, or something like that? If you cast the pointers to > integers, did the subtraction, then used the result as the offset, would > that be legal C? Not really. There are some (very strange) machines which do annelid-like things internally, so the C standard allows for them. But it doesn't matter what C does or doesn't allow, since Valgrind works on machine-code from any language. > Either way, in practice we have to deal with it, especially since glibc > does it in strcpy() (see below), and it pops up in lots of other places. Yep. J |
|
From: Jeremy F. <je...@go...> - 2003-10-01 17:40:03
|
On Mon, 2003-09-29 at 18:14, Nicholas Nethercote wrote: > > /* Copy just a few bytes to make DSTP aligned. */ > > len -= (-dstp) % OPSIZ; > > > > I guess I need the right suppression file. > > Hmm, see my other reply to Steve G. Thanks for giving me the exact line > it occurred on. I won't pretend to understand what that code is doing, It actually does make sense. This code wants to move the pointer to an aligned address, so it does the first part of the operation on small units until the pointer is aligned, then does the rest with word-sized operations. In other words, just make negation drop the pointerness and carry on. J |