public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
@ 2002-01-19  7:26 andrew
  0 siblings, 0 replies; 5+ messages in thread
From: andrew @ 2002-01-19  7:26 UTC (permalink / raw)
  To: gcc-gnats; +Cc: andrew


>Number:         5432
>Category:       libstdc++
>Synopsis:       Implementation still not thread-safe on multiprocessor machines
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 19 07:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     andrew@andypo.net
>Release:        gcc-3.0.4-cvs-20020116
>Organization:
>Environment:
System: SunOS primo 5.6 Generic_105181-26 sun4u sparc SUNW,Ultra-4
Architecture: sun4configured with: /disks/nermal/andrewp/cvs/gcc-3_0-branch/configure --prefix=/opt/gcc-3.0.4-20020116-sparc-sun-solaris2.6-gnu-asld --with-gnu-as --with-gnu-ld --enable-threads=solaris --enable-version-specific-runtime-libs --disable-shared --enable-languages=c++
[ This is on a 4 processor machine ]

>Description:
[ Re libstdc++/5347 and libstdc++/5037 ]

In our project which is heavily multi-threaded we would occasionally get randon crashes which were associated with the iostreams code.

Managed to get it down to a very small test case which indicates the problems.

[ I'm also not sure that the file attachments have worked, I'm sending them to the gcc-mailing list as well.... ]
>How-To-Repeat:
Compile and run the attached program with gcc-3.0.x on a multiprocessor system (in this case UltraSparc/Solaris6, but similar things happen on a dual processor i686/Redhat7.2). Sometimes it will work, sometimes you will get a Bus Error and sometimes a Segmentation Fault

% /opt/gcc-3.0.4-20020116-sparc-sun-solaris2.6-gnu-asld/bin/g++ -g main.cxx -lpthread
% a.out
% a.out
% a.out
Bus error (core dumped)
% gdb a.out core
[...]
(gdb) where
#0  0x00020270 in std::__ctype_abstract_base<char>::widen(char) const ()
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/locale_facets.h:97
#1  0x0001fdd4 in std::basic_ios<char, std::char_traits<char> >::widen(char) const (this=0xef109ccc, __c=32 ' ')
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/locale_facets.h:97
#2  0x0001f850 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) (this=0xef109ccc, __sb=0x0)
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/basic_ios.tcc:125
#3  0x0001f918 in std::istream::istream(std::basic_streambuf<char, std::char_traits<char> >*) ()
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/std_istream.h:74
#4  0x0001f4e8 in std::iostream::iostream(std::basic_streambuf<char, std::char_traits<char> >*) (this=0xef109ccc, __vtt_parm=0x4be1c, __sb=0x0)
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/std_istream.h:274
#5  0x0001f318 in std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::_Ios_Openmode) (this=0xef109c70, 
    __m=24)
    at /opt/gcc-3.0.4-20020116-sparc-sun-solaris2.6-gnu-asld/lib/gcc-lib/sparc-sun-solaris2.6/3.0.4/include/g++/bits/std_sstream.h:331
#6  0x000113ac in threadFunc () at main.cxx:11
(gdb) quit

% a.out
% a.out
% a.out
Segmentation fault (core dumped)
% gdb a.out core
[...]
(gdb) where
#0  0x00000000 in ?? ()
#1  0x00017678 in std::locale::facet::_M_remove_reference() (this=0x59d48)
    at /disks/nermal/andrewp/cvs/gcc-3_0-branch/libstdc++-v3/src/locale.cc:537
#2  0x00019c90 in std::locale::_Impl::~_Impl() (this=0x592d8)
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/stl_iterator.h:478
#3  0x00023fc4 in std::locale::_Impl::_M_remove_reference() (this=0x592d8)
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/localefwd.h:332
#4  0x00016fc0 in std::locale::operator=(std::locale const&) (this=0xef109d30, 
    __other=@0xef1099f8)
    at /disks/nermal/andrewp/cvs/gcc-3_0-branch/libstdc++-v3/src/locale.cc:406
#5  0x00016224 in std::ios_base::_M_init() (this=0xef109d30)
    at /disks/nermal/andrewp/cvs/gcc-3_0-branch/libstdc++-v3/src/ios.cc:267
