If you link in libpthread with a program that uses cerr, you leak 8 bytes of
memory (determined through Purify). I discovered this using a RHEL 3 WS box
and also had the same occur on a RHEL 4 AS box. This will not occur when you
use cout or clog in place of cerr, or if libpthread is not linked in.
Granted, 8 bytes is a small leak, but it still is a memory leak.
> cat test.cpp
#include <iostream>
int main( int argc, char* argv[] )
{
std::cerr << "This is a message" << std::endl;
return 0;
}
> which purify
/usr/local/rational/releases/PurifyPlus.2003a.06.13.FixPack.0177/i386_linux2/bin/purify
> purify --version
Version 2003a.06.13 FixPack 0177 050331 Linux (32-bit)
> which g++
/app/gnu/gcc-4.0.1/bin/g++
> g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /gnu/gcc-4.0.1-src/configure --prefix=/gnu/gcc-4.0.1
Thread model: posix
gcc version 4.0.1
> uname -a
Linux testbox 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 i686 i386
GNU/Linux
> purify g++ -o test test.cpp -lpthread
Purify 2003a.06.13 FixPack 0177 050331 Linux (32-bit) (c) Copyright IBM Corp.
1992, 2005 All rights reserved.
Instrumenting: crtbegin.o cctQmZeb.o
libgcc.a................................................................................
crtend.o Linking
> test
[from PurifyPlus window]
Purify: Searching for all memory leaks...
Memory leaked: 8 bytes (100%); potentially leaked: 0 bytes (0%)
MLK: 8 bytes leaked at 0x80b4c10
* This memory was allocated from:
malloc [rtlib.o]
__cxa_get_globals [eh_globals.cc:115]
std::uncaught_exception( void) [eh_catch.cc:138]
std::basic_ostream< char,std::char_traights< char>> & std::operator
<<<std::char_traits< char>>(std::basic_ostream< char,std::char_traits< char>>
&, char const *) [ostream:405]
main [ccz2Vq3m.o]
__libc_start_main [libc.so.6]
Purify Heap Analysis (combining supressed and unsupressed blocks)
Blocks Bytes
Leaked 1 8
Potentially Leaked 0 0
In-Use 0 0
-----------------------------------------
Total Allocated 1 8
Along with the memory leak, Purify reported two categories of uninitialized
memory reads (UMR) that are normally suppressed. I wouldn't usually report
these, but they seem to be related (I performed some mild editing).
UMR: Uninitialized memory read (2 times):
* This is occurring while in thread -1224099488:
__pthread_initialize_minimal [libpthread.so.0]
call_initialize_minimal [libpthread.so.0]
_init [libpthread.so.0]
_dl_init []
_dl_start_user []
* Reading 4 bytes from 0xbfffdaac on the stack of thread -1224099488.
* Address 0xbfffdaac is 168 bytes below frame pointer in function
__pthread_initialize_minimal.
* Command-line: test
UMR: Uninitialized memory read (128 times):
* This is occurring while in thread -1224099488:
__gconv_transform_internal_ascii [libc.so.6]
wctob [libc.so.6]
std::ctype< wchar_t>::_M_initialize_ctype( void)
[ctype_members.cc:246]
std::ctype< wchar_t>::ctype( unsigned) [ctype.cc:91]
std::locale::_Impl::_Impl( unsigned) [locale_init.cc:304]
std::locale::_S_initialize_once( void) [locale_init.cc:143]
* Reading 4 bytes from 0xbfffd904 on the stack of thread -1224099488.
* Address 0xbfffd904 is 84 bytes below frame pointer in function
wctob.
--
Summary: 8 byte memory leak using cerr with libpthread linked in
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loizeaux1 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
