[Bug c++/25849] New: 8 byte memory leak using cerr with libpthread linked in

["loizeaux1 at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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