This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
libstdc++/9914: multi-thread problem within default allocator
- From: markus dot breuer at materna dot de
- To: gcc-gnats at gcc dot gnu dot org
- Cc: markus dot breuer at gmx dot de
- Date: 3 Mar 2003 08:11:45 -0000
- Subject: libstdc++/9914: multi-thread problem within default allocator
- Reply-to: markus dot breuer at materna dot de
>Number: 9914
>Category: libstdc++
>Synopsis: multi-thread problem within default allocator
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Mar 03 08:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: markus dot breuer at materna dot de
>Release: gcc 2.95.3
>Organization:
>Environment:
SUN Solaris 5.7 / multi-processor
>Description:
The default allocator crashes in stl_alloc.h line 422.
The access to the static variable seems not to be threadsafe on read-access. The used Lock (mutex) guards the write-access only. On multi-processor machines the mem-read is non atomic which results, so the result may be undefined.
Affected are all parts using the default allocator, this includes any stl-container.
>How-To-Repeat:
Sorry, but a sample application does not show the bug. It seems you need large scale application with heavy allocator usage and multi-threading. Any small application runs fine.
But take a look at stl_alloc.h to verify.
>Fix:
The read-access should be guarded, too. It should be ok when moving the lock() before the read-access. Possibly i will verify it in a few days, but currently i have not enough harddisk-space to rebuild the whole gcc.
>Release-Note:
>Audit-Trail:
>Unformatted: