public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/9914: multi-thread problem within default allocator
@ 2003-03-03 22:23 ljrittle
  0 siblings, 0 replies; 2+ messages in thread
From: ljrittle @ 2003-03-03 22:23 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, markus.breuer, markus.breuer, nobody

Synopsis: multi-thread problem within default allocator

State-Changed-From-To: open->closed
State-Changed-By: ljrittle
State-Changed-When: Mon Mar  3 22:23:57 2003
State-Changed-Why:
    This type of MP bug is fixed in libstdc++-v3 as shipped with gcc 3.x.  To our knowledge, no one is supporting libstdc++-v2 as was shipped with 2.95.3.  FYI, there were MP bugs in early releases of 3.x for Sparc thus I'd recommend upgrading to 3.2.2, if possible.  Otherwise,
    you will probably need to support yourself.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9914


^ permalink raw reply	[flat|nested] 2+ messages in thread

* libstdc++/9914: multi-thread problem within default allocator
@ 2003-03-03  8:16 markus.breuer
  0 siblings, 0 replies; 2+ messages in thread
From: markus.breuer @ 2003-03-03  8:16 UTC (permalink / raw)
  To: gcc-gnats; +Cc: markus.breuer


>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:


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-03-03 22:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-03 22:23 libstdc++/9914: multi-thread problem within default allocator ljrittle
  -- strict thread matches above, loose matches on Subject: below --
2003-03-03  8:16 markus.breuer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).