https://bugs.kde.org/show_bug.cgi?id=162229
Paul Floyd <pjfl...@wanadoo.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pjfl...@wanadoo.fr
--- Comment #5 from Paul Floyd <pjfl...@wanadoo.fr> ---
I haven't checked the code, but I believe that the cause of this is that the
search for pointers isn't exhaustive and byte by byte. Instead it is done on
word boundaries.
With the latest code
git describe
VALGRIND_3_22_0-128-ga836d21
I get
==11932== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==11932== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==11932== Command: ./bug162229_1
==11932==
==11932== 1,024 bytes in 1 blocks are possibly lost in loss record 1 of 3
==11932== at 0x4030637: operator new[](unsigned long)
(vg_replace_malloc.c:727)
==11932== by 0x401377: f() (bug162229_1.cpp:10)
==11932== by 0x40140B: test() (bug162229_1.cpp:34)
==11932== by 0x4014DD: main (bug162229_1.cpp:43)
==11932==
==11932== 49,380 bytes in 1 blocks are definitely lost in loss record 2 of 3
==11932== at 0x4030637: operator new[](unsigned long)
(vg_replace_malloc.c:727)
==11932== by 0x401385: f() (bug162229_1.cpp:15)
==11932== by 0x40140B: test() (bug162229_1.cpp:34)
==11932== by 0x4014DD: main (bug162229_1.cpp:43)
So, still a definite leak.
If I change the code to be
static size_t offset = 16;
char * f(void)
{
//std::string allocates representation and returns
//fancy pointer to its' guts
char * p = new char[1024];
// then stores some data in its internals
// same approach as below
// here 1 is definitely lost
int * q = new int[12345];
*(int**)(p + offset) = q;
// here p is "possibly lost"
return p + 1; // return offset
}
then I get
==13219== 1,024 bytes in 1 blocks are possibly lost in loss record 1 of 3
==13219== at 0x4030637: operator new[](unsigned long)
(vg_replace_malloc.c:727)
==13219== by 0x401377: f() (bug162229_1.cpp:10)
==13219== by 0x40140B: test() (bug162229_1.cpp:34)
==13219== by 0x4014DD: main (bug162229_1.cpp:43)
==13219==
==13219== 49,380 bytes in 1 blocks are possibly lost in loss record 2 of 3
==13219== at 0x4030637: operator new[](unsigned long)
(vg_replace_malloc.c:727)
==13219== by 0x401385: f() (bug162229_1.cpp:15)
==13219== by 0x40140B: test() (bug162229_1.cpp:34)
==13219== by 0x4014DD: main (bug162229_1.cpp:43)
As a quick hack, I modified lc_scan_memory to do an exhaustive scan - I had to
change the increment from adding a word size to just using ++, and also turn
off a couple oof asserts.
However I don't think that we want to do that, even under an option. Firstly
it's going to be 4 or 8 times slower, depending on the word size. Secondly I'm
not sure that this won't cause misaligned access errors on some platforms.
--
You are receiving this mail because:
You are watching all bug changes.
