Just to try something, see if it might bear relation to the allocator
issue, try: -DGLIBCXX_FORCE_NEW if you are using gcc >= 3.4.x
I know I used that define to prove a "leak" was not a leak in a much older
Valgrind installation and added the info to my suppressions file. The
current installation I use did not require it.
---Dan
>From the Valgrind FAQ
(http://www.valgrind.org/docs/manual/faq.html#faq.reports):
4. Valgrind behaves unexpectedly
4.1. My program uses the C++ STL and string classes. Valgrind
reports 'still reachable' memory leaks involving these classes at the exit
of the program, but there should be none.
4.2. The stack traces given by Memcheck (or another tool) aren't helpful.
How can I improve them?
4.3. The stack traces given by Memcheck (or another tool) seem to have the
wrong function name in them. What's happening?
4.4. My program crashes normally, but doesn't under Valgrind, or vice
versa. What's happening?
4.1. My program uses the C++ STL and string classes. Valgrind reports
'still reachable' memory leaks involving these classes at the exit of the
program, but there should be none.
First of all: relax, it's probably not a bug, but a feature. Many
implementations of the C++ standard libraries use their own memory pool
allocators. Memory for quite a number of destructed objects is not
immediately freed and given back to the OS, but kept in the pool(s) for
later re-use. The fact that the pools are not freed at the exit() of the
program cause Valgrind to report this memory as still reachable. The
behaviour not to free pools at the exit() could be called a bug of the
library though.
Using gcc, you can force the STL to use malloc and to free memory
as soon as possible by globally disabling memory caching. Beware! Doing so
will probably slow down your program, sometimes drastically.
With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL
with -D__USE_MALLOC. Beware! This was removed from gcc starting with
version 3.3.
With gcc 3.2.2 and later, you should export the environment
variable GLIBCPP_FORCE_NEW before running your program.
With gcc 3.4 and later, that variable has changed name to
GLIBCXX_FORCE_NEW.
There are other ways to disable memory pooling: using the
malloc_alloc template with your objects (not portable, but should work for
gcc) or even writing your own memory allocators. But all this goes beyond
the scope of this FAQ. Start by reading
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak if you
absolutely want to do that. But beware: allocators belong to the more
messy parts of the STL and people went to great lengths to make the STL
portable across platforms. Chances are good that your solution will work
on your platform, but not on others.
fpga <[email protected]>
05/04/2009 11:32 AM
To
[email protected]
cc
Subject
[Valgrind-users] Does creating a stringstream object cause a leak
#include "sstream"
using namespace std;
int main(){
stringstream ss;
return 0;
}
Why does the above cause this 'bug'?
==4249== Invalid free() / delete / delete[]
==4249== at 0x40052EA: operator delete(void*, std::nothrow_t const&)
(vg_replace_malloc.c:354)
==4249== by 0x5544058: std::__verify_grouping(char const*, unsigned,
std::string const&) (locale_facets.cc:108)
==4249== by 0x5544F8C: std::locale::_Impl::_Impl(char const*, unsigned)
(localename.cc:218)
==4249== by 0x554500C: std::locale::_Impl::_Impl(char const*, unsigned)
(localename.cc:206)
==4249== by 0x5546137: std::locale::locale() (localename.cc:88)
==4249== by 0x5540B9B: std::ios_base::ios_base() (locale.cc:378)
==4249== by 0x557EAA4: std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char>
>::basic_stringstream(std::_Ios_Openmode) (istream:586)
==4249== by 0x804863E: main (/home/me/Desktop/new_play/bug.cpp:4)
==4249== Address 0x55dd188 is not stack'd, malloc'd or (recently) free'd
--
View this message in context:
http://www.nabble.com/Does-creating-a-stringstream-object-cause-a-leak-tp23370849p23370849.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
