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):
Steps to Reproduce:
1.Compile the attached test program:
$ g++ -pthread -Wall -g heap-banger.cpp -o 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
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.
Created attachment 94332 [details]
test program that reproduces the SEGV
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).
"Actual" and "Expected" results in the report are backwards! Sorry.
Open bugs that may be related to this one are 71354 and 82433. But I couldn't
find an exact match...
Component changed from glibc => libstdc++.
libstdc++-3.2-7 that is.
Created attachment 94523 [details]
Updated test case program that consistently produces heap bug
g++ -g -fpic -pthread -lpthread -ldmallocthcxx test-heap.cpp -o test-heap
I used dmalloc-5.2.2-1.
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.
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.