Bug 104064 - random SEGVs with libstdc++ & detached pthreads
random SEGVs with libstdc++ & detached pthreads
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: libstdc++ (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-09 12:08 EDT by David Copp
Modified: 2007-04-18 12:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-07 10:47:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program that reproduces the SEGV (1.18 KB, text/plain)
2003-09-09 12:12 EDT, David Copp
no flags Details
Updated test case program that consistently produces heap bug (1.59 KB, text/plain)
2003-09-16 11:01 EDT, David Copp
no flags Details

  None (edit)
Description David Copp 2003-09-09 12:08:33 EDT
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 12:12:58 EDT
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 12:15:49 EDT
"Actual" and "Expected" results in the report are backwards! Sorry.
Comment 3 David Copp 2003-09-09 12:17:43 EDT
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 12:42:03 EDT
Component changed from glibc => libstdc++.
libstdc++-3.2-7 that is.
Comment 5 David Copp 2003-09-16 11:01:13 EDT
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 11:13:09 EDT
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 10:47:56 EDT
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.

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