[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- For the record, I believe this was fixed by https://gcc.gnu.org/r67912
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261 Bug 32261 depends on bug 33394, which changed state. Bug 33394 Summary: Add test case for Thread race segfault in std::string::append with -O and -s https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33394 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #12 from appfault at hotmail dot com 2007-09-24 17:48 --- Due to lack of responsiveness, a separate Bug 33394 was opened for the missing test case. Verified this is generically in concept a duplicate of bug 21334, although the technical details are in fact not the same. -- appfault at hotmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #11 from appfault at hotmail dot com 2007-07-09 23:21 --- I've been unable to reproduce any issues in 3.4.6, even with tests that do not rely on the empty string. I suspect there is something more specific that was fixed somewhere between 3.3.x and 3.4.6. It doesn't seem appropriate to have marked this as a dupe of bug 21334, since bug 21334 has had no code changes made, but clearly a code change was made at some point to fix the comment 0 report. I recommend the comment 0 test be added to the gcc regression test suite, after which this zilla could be reclassified as 'fixed'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #9 from appfault at hotmail dot com 2007-06-25 23:41 --- So does this being marked dupe of bug 21334 mean that as long as string (not ext/vstring.h) is in use, that std::string is subject to other possible race conditions, even if the original test case succeeds in gcc 3.4.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #10 from pcarlini at suse dot de 2007-06-25 23:50 --- Probably, the answer is yes. In this area, when writing portable code, always remember that C++03 says *nothing* about threads, and concurrent programming, and so on. Different implementations, historically, made different choices, different routes and trade-offs. That means that in general, if you cannot optimize for the implementation defined details of a specific implementation, you end-up locking a lot, for safety. That's unfortunate, I agree. The next C++ standard (and ext/vstring.h ;) will be better, certainly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #8 from pcarlini at suse dot de 2007-06-14 08:15 --- Note, however, that startiing with 3.4.x (vs 3.3.x) the empty string representation is not not reference counted anymore. First blush, the *specific* code snippet in this PR should be safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-14 01:27 --- *** This bug has been marked as a duplicate of 21334 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #6 from jlawson-gcc at bovine dot net 2007-06-14 02:42 --- bug 21334 seems to deal with multiple threads accessing the same shared object at the same time. However, the sample code provided here involves separate private objects so there should not be any such issues. If it is not possible to assume that separate threads can access unrelated STL objects at the same time, then this would imply that all STL operations (regardless of the object) must be serialized! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
Re: [Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
bug 21334 seems to deal with multiple threads accessing the same shared object at the same time. However, the sample code provided here involves separate private objects so there should not be any such issues. If it is not possible to assume that separate threads can access unrelated STL objects at the same time, then this would imply that all STL operations (regardless of the object) must be serialized! The empty string is the same object really. -- Pinski
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #7 from pinskia at gmail dot com 2007-06-14 02:56 --- Subject: Re: Thread race segfault in std::string::append with -O and -s bug 21334 seems to deal with multiple threads accessing the same shared object at the same time. However, the sample code provided here involves separate private objects so there should not be any such issues. If it is not possible to assume that separate threads can access unrelated STL objects at the same time, then this would imply that all STL operations (regardless of the object) must be serialized! The empty string is the same object really. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
