Bug 21108

Summary: Locks not freed in iostreams (endl)
Product: [Retired] Red Hat Linux Reporter: Andrey Shytov <avshytov>
Component: libstdc++Assignee: Jakub Jelinek <jakub>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-11-20 02:45:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrey Shytov 2000-11-20 02:45:43 UTC
I found that when endl is output to ostream, 
the locks sometimes are not freed. 
If two or more threads do output to
stderr, it finally results in deadlock. 
Somehow, one has to output more than one endl.
It does not work with "\n", only with endl.

The minimal version of this bug is manifest even in single-threaded
application compiled with -lpthread, though.
Here is an example:

//////////    Code starts here /////////
#include <iostream.h>
#include <stdio.h>
 
//
//  Compile:
//
//     g++ -g -o t t.cc -lpthread
//
 
 
int lock_count ()
{
    return ((pthread_mutex_t *)stderr->_lock)->__m_count ;
}
 
main ()
{
    cerr << "BEFORE endls: lock count = " << lock_count ();
    cerr << endl << endl;   // Does not work with only 1 endl
    cerr << "AFTER: lock count = " << lock_count () << endl;
 
} 

////////////////   Code ends here   ////////////////


On my system, it produces the following output: 
-------------------------------------------------
avs % ./t
BEFORE endls: lock count = 0
 
AFTER: lock count = 1    
------------------------------------------------
So the lock is not released, as you can see. 

Information that may be relevant:
RedHat 7.0
avs % rpm -q glibc libstdc++ gcc
glibc-2.1.94-3
libstdc++-2.96-54
gcc-2.96-54

Comment 1 Jakub Jelinek 2000-11-21 07:01:26 UTC

*** This bug has been marked as a duplicate of 18339 ***