[Bug libstdc++/51636] New: Thread-safeness of new and delete operators

[Bug libstdc++/51636] New: Thread-safeness of new and delete operators

[ingo at pyrillion dot org]

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: unassigned@gcc.gnu.org
        ReportedBy: ingo@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?

[Bug libstdc++/51636] Thread-safeness of new and delete operators

[ingo at pyrillion dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636

Ingo K. <ingo at pyrillion dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor

[Bug libstdc++/51636] Thread-safeness of new and delete operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-12-20
     Ever Confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-20 19:48:56 UTC ---
Without a self contained testcase nothing will happen, per the bug reporting
instructions. Please attach one or the bug will be soon closed. Thanks.

[Bug libstdc++/51636] Thread-safeness of new and delete operators

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-24 19:41:54 UTC ---
>Guess: the new/new[] operators throwing std::bad_alloc have a MT-safeness
problem.

They should not as they are just wrappers around malloc.

[Bug libstdc++/51636] Thread-safeness of new and delete operators

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
Information not coming.