Bug 104064

Summary: random SEGVs with libstdc++ & detached pthreads
Product: [Retired] Red Hat Linux Reporter: David Copp <rh-bugzilla>
Component: libstdc++Assignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-07 14:47:56 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:
Attachments:
Description Flags
test program that reproduces the SEGV
none
Updated test case program that consistently produces heap bug none

Description David Copp 2003-09-09 16:08:33 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.11 (X11; Linux i686; U;) Gecko/20030417

Description of problem:
A small C++ program creates one or more detached pthreads, and all threads use
ostringstream, string, etc. classes that bang on the heap. Eventually a SEGV
occurs in either malloc_consolidate, _int_malloc, or something similar. The
caller is libstdc++ -- typically to allocate/free memory. The heap is clearly
being corrupted. Yet the program I use to reproduce the problem does not appear
to contain any illegal memory references.

Version-Release number of selected component (if applicable):
glibc-2.3.2-4.80.6

How reproducible:
Always

Steps to Reproduce:
1.Compile the attached test program:
  $ g++ -pthread -Wall -g    heap-banger.cpp   -o heap-banger
2.Run it:
  $ heap-banger
3. Wait for the SEGV. It may take a second, a minute, or several minutes. On my
system it often takes just 1-15 seconds.

Actual Results:  test program runs forever

Expected Results:  test program eventually receives SEGV

Additional info:

My test program includes a trivial DetachedThread class wrapping a detached
pthread. A DetachedThread is new'd by the main thread and deletes itself when it
exits. So far I have been unable to reproduce the SEGV with smaller test
programs that don't bang on the heap in this way.
Comment 1 David Copp 2003-09-09 16:12:58 UTC 
Created attachment 94332 [details]
test program that reproduces the SEGV

Compiled thusly:
g++ -pthread -Wall -g	 heap-banger.cpp   -o heap-banger

I believe -pthread defines _REENTRANT. I get the SEGV whether or not I add
-D_REENTRANT to the above compilation line.

My system has a single CPU (Duron 90MHz).
Comment 2 David Copp 2003-09-09 16:15:49 UTC 
"Actual" and "Expected" results in the report are backwards! Sorry.
Comment 3 David Copp 2003-09-09 16:17:43 UTC 
Open bugs that may be related to this one are 71354 and 82433. But I couldn't
find an exact match...
Comment 4 David Copp 2003-09-09 16:42:03 UTC 
Component changed from glibc => libstdc++.
libstdc++-3.2-7 that is.
Comment 5 David Copp 2003-09-16 15:01:13 UTC 
Created attachment 94523 [details]
Updated test case program that consistently produces heap bug

Compiled thusly:

 g++ -g -fpic -pthread -lpthread -ldmallocthcxx test-heap.cpp -o test-heap

I used dmalloc-5.2.2-1.
Comment 6 David Copp 2003-09-16 15:13:09 UTC 
With the updated test-heap.cpp program, a heap corruption is detected almost
immediately and fairly consistently -- always after either 16 or 17 passes
through the inner loop on my machine.
Comment 7 Jakub Jelinek 2004-10-07 14:47:56 UTC 
With GCC 3.4.2-2, I certainly can't reproduce any segfaults and
neither valgrind reports any problems on it.

Assume this has been fixed.