Thread: [Valgrind-users] Does creating a stringstream object cause a leak

Brought to you by: njn, sewardj, wielaard

valgrind-users

[Valgrind-users] Does creating a stringstream object cause a leak

From: fpga <mgb...@bl...> - 2009-05-04 15:32:47

#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.

Re: [Valgrind-users] Does creating a stringstream object cause a leak

From: Miguel O. <mig...@gm...> - 2009-05-04 15:45:39

On Mon, May 4, 2009 at 3:32 PM, fpga <mgb...@bl...> wrote:
>
> #include "sstream"
> using namespace std;
> int main(){
>   stringstream ss;
>   return 0;
> }
>
> Why does the above cause this 'bug'?

Trying...

$ valgrind --version
valgrind-3.4.1-Debian
$ g++ --version
g++ (Debian 4.3.3-3) 4.3.3
$ valgrind ./a.out
...
==2990== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==2990== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2990== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==2990== For counts of detected errors, rerun with: -v
==2990== All heap blocks were freed -- no leaks are possible.
...

Which versions are you using? Is your C++ lib in good shape?

>
> ==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
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Does creating a stringstream object cause a leak

From: Nicholas N. <n.n...@gm...> - 2009-05-04 22:59:37

On Tue, May 5, 2009 at 1:45 AM, Miguel Ojeda
<mig...@gm...> wrote:
> On Mon, May 4, 2009 at 3:32 PM, fpga <mgb...@bl...> wrote:
>>
>> #include "sstream"
>> using namespace std;
>> int main(){
>>   stringstream ss;
>>   return 0;
>> }
>>
>> Why does the above cause this 'bug'?
>
> Trying...
>
> $ valgrind --version
> valgrind-3.4.1-Debian
> $ g++ --version
> g++ (Debian 4.3.3-3) 4.3.3
> $ valgrind ./a.out
> ...
> ==2990== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
> ==2990== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==2990== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==2990== For counts of detected errors, rerun with: -v
> ==2990== All heap blocks were freed -- no leaks are possible.
> ...
>
> Which versions are you using? Is your C++ lib in good shape?

I don't get the error either, with the same Valgrind version on my
Ubuntu 9.04 box.

Judging from the stack trace, it's a bug in the libc which you
probably can't do much about.  I'd suppress it -- use
--gen-suppressions=yes to do so.

Nick

Re: [Valgrind-users] Does creating a stringstream object cause a leak

From: fpga <mgb...@bl...> - 2009-05-05 14:26:00

Versions are 
$ valgrind --version
valgrind-3.3.0
$ g++ --version
g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)

Thanks for confirming that your g++ configurations run ok
and for the supression tip.
Yum won't let me upgrade further.
Maybe I'll change OS'

-- 
View this message in context: http://www.nabble.com/Does-creating-a-stringstream-object-cause-a-leak-tp23370849p23388130.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Does creating a stringstream object cause a leak

From: <dan...@in...> - 2009-05-11 16:30:11

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 <mgb...@bl...> 
05/04/2009 11:32 AM

To
val...@li...
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
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users