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.
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).
"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 Compiled thusly: 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.