libstdc++/5444: in multi-processor environment basic_string ist not thread safe

libstdc++/5444: in multi-processor environment basic_string ist not thread safe

[markus.breuer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6670 bytes --]


>Number:         5444
>Category:       libstdc++
>Synopsis:       in multi-processor environment basic_string ist not thread safe
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 21 12:36:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     markus.breuer@materna.de
>Release:        shipped with gcc 3.0.3 (3.0.951ß9
>Organization:
>Environment:
SUN Solaris 2.8
multi-processor machine
>Description:
This bug is not a clone of libstdc++/5037

I tested gcc 3.0.3 with a small sample application when the memory allocation became corrupt. After some time the process size grows up to maximum of available memory. Then the application runs out of memory und tries to write a core dump. Because of less free disk space this core is not comletly ritten.
I also applied the fix for atomcity (not yet released, but in 3.1-stream), but it seems not to solve the problem. When starting the application in a single processor machine, there are no problems.

In my opinion there are two possible problems:

1. The atomicity works fine, but because of the mass of strings the reference counter becomes an overflow. I could not see any protection in the context of basic_string. But I also could not find any hint (within the debugger) that an overflow may occure. The conditional breakpoint at the reference counter never reached a size of 1000 or more.

2. The atomicity does not work correct or there are accesses which are not synchronized. The changing accesses are done by using atomicity.h. But simple read accesses are done directly (see at header for example in _M_is_shared() in bits/basic_string.h.)

I allready mailed nathan myers, who was involved in the basic_string implementation. I am not sure if he found any error, but I am really sure that gcc 3.0.3 (with the patch you described) is not stable when running my application.

Currently I am using a mix of 2.95.3 and 3.x-atomicity. This mix runs without any problem. But because of the new implementation I am not able to apply my changes to the new implementation, nearly everthing is new.

While fixing gcc 2.95.3 I found out, that the usage of only one global synchronizer for any string may be a bottle neck. So I decided to remove the global string synchronizer, instead of this I added it to the Rep structure. It works while using chunks of 16 byte, so my additional byte requires not really more effort or memory usage. As result shared Rep's use their own synchronizing atomic char. After this change my test-application was running much faster . I saw it on the terminal. Also there was less cpu usage. 

I think the atomic implementations behavior is like following:

/* !!! atomic uses more than on instruction to implement mutex !!! */
/* lock */
do { 
   current = atomics_value; // a context switch to an thread running on another processor 
				    // will force the other thread to loop until current thread unlocks
                            // the mutex => active waiting
} while( current != 0 );

>How-To-Repeat:
It seems there is a relationship between processor idle time and the core dumps. To repeat the error try to start two or three instances of the application. Open a further shell running top-command (interval 1s) and watch the applications memory usage. After about half a minute one processes memory usage will grow.
>Fix:
No real idea. 
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="stringtest.cpp"; name="stringtest.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="stringtest.cpp"

Ci8vIGcrKyBzdHJpbmd0ZXN0LmNwcCAtcHRocmVhZHMgLWc6CgovLyNkZWZpbmUgX1BUSFJFQURT
Ci8vI2RlZmluZSBfU09MVEhSRUFEUwovLyNkZWZpbmUgX1JFRU5UUkFOVAojaW5jbHVkZSA8cHRo
cmVhZC5oPgojaW5jbHVkZSA8dGhyZWFkLmg+CgojaW5jbHVkZSA8dW5pc3RkLmg+CiNpbmNsdWRl
IDxpb3N0cmVhbT4KI2luY2x1ZGUgPHN0cmluZz4KI2luY2x1ZGUgPG1hcD4KI2luY2x1ZGUgPHZl
Y3Rvcj4KI2luY2x1ZGUgPHN0cnN0cmVhbT4KCmNvbnN0IGludCBtYXhfdGhyZWFkX2NvdW50ID0g
ODsKdm9sYXRpbGUgaW50IHJ1bm5pbmdUaHJlYWRzID0gbWF4X3RocmVhZF9jb3VudDsKY29uc3Qg
Y2hhciogbXlfZGVmYXVsdCA9ICJIYWxsbyBXZWx0ISI7Cgpjb25zdCBpbnQgdXBwZXJfbGltaXQg
PSAyNTAwOwpjb25zdCBpbnQgbG93ZXJfbGltaXQgPSAxMDAwOwoKdHlwZWRlZiBjaGFyIGNoYXJU
OwovL3R5cGVkZWYgc3RyaW5nX2NoYXJfdHJhaXRzPGNoYXJUPiB0cmFpdHNUOwovL3R5cGVkZWYg
YWxsb2NhdG9yPHRyYWl0c1Q+IGFsbG9jVDsKCi8vY2xhc3MgTXlBbGxvY2F0b3IgOiBwdWJsaWMg
YWxsb2NUCi8vewovL307CgovL3R5cGVkZWYgYmFzaWNfc3RyaW5nPCBjaGFyVCwgdHJhaXRzVD4g
U3RyaW5nOwovL3R5cGVkZWYgYmFzaWNfc3RyaW5nPGNoYXIsc3RyaW5nX2NoYXJfdHJhaXRzPGNo
YXI+LCBtYWxsb2NfYWxsb2M+IFN0cmluZzsKdHlwZWRlZiBzdGQ6OnN0cmluZyBTdHJpbmc7Cgpj
bGFzcyBGYWtlCnsKICAgY2hhciAqIG1fcHRyOwpwdWJsaWM6CiAgIEZha2UoKSB7IG1fcHRyID0g
bmV3IGNoYXJbMTAwXTsgfQogICB+RmFrZSgpIHsgZGVsZXRlIG1fcHRyOyB9Cn07CgpwdGhyZWFk
X3QgdGlkWyBtYXhfdGhyZWFkX2NvdW50IF07Cgp0eXBlZGVmIFN0cmluZyBNeVR5cGU7Cgp2b2lk
KiB0aHJlYWRfbWFpbiggdm9pZCAqICkKewogICB1bnNpZ25lZCBpbnQgbG9vcCA9IDA7CiAgIAog
ICBzdGQ6OmNvdXQgPDwgIkVudGVyaW5nIHRocmVhZCAuLi4iIDw8IHN0ZDo6ZW5kbDsKICAgCiAg
IHR5cGVkZWYgc3RkOjptYXA8dW5zaWduZWQgaW50LE15VHlwZT4gTWFwOwogICB0eXBlZGVmIE1h
cDo6dmFsdWVfdHlwZSBWYWx1ZV9QYWlyOwogICBNYXAgbXlNYXA7CiAgIGRvIHsKICAgICAgY2hh
ciBidWZmZXJbMzJdOwogICAgICAKICAgICAgc3RkOjpvc3Ryc3RyZWFtIG9zcyggYnVmZmVyLCBz
aXplb2YoYnVmZmVyKSApOwogICAgICBvc3MgPDwgbG9vcCA8PCAnXDAnOwogICAgICAKICAgICAg
U3RyaW5nJiBzdHIgPSBteU1hcFtsb29wXTsKICAgICAgc3RyLmFwcGVuZCggbXlfZGVmYXVsdCAp
OwogICAgICAvL215TWFwLmluc2VydCggVmFsdWVfUGFpciggbG9vcCwgc3RyICkgKTsKICAgICAg
bG9vcCsrOwogICAgICAKICAgICAgaWYgKCBteU1hcC5zaXplKCkgPiB1cHBlcl9saW1pdCApCiAg
ICAgIHsKICAgICAgICAgc3RkOjpjb3V0IDw8ICJjbGVhbmluZyB1cCAuLi4iIDw8IHN0ZDo6ZW5k
bDsgICAgICAgICAgICAKICAgICAgICAgd2hpbGUoIG15TWFwLnNpemUoKSA+IGxvd2VyX2xpbWl0
ICkKICAgICAgICAgewogICAgICAgICAgICBNYXA6Oml0ZXJhdG9yIGl0ID0gbXlNYXAuYmVnaW4o
KTsKICAgICAgICAgICAgbXlNYXAuZXJhc2UoIGl0ICk7CiAgICAgICAgIH0KICAgICAgICAgc2xl
ZXAoIDUgKTsKICAgICAgfQogICAgICAKICAgfSB3aGlsZSAoIGxvb3AgKTsKICAgc3RkOjpjb3V0
IDw8ICJMZWF2aW5nIHRocmVhZCAuLi4iIDw8IHN0ZDo6ZW5kbDsKICAgcnVubmluZ1RocmVhZHMt
LTsKfQoKCmludCBtYWluKCkKewogICBpbnQgY3RyOwogICAKICAgc3RkOjpjb3V0IDw8ICJTdGFy
dHVwIC4uLiIgPDwgc3RkOjplbmRsOwogICAKICAgZm9yKCBjdHI9MDsgY3RyIDwgbWF4X3RocmVh
ZF9jb3VudDsgY3RyKysgKQogICB7CiAgICAgIHB0aHJlYWRfdCBwdCA9IHB0aHJlYWRfY3JlYXRl
KCAmdGlkW2N0cl0sIE5VTEwsIHRocmVhZF9tYWluLCAwICk7CiAgICAgIHN0ZDo6Y291dCA8PCAi
dGhyZWFkICIgPDwgY3RyKzEgPDwgIiBzdGFydGVkIC4uLiIgPDwgc3RkOjplbmRsOwogICB9CiAg
IHdoaWxlKCBydW5uaW5nVGhyZWFkcyApCiAgICAgIHNsZWVwICggMSk7CiAgICAgIAogICBzdGQ6
OmNvdXQgPDwgIlNodXRkb3duIC4uLiIgPDwgc3RkOjplbmRsOyAgICAgIAogICAKICAgCiAgIHJl
dHVybiAwOwp9Cg==

Re: libstdc++/5444: in multi-processor environment basic_string ist not thread safe

[ljrittle]

Synopsis: in multi-processor environment basic_string ist not thread safe

State-Changed-From-To: analyzed->closed
State-Changed-By: ljrittle
State-Changed-When: Thu Jan 24 13:48:44 2002
State-Changed-Why:
    Testcase added.  Same as libstdc++/5432.  Patch on
    mainline.

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

Re: libstdc++/5444: in multi-processor environment basic_string ist not thread safe

[ljrittle]

Synopsis: in multi-processor environment basic_string ist not thread safe

Responsible-Changed-From-To: ljrittle->unassigned
Responsible-Changed-By: ljrittle
Responsible-Changed-When: Tue Jan 22 14:13:19 2002
Responsible-Changed-Why:
    Doesn't look as related to the part of the code base
    I understand as I originally thought.
State-Changed-From-To: feedback->analyzed
State-Changed-By: ljrittle
State-Changed-When: Tue Jan 22 14:13:19 2002
State-Changed-Why:
    Agreed, I can reproduce the reduced test case failure
    on a two-way MP sparc-sun-solaris2.7 machine using
    gcc 3.0.3+"sparc atomicity patch".  Parts of 
    the reduced test case violate libstdc++-v3 threading
    rules but I agree that ``std::ostringstream oss''
    should be concurrently executable in different threads
    and is the root cause of a core dump.

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

Re: libstdc++/5444: in multi-processor environment basic_string ist not thread safe

[Reichelt]

The following reply was made to PR libstdc++/5444; it has been noted by GNATS.

From: Reichelt <reichelt@igpm.rwth-aachen.de>
To: gcc-gnats@gcc.gnu.org, ljrittle@gcc.gnu.org, markus.breuer@materna.de,
        gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/5444: in multi-processor environment basic_string ist not thread safe
Date: Tue, 22 Jan 2002 17:49:10 +0100

 Hi,
 
 I can confirm the problems with the example in PR5444.
 I compiled the program with gcc 3.1-20020121 (configured with
 "--enable-threads") on a dual i686-pc-linux-gnu box.
 Running it I get segfaults most of the time, but no memory growth.
 I only need to run one instance to get the segfault.
 
 I tried to reduce the exapmle a little bit and to get rid of the
 deprecated header <strstream> and came up with to following example
 that crashes within less than a second most of the time
 (just compile with "g++ filename.cpp -lpthread"):
 
 #include <pthread.h>
 #include <unistd.h>
 #include <iostream>
 #include <sstream>
 
 const int max_thread_count = 8;
 volatile int runningThreads = max_thread_count;
 
 pthread_t tid[ max_thread_count ];
 
 void* thread_main (void*)
 {
    std::cout << "Entering thread ..." << std::endl;
 
    for (int i=0; i<10000; ++i )
       std::ostringstream oss;
 
    std::cout << "Leaving thread ..." << std::endl;
    runningThreads--;
 }
 
 
 int main()
 {
    std::cout << "Startup ..." << std::endl;
 
    for ( int i=0; i < max_thread_count; ++i )
    {
       pthread_create( &tid[i], 0, thread_main, 0 );
       std::cout << "thread " << i+1 << " started ..." << std::endl;
    }
 
    while ( runningThreads )
       sleep (1);
 
    std::cout << "Shutdown ..." << std::endl;
 
    return 0;
 }
 
 The problem seems to be hidden in the command "std::ostringstream oss;".
 If I replace it with some different dummy code, everything works fine.
 
 Greetings,
 Volker Reichelt
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5444
 
 

Re: libstdc++/5444: in multi-processor environment basic_string ist not thread safe

[ljrittle]

Synopsis: in multi-processor environment basic_string ist not thread safe

Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-By: ljrittle
Responsible-Changed-When: Mon Jan 21 13:51:04 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->feedback
State-Changed-By: ljrittle
State-Changed-When: Mon Jan 21 13:51:04 2002
State-Changed-Why:
    I couldn't reproduce this problem on a sparc-sun-solaris2.7
    dual-processor machine against gcc 3.0.4 prerelease.
    
    I saw no boundless memory growth or crashes with
    1 or 2 copies of the test program running.

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