|
From: Trond V. <va...@st...> - 2004-11-04 15:26:25
|
Hi!
It seems that Valgrind has a bug concerning strings on the stack. This
simple example yields "1 allocs, 0 frees" using the command "valgrind
alloctest", where alloctest is the executable file of the example:
#include <string>
using namespace std;
int main()
{
string s =3D "jklds";
}
This is not an actual mistake on my part, right? s will go out of scope
when main terminates, won't it?
--
Trond Valen
NTNU student
|
|
From: Tom H. <th...@cy...> - 2004-11-04 16:17:29
|
In message <109...@we...>
Trond Valen <va...@st...> wrote:
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right? s will go out of scope
> when main terminates, won't it?
It will, yes. I believe what you are seeing is an artifact of the
pooled memory allocator that libstdc++ uses for string objects.
The result of that is that the memory is returned to an internal free
pool inside the string class and not to the main free pool. So as far
as valgrind is concerned it is still allocated.
If you use --leak-check=yes --show-reachable=yes then you should be
able to see that there is a block still allocated and that something
in libstdc++ has a handle to it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-04 16:19:09
|
On Thu, 4 Nov 2004, Trond Valen wrote:
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right?
It's not a bug by you or Valgrind. Underneath the shiny "string" surface,
glibc will have done one allocation.
> s will go out of scope when main terminates, won't it?
Yes, but it looks like glibc doesn't bother to free it. This is not a
problem. You don't need to worry about mismatches between the
allocs/frees counts, rather only the leaks that --leak-check=yes tells
you.
N
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-11-04 17:00:15
|
> Hi!
>
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right? s will go out of scope
> when main terminates, won't it?
See also item 4.3 in the Valgrind FAQ, file FAQ.txt in the top source
directory, for more information on these memory leaks in the C++ STL and
string classes.
Regards,
Jeroen.
|
|
From: Dennis L. <pla...@tz...> - 2004-11-05 15:40:22
|
Am Donnerstag, den 04.11.2004, 16:26 +0100 schrieb Trond Valen:
> Hi!
>
> It seems that Valgrind has a bug concerning strings on the stack. This
> simple example yields "1 allocs, 0 frees" using the command "valgrind
> alloctest", where alloctest is the executable file of the example:
>
> #include <string>
> using namespace std;
>
> int main()
> {
> string s = "jklds";
> }
>
> This is not an actual mistake on my part, right? s will go out of scope
> when main terminates, won't it?
The GNU string implementation uses some custom allocator pools for
strings, as this is also encouraged by ISO C++. Things are even worse if
you assing the s.c_str(); to something, and use it after s goes out of
scope, it often works, and valgrind does not notice the bug. In a
previous post I asked that this issue should be added to FAQ5, but it
seemed to be silently ignored. Running such a program with the
environment variabel GLIBCPP_FORCE_NEW set (with gcc 3.x) also the
string implementation uses the slower new allocator. This will cause
valgrind to correctly report that in your case the memory is deleted
when s goes out of scope, and if you would after that use the pointer
from s.c_str() valgrind would also report the misuse there.
greets
Dennis
--
Dennis Lubert <pla...@tz...>
|
|
From: Robert W. <rj...@du...> - 2004-11-05 17:32:37
|
> Running such a program with the > environment variabel GLIBCPP_FORCE_NEW set (with gcc 3.x) also the > string implementation uses the slower new allocator. This will cause > valgrind to correctly report that in your case the memory is deleted > when s goes out of scope, and if you would after that use the pointer > from s.c_str() valgrind would also report the misuse there. Huh. Maybe Valgrind should set this variable for you by default, then? Perhaps with an option to turn it off. Regards, Robert. |