Bug 104064 - random SEGVs with libstdc++ & detached pthreads
Summary: random SEGVs with libstdc++ & detached pthreads
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libstdc++ (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-09-09 16:08 UTC by David Copp
Modified: 2007-04-18 16:57 UTC (History)
0 users

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


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

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.


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