#6  0x0001f824 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) (this=0xef109ccc, __sb=0x0)
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/basic_ios.tcc:122
#7  0x0001f918 in std::istream::istream(std::basic_streambuf<char, std::char_traits<char> >*) ()
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/std_istream.h:74
#8  0x0001f4e8 in std::iostream::iostream(std::basic_streambuf<char, std::char_traits<char> >*) (this=0xef109ccc, __vtt_parm=0x4be1c, __sb=0x0)
    at /disks/primo4/workplaces/andrewp/gnu/gcc-3.0.4-20020116-build/sparc-sun-solaris2.6/libstdc++-v3/include/bits/std_istream.h:274
#9  0x0001f318 in std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::_Ios_Openmode) (this=0xef109c70, 
    __m=24)
    at /opt/gcc-3.0.4-20020116-sparc-sun-solaris2.6-gnu-asld/lib/gcc-lib/sparc-sun-solaris2.6/3.0.4/include/g++/bits/std_sstream.h:331
#10 0x000113ac in threadFunc () at main.cxx:11
(gdb) quit
>Fix:
With the attached patch, the attached program 'always' seems to work (I had it in a while loop running for about an hour...)

I don't make any guarantees for the correctness of the patch, but it definitely addresses some of the 'XXX MT' issues in the source code (eg using _Atomic_word, __atomic_add, __exchange_and_add and a lock)

The gcc-3.1 cvs code is very similar, if not the same...
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="patch"

