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