http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636
Bug #: 51636
Summary: Thread-safeness of new and delete operators
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@pyrillion.org
Dear colleagues,
I had a nasty thread-safeness bug that I finally did not track down completely
(but solved).
My system: Linux ubuntu 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
My gcc: gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
libstdc++: libstdc++.so.6.0.16
Problem: application crashes if too many concurrent POSIX threads get started
Description: application is platform-independent; was developed for Win32/Win64
and Linux 32bit/64bit
If executed with valgrind/hellgrind (Linux) or Microsoft Application Verifier
(Windows 7/64bit), then no errors occur.
If executed on above mentioned host AND more than 100 concurrent threads
performing a lot of new/delete operations, then memory clobbered. Application
was tested using valgrind or GNU mprobe, respectively. GNU mprobe aborts
application with memory clobbered before memory block. All sources compiled
with "-pthread", "-fpic". Error occurs with Debug and Release build. POSIX
threads are performing a mix of new/delete/malloc/free and use thread-specific
data.
My fix: Wrote another shared object implementing malloc/calloc/free/realloc,
new/delete/new[]/delete[] with and without throw(std::bad_alloc). Linking this
shared object to my application fixes the problem.
Guess: the new/new[] operators throwing std::bad_alloc have a MT-safeness
problem.
Sorry for this obfuscating bug report but I am not allowed to disclose more
information. Maybe someone ran into this bug?, too?