SW5kZXg6IGluY2x1ZGUvYml0cy9pb3NfYmFzZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMv
Z2NjL2djYy9saWJzdGRjKystdjMvaW5jbHVkZS9iaXRzL2lvc19iYXNlLmgsdgpyZXRyaWV2aW5n
IHJldmlzaW9uIDEuOC4yLjMKZGlmZiAtdSAtcjEuOC4yLjMgaW9zX2Jhc2UuaAotLS0gaW9zX2Jh
c2UuaAkyMDAxLzA2LzA2IDAxOjM5OjAwCTEuOC4yLjMKKysrIGlvc19iYXNlLmgJMjAwMi8wMS8x
NyAxMjo1MzozOApAQCAtMzYsNiArMzYsOCBAQAogCiAjcHJhZ21hIEdDQyBzeXN0ZW1faGVhZGVy
CiAKKyNpbmNsdWRlIDxiaXRzL2F0b21pY2l0eS5oPgorCiBuYW1lc3BhY2Ugc3RkCiB7CiAgIC8v
IFRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbnMgb2YgYml0bWFzayB0eXBlcyBhcmUgZW51bXMsIG5v
dCBpbnRzLApAQCAtMjM5LDE3ICsyNDEsMTcgQEAKICAgICAgIF9DYWxsYmFja19saXN0KiAJCV9N
X25leHQ7CiAgICAgICBpb3NfYmFzZTo6ZXZlbnRfY2FsbGJhY2sgCV9NX2ZuOwogICAgICAgaW50
IAkJCV9NX2luZGV4OwotICAgICAgaW50IAkJCV9NX3JlZmNvdW50OyAgLy8gMCBtZWFucyBvbmUg
cmVmZXJlbmNlLgorICAgICAgX0F0b21pY193b3JkCQlfTV9yZWZjb3VudDsgIC8vIDAgbWVhbnMg
b25lIHJlZmVyZW5jZS4KICAgICAKICAgICAgIF9DYWxsYmFja19saXN0KGlvc19iYXNlOjpldmVu
dF9jYWxsYmFjayBfX2ZuLCBpbnQgX19pbmRleCwgCiAJCSAgICAgX0NhbGxiYWNrX2xpc3QqIF9f
Y2IpCiAgICAgICA6IF9NX25leHQoX19jYiksIF9NX2ZuKF9fZm4pLCBfTV9pbmRleChfX2luZGV4
KSwgX01fcmVmY291bnQoMCkgeyB9CiAgICAgICAKICAgICAgIHZvaWQgCi0gICAgICBfTV9hZGRf
cmVmZXJlbmNlKCkgeyArK19NX3JlZmNvdW50OyB9IC8vIFhYWCBNVAorICAgICAgX01fYWRkX3Jl
ZmVyZW5jZSgpIHsgX19hdG9taWNfYWRkKCZfTV9yZWZjb3VudCwgMSk7IH0gLy8gWFhYIE1UCiAg
ICAgICAKICAgICAgIGludCAKLSAgICAgIF9NX3JlbW92ZV9yZWZlcmVuY2UoKSB7IHJldHVybiBf
TV9yZWZjb3VudC0tOyB9ICAvLyAwID0+IE9LIHRvIGRlbGV0ZQorICAgICAgX01fcmVtb3ZlX3Jl
ZmVyZW5jZSgpIHsgcmV0dXJuIF9fZXhjaGFuZ2VfYW5kX2FkZCgmX01fcmVmY291bnQsIC0xKTsg
fSAgLy8gMCA9PiBPSyB0byBkZWxldGUKICAgICB9OwogCiAgICAgIF9DYWxsYmFja19saXN0KiAg
CV9NX2NhbGxiYWNrczsKSW5kZXg6IGluY2x1ZGUvYml0cy9sb2NhbGVmd2QuaAo9PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
ClJDUyBmaWxlOiAvY3ZzL2djYy9nY2MvbGlic3RkYysrLXYzL2luY2x1ZGUvYml0cy9sb2NhbGVm
d2QuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMS4yLjMKZGlmZiAtdSAtcjEuMTEuMi4zIGxv
Y2FsZWZ3ZC5oCi0tLSBsb2NhbGVmd2QuaAkyMDAxLzA1LzE0IDE5OjQ5OjAzCTEuMTEuMi4zCisr
KyBsb2NhbGVmd2QuaAkyMDAyLzAxLzE3IDEyOjUzOjM4CkBAIC00Myw2ICs0Myw4IEBACiAjaW5j
bHVkZSA8Yml0cy9zdGRfY2N0eXBlLmg+CS8vIEZvciBpc3NwYWNlLCBldGMuCiAjaW5jbHVkZSA8
Yml0cy9mdW5jdGV4Y2VwdC5oPgogCisjaW5jbHVkZSA8Yml0cy9hdG9taWNpdHkuaD4KKwogbmFt
ZXNwYWNlIHN0ZAogewogICAvLyBOQjogRG9uJ3QgaW5zdGFudGlhdGUgcmVxdWlyZWQgd2NoYXJf
dCBmYWNldHMgaWYgbm8gd2NoYXJfdCBzdXBwb3J0LgpAQCAtMzA3LDcgKzMwOSw3IEBACiAKICAg
cHJpdmF0ZToKICAgICAvLyBEYXRhIE1lbWJlcnMuCi0gICAgc2l6ZV90IAkJCQlfTV9yZWZlcmVu
Y2VzOworICAgIF9BdG9taWNfd29yZAkJCV9NX3JlZmVyZW5jZXM7CiAgICAgX192ZWNfZmFjZXQq
IAkJCV9NX2ZhY2V0czsKICAgICBzdHJpbmcgCQkJCV9NX25hbWVzW19TX251bV9jYXRlZ29yaWVz
XTsKICAgICBfX2NfbG9jYWxlCQkJCV9NX2NfbG9jYWxlOwpAQCAtMzIxLDEyICszMjMsMTIgQEAK
IAogICAgIGlubGluZSB2b2lkIAogICAgIF9NX2FkZF9yZWZlcmVuY2UoKSB0aHJvdygpCi0gICAg
eyArK19NX3JlZmVyZW5jZXM7IH0gIC8vIFhYWCBNVAorICAgIHsgX19hdG9taWNfYWRkKCZfTV9y
ZWZlcmVuY2VzLCAxKTsgfSAgLy8gWFhYIE1UCiAKICAgICBpbmxpbmUgdm9pZCAKICAgICBfTV9y
ZW1vdmVfcmVmZXJlbmNlKCkgdGhyb3coKQogICAgIHsKLSAgICAgIGlmIChfTV9yZWZlcmVuY2Vz
LS0gPT0gMCkgIC8vIFhYWCBNVAorICAgICAgaWYgKF9fZXhjaGFuZ2VfYW5kX2FkZCgmX01fcmVm
ZXJlbmNlcywgLTEpID09IDApICAvLyBYWFggTVQKIAl7CiAJICB0cnkgCiAJICAgIHsgZGVsZXRl
IHRoaXM7IH0gCkBAIC0zOTQsNyArMzk2LDcgQEAKICAgICBfU19kZXN0cm95X2NfbG9jYWxlKF9f
Y19sb2NhbGUmIF9fY2xvYyk7CiAKICAgcHJpdmF0ZToKLSAgICBzaXplX3QgX01fcmVmZXJlbmNl
czsKKyAgICBfQXRvbWljX3dvcmQgX01fcmVmZXJlbmNlczsKIAogICAgIHZvaWQgCiAgICAgX01f
YWRkX3JlZmVyZW5jZSgpIHRocm93KCk7CkBAIC00MjgsNyArNDMwLDcgQEAKICAgICBtdXRhYmxl
IHNpemVfdCAJX01faW5kZXg7CiAKICAgICAvLyBMYXN0IGlkIG51bWJlciBhc3NpZ25lZAotICAg
IHN0YXRpYyBzaXplX3QgCV9TX2hpZ2h3YXRlcjsgICAKKyAgICBzdGF0aWMgX0F0b21pY193b3Jk
IAlfU19oaWdod2F0ZXI7ICAgCiAKICAgICB2b2lkIAogICAgIG9wZXJhdG9yPShjb25zdCBpZCYp
OyAgLy8gbm90IGRlZmluZWQKSW5kZXg6IHNyYy9pb3MuY2MKPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog
L2N2cy9nY2MvZ2NjL2xpYnN0ZGMrKy12My9zcmMvaW9zLmNjLHYKcmV0cmlldmluZyByZXZpc2lv
biAxLjE0LjQuMgpkaWZmIC11IC1yMS4xNC40LjIgaW9zLmNjCi0tLSBpb3MuY2MJMjAwMS8wNi8w
NiAwMTozOTowMQkxLjE0LjQuMgorKysgaW9zLmNjCTIwMDIvMDEvMTcgMTI6NTM6MzgKQEAgLTM2
LDYgKzM2LDggQEAKICNpbmNsdWRlIDxiaXRzL3N0ZF9pc3RyZWFtLmg+CiAjaW5jbHVkZSA8Yml0
cy9zdGRfZnN0cmVhbS5oPgogCisjaW5jbHVkZSA8Yml0cy9hdG9taWNpdHkuaD4KKwogbmFtZXNw
YWNlIHN0ZCAKIHsKICAgLy8gRXh0ZXJuIGRlY2xhcmF0aW9ucyBmb3IgZ2xvYmFsIG9iamVjdHMg
aW4gc3JjL2dsb2JhbHMuY2MuCkBAIC0yMTYsOCArMjE4LDggQEAKICAgewogICAgIC8vIFhYWCBN
VAogICAgIC8vIFhYWCBzaG91bGQgYmUgYSBzeW1ib2wuIChSZXNlcnZlIDAuLjMgZm9yIGJ1aWx0
aW5zLikKLSAgICBzdGF0aWMgaW50IHRvcCA9IDQ7IAotICAgIHJldHVybiB0b3ArKzsKKyAgICBz
dGF0aWMgX0F0b21pY193b3JkIHRvcCA9IDQ7IAorICAgIHJldHVybiBfX2V4Y2hhbmdlX2FuZF9h
ZGQoJnRvcCwgMSk7CiAgIH0KIAogICAvLyAyNy40LjIuNSAgaXdvcmQvcHdvcmQgc3RvcmFnZQpJ
bmRleDogc3JjL2xvY2FsZS5jYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3ZzL2djYy9nY2MvbGli
c3RkYysrLXYzL3NyYy9sb2NhbGUuY2MsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjguMi41CmRp
ZmYgLXUgLXIxLjI4LjIuNSBsb2NhbGUuY2MKLS0tIGxvY2FsZS5jYwkyMDAxLzEyLzExIDA4OjAx
OjI0CTEuMjguMi41CisrKyBsb2NhbGUuY2MJMjAwMi8wMS8xNyAxMjo1MzozOQpAQCAtNDEsNiAr
NDEsOCBAQAogIyBpbmNsdWRlIDxiaXRzL3N0ZF9jd2N0eXBlLmg+ICAgICAvLyBmb3IgdG93dXBw
ZXIsIGV0Yy4KICNlbmRpZgogCisjaW5jbHVkZSA8Yml0cy9hdG9taWNpdHkuaD4KKwogbmFtZXNw
YWNlIHN0ZCAKIHsKICAgLy8gRGVmaW5pdGlvbnMgZm9yIHN0YXRpYyBjb25zdCBkYXRhIG1lbWJl
cnMgb2YgbG9jYWxlLgpAQCAtNjgsNyArNzAsNyBAQAogI2VuZGlmCiAKICAgLy8gRGVmaW5pdGlv
bnMgZm9yIHN0YXRpYyBjb25zdCBkYXRhIG1lbWJlcnMgb2YgbG9jYWxlOjppZAotICBzaXplX3Qg
bG9jYWxlOjppZDo6X1NfaGlnaHdhdGVyOyAgLy8gaW5pdCdkIHRvIDAgYnkgbGlua2VyCisgIF9B
dG9taWNfd29yZCBsb2NhbGU6OmlkOjpfU19oaWdod2F0ZXI7ICAvLyBpbml0J2QgdG8gMCBieSBs
aW5rZXIKIAogICAvLyBEZWZpbml0aW9ucyBmb3Igc3RhdGljIGNvbnN0IGRhdGEgbWVtYmVycyBv
ZiBsb2NhbGU6Ol9JbXBsCiAgIGNvbnN0IGxvY2FsZTo6aWQqIGNvbnN0CkBAIC00NDUsNiArNDQ3
LDkgQEAKICAgbG9jYWxlOjpjbGFzc2ljKCkKICAgewogICAgIHN0YXRpYyBsb2NhbGUqIF9fY2xh
c3NpY19sb2NhbGU7CisgICAgc3RhdGljIF9TVExfbXV0ZXhfbG9jayBfX2xvY2sgX19TVExfTVVU
RVhfSU5JVElBTElaRVI7CisgICAgX1NUTF9hdXRvX2xvY2sgX19hdXRvKF9fbG9jayk7CisKICAg
ICAvLyBYWFggTVQKICAgICBpZiAoIV9TX2NsYXNzaWMpCiAgICAgICB7CkBAIC01MjMsMTUgKzUy
OCwxMyBAQAogICB2b2lkICAKICAgbG9jYWxlOjpmYWNldDo6CiAgIF9NX2FkZF9yZWZlcmVuY2Uo
KSB0aHJvdygpCi0gIHsgKytfTV9yZWZlcmVuY2VzOyB9ICAgICAgICAgICAgICAgICAgICAgLy8g
WFhYIE1UCisgIHsgX19hdG9taWNfYWRkKCZfTV9yZWZlcmVuY2VzLCAxKTsgfSAgICAgICAgICAg
ICAgICAgICAgIC8vIFhYWCBNVAogCiAgIHZvaWQgIAogICBsb2NhbGU6OmZhY2V0OjoKICAgX01f
cmVtb3ZlX3JlZmVyZW5jZSgpIHRocm93KCkKICAgewotICAgIGlmIChfTV9yZWZlcmVuY2VzKQot
ICAgICAgLS1fTV9yZWZlcmVuY2VzOwotICAgIGVsc2UKKyAgICBpZiAoX19leGNoYW5nZV9hbmRf
YWRkKCZfTV9yZWZlcmVuY2VzLCAtMSkgPT0gMCkKICAgICAgIHsKICAgICAgICAgdHJ5IAogCSAg
eyBkZWxldGUgdGhpczsgfSAgLy8gWFhYIE1UCkluZGV4OiBzcmMvbG9jYWxlbmFtZS5jYwo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09ClJDUyBmaWxlOiAvY3ZzL2djYy9nY2MvbGlic3RkYysrLXYzL3NyYy9sb2NhbGVuYW1l
LmNjLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEyLjIuMgpkaWZmIC11IC1yMS4xMi4yLjIgbG9j
YWxlbmFtZS5jYwotLS0gbG9jYWxlbmFtZS5jYwkyMDAxLzA1LzE0IDE5OjQ5OjE1CTEuMTIuMi4y
CisrKyBsb2NhbGVuYW1lLmNjCTIwMDIvMDEvMTcgMTI6NTM6MzkKQEAgLTE3Myw3ICsxNzMsNyBA
QAogICAgICAgewogCXNpemVfdCYgX19pbmRleCA9IF9faWRwLT5fTV9pbmRleDsKIAlpZiAoIV9f
aW5kZXgpCi0JICBfX2luZGV4ID0gKytsb2NhbGU6OmlkOjpfU19oaWdod2F0ZXI7ICAvLyBYWFgg
TVQKKwkgIF9faW5kZXggPSAxICsgX19leGNoYW5nZV9hbmRfYWRkKCZsb2NhbGU6OmlkOjpfU19o
aWdod2F0ZXIsIDEpOyAgLy8gWFhYIE1UCiAJCiAJaWYgKF9faW5kZXggPj0gX01fZmFjZXRzLT5z
aXplKCkpCiAJICBfTV9mYWNldHMtPnJlc2l6ZShfX2luZGV4ICsgMSwgMCk7ICAvLyBtaWdodCB0
aHJvdwo=


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

* Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
@ 2002-02-18 15:46 Andrew Pollard
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew Pollard @ 2002-02-18 15:46 UTC (permalink / raw)
  To: ljrittle; +Cc: gcc-prs

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

From: Andrew Pollard <andrewp@andypo.net>
To: rodrigc@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc: andrew@andypo.net, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   ljrittle@gcc.gnu.org
Subject: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
Date: Mon, 18 Feb 2002 23:34:46 GMT

 >Synopsis: Implementation still not thread-safe on multiprocessor machines
 >
 >State-Changed-From-To: feedback->closed
 >State-Changed-By: rodrigc
 >State-Changed-When: Sun Feb 17 18:54:57 2002
 >State-Changed-Why:
 >    Fixed in recent gcc 3.1 snapshots.
 >
 >http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5432
 
 Cheers. I have verified that the 3.1 source "works as expected".
 
 Shame it couldn't make it into gcc-3.0.4, I'll just have to patch locally
 once gcc-3.0.4 is out...
 
 Andrew.
 --
  Andrew Pollard, ASI/Brooks Automation  | home: andrew@andypo.net
 670 Eskdale Road, Winnersh Triangle, UK | work: Andrew.Pollard@brooks.com
  Tel/Fax:+44 (0)118 9215603 / 9215660   | http://www.andypo.net


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

* Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
@ 2002-02-17 18:54 rodrigc
  0 siblings, 0 replies; 5+ messages in thread
From: rodrigc @ 2002-02-17 18:54 UTC (permalink / raw)
  To: andrew, gcc-bugs, gcc-prs, ljrittle, rodrigc

Synopsis: Implementation still not thread-safe on multiprocessor machines

State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Sun Feb 17 18:54:57 2002
State-Changed-Why:
    Fixed in recent gcc 3.1 snapshots.

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


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

* Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
@ 2002-01-24 13:26 ljrittle
  0 siblings, 0 replies; 5+ messages in thread
From: ljrittle @ 2002-01-24 13:26 UTC (permalink / raw)
  To: andrew, gcc-bugs, gcc-prs, ljrittle, rodrigc

Synopsis: Implementation still not thread-safe on multiprocessor machines

State-Changed-From-To: analyzed->feedback
State-Changed-By: ljrittle
State-Changed-When: Thu Jan 24 13:25:59 2002
State-Changed-Why:
    Andrew, there were two minor issues with your patch:
    (And it took collective thought to figure all this out
    so don't feel bad. ;-)
    
    In general, static _Atomic_word should always be init'd
    to 0 with C++.  We think g++ follows the init order
    rules of C which are tighter than C++ but for C++
    non-zero static values may not be init'd until after main()
    has run (the only rule says it must be done "before
    the related block [scope] is entered" which might be after
    threads were started).
    
    Secondly:
    
    <       if (--_M_references == 0)  // XXX MT
    ---
    >       if (__exchange_and_add(&_M_references, -1) == 1)
    
    is correct (you had == 0).  I.e. assuming it was correct
    as written (other than thread-safety) your rewrite had a
    memory leak.
    
    Other than that, Nathan and I have reviewed the patch;
    I have tested it and installed it (that report to
    the libstdc++ mailing list).  To be closed after you
    confirm MP *-*-linux* system fixed as installed and
    then I move it to 3.0.X branch.  Thanks, Loren

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


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

* Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
@ 2002-01-23 23:49 ljrittle
  0 siblings, 0 replies; 5+ messages in thread
From: ljrittle @ 2002-01-23 23:49 UTC (permalink / raw)
  To: andrew, gcc-bugs, gcc-prs, ljrittle, nobody, rodrigc

Synopsis: Implementation still not thread-safe on multiprocessor machines

Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-By: ljrittle
Responsible-Changed-When: Wed Jan 23 23:49:43 2002
Responsible-Changed-Why:
    Taking at Ben's request.
State-Changed-From-To: open->analyzed
State-Changed-By: ljrittle
State-Changed-When: Wed Jan 23 23:49:43 2002
State-Changed-Why:
    Wacking patch into final shape (addressing issue of only
    zero PODs being guaranteed to be initiallized before
    main() starts).

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


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

end of thread, other threads:[~2002-02-18 23:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-19  7:26 libstdc++/5432: Implementation still not thread-safe on multiprocessor machines andrew
2002-01-23 23:49 ljrittle
2002-01-24 13:26 ljrittle
2002-02-17 18:54 rodrigc
2002-02-18 15:46 Andrew Pollard

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).