From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-30335-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10148 invoked by alias); 3 Mar 2003 08:16:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 10128 invoked by uid 71); 3 Mar 2003 08:16:00 -0000
Resent-Date: 3 Mar 2003 08:16:00 -0000
Resent-Message-ID: <20030303081600.10127.qmail@sources.redhat.com>
Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer)
Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, markus.breuer@gmx.de
Resent-Reply-To: gcc-gnats@gcc.gnu.org, markus.breuer@materna.de
Received: (qmail 9104 invoked by uid 48); 3 Mar 2003 08:11:45 -0000
Message-Id: <20030303081145.9103.qmail@sources.redhat.com>
Date: Mon, 03 Mar 2003 08:16:00 -0000
From: markus.breuer@materna.de
Reply-To: markus.breuer@materna.de
To: gcc-gnats@gcc.gnu.org
Cc: markus.breuer@gmx.de
X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31)
X-GNATS-Notify: markus.breuer@gmx.de
Subject: libstdc++/9914: multi-thread problem within default allocator
X-SW-Source: 2003-03/txt/msg00065.txt.bz2
List-Id: <gcc-prs.sourceware.org>


>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.breuer@materna.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: