From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25322 invoked by alias); 10 Jan 2002 12:56:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 25268 invoked by uid 71); 10 Jan 2002 12:56:01 -0000 Resent-Date: 10 Jan 2002 12:56:01 -0000 Resent-Message-ID: <20020110125601.25267.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, markus.breuer@materna.de Resent-Reply-To: gcc-gnats@gcc.gnu.org, markus.breuer@materna.de Received:(qmail 24509 invoked by uid 61); 10 Jan 2002 12:54:17 -0000 Message-Id:<20020110125417.24508.qmail@sources.redhat.com> Date: Thu, 10 Jan 2002 04:56:00 -0000 From: markus.breuer@materna.de Reply-To: markus.breuer@materna.de To: gcc-gnats@gcc.gnu.org Cc: markus.breuer@materna.de X-Send-Pr-Version:gnatsweb-2.9.3 (1.1.1.1.2.31) X-GNATS-Notify:markus.breuer@materna.de Subject: libstdc++/5347: implementation is not thread-safe on multi-processor machines X-SW-Source: 2002-01/txt/msg00407.txt.bz2 List-Id: >Number: 5347 >Category: libstdc++ >Synopsis: implementation is not thread-safe on multi-processor machines >Confidential: no >Severity: serious >Priority: high >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Jan 10 04:56:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: markus.breuer@materna.de >Release: up to current release >Organization: >Environment: sun solaris 2.7/2.8 (multi-processor machine) gcc 2.95.3 up to 3.0.x >Description: The libstdc++ implementation is not really thread-safe. Currently we allocate ostrstreams/ostrstreams with new and free them immediatelly with delete. There's no access the the objects (except new and delete), but the application sometimes crashes. The main problem are static variables within streambuf (and perhaps other classes). When instantiating an derived object (e.g. filestreambuf), this variables are accessed. On a single processor machine these accesses may be atomic ( depending on hardware), but an a real multi-processor environment they are not atomic. When running our application on a single processor machine, there are no further problems, but on multi-processor there are unavoidable system crashes (core dumps). >How-To-Repeat: Compile and run the attached program on a (sun!?) multi-processor machine >Fix: To fix the problem the access to any global variable must be synchronized. Search the libstdc++ for any static variable (streambuf/basic_string/etc) and use atomicity to synchronize any access to it. Any access, read and write, must be synchronized. The basic_string class uses atmicity to synchronize access to nulRep and Rep. But only the write access is synchronized. In a multi-processor environment the write access of, for example an pointer, is not atomic. So its read-access must be guarded by atomicity. >Release-Note: >Audit-Trail: >Unformatted: ----gnatsweb-attachment---- Content-Type: application/octet-stream; name="HMSTestApp.cpp"; name="HMSTestApp.cpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="HMSTestApp.cpp" Ly8gY21kOiBnKysgSE1TVGVzdEFwcC5jcHAgLWcgLXB0aHJlYWRzCgojaW5jbHVkZSA8c3RyaW5n PgojaW5jbHVkZSA8ZnN0cmVhbT4KI2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8c3Ryc3Ry ZWFtPgojaW5jbHVkZSA8dW5pc3RkLmg+CgojaW5jbHVkZSA8cHRocmVhZC5oPgojaW5jbHVkZSA8 dGhyZWFkLmg+Cgpjb25zdCBpbnQgbWF4X3RocmVhZF9jb3VudCA9IDE2Owp2b2xhdGlsZSBpbnQg cnVubmluZ1RocmVhZHMgPSBtYXhfdGhyZWFkX2NvdW50OwoKcHRocmVhZF90IHRpZFsgbWF4X3Ro cmVhZF9jb3VudCBdOwoKdXNpbmcgbmFtZXNwYWNlIHN0ZDsKCnZvaWQqIHRocmVhZF9tYWluKCB2 b2lkICogKQp7CiAgIHN0ZDo6Y291dCA8PCAiRW50ZXJpbmcgdGhyZWFkICMiIDw8IHB0aHJlYWRf c2VsZigpIDw8ICIuLi4iIDw8IHN0ZDo6ZW5kbDsKICAgCiAgIGludCBtYXggPTEwMDAwMDA7Cgog ICB3aGlsZSggbWF4LS0gKQogICB7CiAgICAgIHRocl95aWVsZCgpOwogICAgICAKICAgICAgb3N0 cnN0cmVhbSAqcG9zOwogICAgICBvZnN0cmVhbSAqcG9zMTsKICAgICAgcG9zID0gbmV3IG9zdHJz dHJlYW07ICAgICAgCiAgICAgIC8vIHNvbWV0aW1lcyBkZWxldGUgdGhyb3dzIGEgY29yZSBkdW1w CiAgICAgIGRlbGV0ZSBwb3M7CiAgICAgIHBvczEgPSBuZXcgb2ZzdHJlYW07CiAgICAgIC8vIHNv bWV0aW1lcyBkZWxldGUgdGhyb3dzIGEgY29yZSBkdW1wCiAgICAgIGRlbGV0ZSBwb3MxOwogICAg ICAKICAgICAgaWYgKG1heCUxMDAgPT0gMCApCiAgICAgIGNvdXQgPDwgIiMiIDw8IHB0aHJlYWRf c2VsZigpIDw8IGVuZGw7CiAgIH0KICAgcnVubmluZ1RocmVhZHMtLTsKICAgc3RkOjpjb3V0IDw8 ICJMZWF2aW5nIHRocmVhZCAjIiA8PCBwdGhyZWFkX3NlbGYoKSA8PCAiLi4uIiA8PCBzdGQ6OmVu ZGw7CiAgIAogICByZXR1cm4gMDsKfQoKCmludCBtYWluKCkKewogICBpbnQgY3RyOwogICAKICAg c3RkOjpjb3V0IDw8ICJTdGFydHVwIC4uLiIgPDwgc3RkOjplbmRsOwogICAKICAgZm9yKCBjdHI9 MDsgY3RyIDwgbWF4X3RocmVhZF9jb3VudDsgY3RyKysgKQogICB7CiAgICAgIHB0aHJlYWRfdCBw dCA9IHB0aHJlYWRfY3JlYXRlKCAmdGlkW2N0cl0sIE5VTEwsIHRocmVhZF9tYWluLCAwICk7CiAg ICAgIHN0ZDo6Y291dCA8PCAidGhyZWFkICIgPDwgY3RyKzEgPDwgIiBzdGFydGVkIC4uLiIgPDwg c3RkOjplbmRsOwogICB9CiAgIHdoaWxlICggcnVubmluZ1RocmVhZHMgKQogICAgICBzbGVlcCgg MSApOyAgIAogICBzdGQ6OmNvdXQgPDwgIlNodXRkb3duIC4uLiIgPDwgc3RkOjplbmRsOyAgICAg IAogICAKICAgcmV0dXJuIDA7Cn0KCg==