Bug 21108 - Locks not freed in iostreams (endl)
Summary: Locks not freed in iostreams (endl)
Keywords:
Status: CLOSED DUPLICATE of bug 18339
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libstdc++
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-11-20 02:45 UTC by Andrey Shytov
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-11-20 02:45:54 UTC
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.