[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #25 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[timturnerc at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

Tim Turner <timturnerc at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timturnerc at yahoo dot com

--- Comment #26 from Tim Turner <timturnerc at yahoo dot com> ---
If you create a new TUI layout, don't include the status window, and then
change from a layout with the status window to the new one, gdb crashes.
http://www.compilatori.com/category/tech/

(gdb) layout src
(gdb) tui new-layout test src 2 cmd 1
http://www.acpirateradio.co.uk/category/tech/
(gdb) layout test
http://www.logoarts.co.uk/category/tech/
On Windows I get a STATUS_HEAP_CORRUPTION exception (0xc0000374).
http://www.mconstantine.co.uk/property/netherlands/
It happens because tui_apply_current_layout() deletes all windows that are no
longer  http://www.go-mk-websites.co.uk/property/miyazaki/ needed, but the
status (locator) window is never allocated dynamically. 
http://www.slipstone.co.uk/category/tech/
If you create a new TUI layout, don't include the status window, and then
http://fishingnewsletters.co.uk/health/adrasan/ change from a layout with the
status window to the new one, gdb crashes.
http://embermanchester.uk/category/tech/
(gdb) layout src
(gdb) tui new-layout test src 2 cmd 1 http://connstr.net/category/tech/
(gdb) layout test
 http://joerg.li/category/tech/
On Windows I get a STATUS_HEAP_CORRUPTION exception (0xc0000374).
It happens because tui_apply http://www.jopspeech.com/category/tech/
_current_layout() deletes all windows that are no longer needed,
http://the-hunters.org/services/miui-12-5/ but the status (locator) window is
never allocated dynamically.
http://www.wearelondonmade.com/category/tech/
If you create a new TUI layout, don't include the status window, and then
change from a layout with the status window to the new one, gdb crashes.
https://waytowhatsnext.com/category/property/

(gdb) layout src
(gdb) tui new-layout test src 2 cmd 1
http://www.iu-bloomington.com/category/property/
(gdb) layout test
https://komiya-dental.com/category/property/
On Windows I get a STATUS_HEAP_CORRUPTION exception (0xc0000374).
It happens because tui
http://www-look-4.com/category/tech/_apply_current_layout() deletes all windows
that are no longer needed, but the status (locator) window is never allocated
dynamically. https://www.webb-dev.co.uk/category/property/

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[redi at gcc dot gnu dot org]

------- Comment #24 from redi at gcc dot gnu dot org  2010-04-10 13:48 -------
Fixed for 4.4.4


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.2.2 4.3.2 4.4.0 4.5.0     |4.2.2 4.3.2 4.4.3
   Target Milestone|4.5.0                       |4.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[redi at gcc dot gnu dot org]

------- Comment #23 from redi at gcc dot gnu dot org  2010-04-10 13:46 -------
Subject: Bug 40518

Author: redi
Date: Sat Apr 10 13:46:25 2010
New Revision: 158190

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158190
Log:
2010-04-10  Jonathan Wakely  <jwakely.gcc@gmail.com>

        Backport:
        2009-06-23  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40518
        * include/bits/basic_string.h (basic_string<>::_Rep::
        _M_set_length_and_sharable): Do not write the empty rep.
        (basic_string<>::erase(iterator, iterator)): Likewise,
        move out of line...
        * include/bits/basic_string.tcc: ... here.


Modified:
    branches/gcc-4_4-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_4-branch/libstdc++-v3/include/bits/basic_string.h
    branches/gcc-4_4-branch/libstdc++-v3/include/bits/basic_string.tcc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[redi at gcc dot gnu dot org]

------- Comment #22 from redi at gcc dot gnu dot org  2010-04-09 08:03 -------
I'm unable to bootstrap 4.4 for some reason, I'll try again tomorrow


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #21 from paolo dot carlini at oracle dot com  2010-04-08 14:04 -------
> I'll look into backporting it tonight on condition you cease the hyperbole
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^       

That's why (among other reasons) I voted in favor of appointing Jon maintainer
;) Agreed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[redi at gcc dot gnu dot org]

------- Comment #20 from redi at gcc dot gnu dot org  2010-04-08 13:51 -------
You can still reduce the helgrind output with just one suppression

{
  libstdcxx_std_string_race_pr40518
  Helgrind:Race
  fun:_ZNSs9_M_mutateEmmm
}

I'm not convinced the impact is "severe", COW strings already have problems in
multiprocessor systems, I don't think erase() on empty strings is the
bottleneck!   It's not been a problem in my own experience, and I'm not aware
of any distros having felt the need to backport the patch to their 4.4
packages.

I'll look into backporting it tonight on condition you cease the hyperbole


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #19 from paolo dot carlini at oracle dot com  2010-04-08 10:33 -------
Please keep in mind that nobody complained so far, over the last ~10 years, and
4.4 is close to its end of life.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[bart dot vanassche at gmail dot com]

------- Comment #18 from bart dot vanassche at gmail dot com  2010-04-08 10:28 -------
(In reply to comment #12)
> In my opinion it's too late now, I'm not even sure a 4.4.4 will be released any
> time soon, and 4.5.0 is around the corner. But if Jon would also like to see it
> in 4.4.4 and wants to backport the patch I do not object.

Please keep in mind that this behavior can have a severe negative impact on
multithreaded C++ software that uses class std::string intensively because the
unnecessary writes to _S_empty_rep_storage will cause unnecessary cache line
bouncing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #17 from paolo dot carlini at oracle dot com  2010-04-08 09:34 -------
.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #16 from paolo dot carlini at oracle dot com  2010-04-08 09:33 -------
unassign myself


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
                   |dot com                     |dot org
             Status|REOPENED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #15 from paolo dot carlini at oracle dot com  2010-04-08 09:33 -------
Re-open to..


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[bart dot vanassche at gmail dot com]

------- Comment #14 from bart dot vanassche at gmail dot com  2010-04-08 06:03 -------
(In reply to comment #13)
> I agree it's probably not worth backporting to a release branch, it wasn't a
> regression.
> 
> Haven't affected users written valgrind suppression files by now? :)

Since the races on _S_empty_rep_storage are triggered by an inline function
many different suppression patterns would have to be added in order to suppress
these races. And adding such suppression patterns would suppress several real
races.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[redi at gcc dot gnu dot org]

------- Comment #13 from redi at gcc dot gnu dot org  2010-04-07 19:06 -------
I agree it's probably not worth backporting to a release branch, it wasn't a
regression.

Haven't affected users written valgrind suppression files by now? :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2010-04-07 18:11 -------
In my opinion it's too late now, I'm not even sure a 4.4.4 will be released any
time soon, and 4.5.0 is around the corner. But if Jon would also like to see it
in 4.4.4 and wants to backport the patch I do not object.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[bart dot vanassche at gmail dot com]

------- Comment #11 from bart dot vanassche at gmail dot com  2010-04-07 17:54 -------
(In reply to comment #10)
> I think this is for mainline only. In a couple of few weeks a I will give it a
> second thought for 4_4-branch but certainly isn't a regression.

Any status update here ? Many Helgrind and DRD users would be grateful if this
could be backported to gcc 4.4.


-- 

bart dot vanassche at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bart dot vanassche at gmail
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2009-06-23 12:39 -------
I think this is for mainline only. In a couple of few weeks a I will give it a
second thought for 4_4-branch but certainly isn't a regression.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo at gcc dot gnu dot org]

------- Comment #9 from paolo at gcc dot gnu dot org  2009-06-23 12:36 -------
Subject: Bug 40518

Author: paolo
Date: Tue Jun 23 12:36:43 2009
New Revision: 148850

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148850
Log:
2009-06-23  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40518
        * include/bits/basic_string.h (basic_string<>::_Rep::
        _M_set_length_and_sharable): Do not write the empty rep.
        (basic_string<>::erase(iterator, iterator)): Likewise,
        move out of line...
        * include/bits/basic_string.tcc: ... here.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/basic_string.h
    trunk/libstdc++-v3/include/bits/basic_string.tcc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[jwakely dot gcc at gmail dot com]

------- Comment #8 from jwakely dot gcc at gmail dot com  2009-06-22 20:30 -------
the revised patch tests ok, no helgrind errors from

std::string s;
s.erase();
s.erase(s.begin(), s.end());


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-06-22 17:56 -------
Jon, that is ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2009-06-22 17:56 -------
Created an attachment (id=18048)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18048&action=view)
Updated


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2009-06-22 17:55 -------
Jo, I think we need an additional hunk, to deal with s.erase(s.begin(),
s.end()). I'm attaching an updated draft...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2009-06-22 12:01 -------
Great. In the meanwhile I did run the testsuite and everything is fine. Let's
wait a bit more, in case something trickier is noticed, and close the issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[jwakely dot gcc at gmail dot com]

------- Comment #3 from jwakely dot gcc at gmail dot com  2009-06-22 11:58 -------
That looks good.  I didn't run the v3 testsuite, but it fixes the helgrind
errors in the test cases


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2009-06-22 11:06 -------
Created an attachment (id=18046)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18046&action=view)
Draft


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-06-22 11:05 -------
Jon, thanks for clearly pointing out that warning: indeed, at that time I
noticed that in some cases we could overwrite the same values. Anyway, the very
simple attached draft seems then the way to go. Can you test it? Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-06-22 11:03:37
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518