Re: libstdc++/1853: <deque> deallocates unowned memory within .pop_back()

Re: libstdc++/1853: <deque> deallocates unowned memory within .pop_back()

[bkoz]

Synopsis: <deque> deallocates unowned memory within .pop_back()

State-Changed-From-To: open->analyzed
State-Changed-By: bkoz
State-Changed-When: Tue Jun 12 14:14:26 2001
State-Changed-Why:
    Still an issue with gcc as of 2001-06-12

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1853&database=gcc

Re: libstdc++/1853: <deque> deallocates unowned memory within .pop_back()

[pme]

Synopsis: <deque> deallocates unowned memory within .pop_back()

State-Changed-From-To: analyzed->closed
State-Changed-By: pme
State-Changed-When: Wed Jan  2 21:00:36 2002
State-Changed-Why:
    Like jdennett says, this is undefined behavior.  To be
    strictly portable and correct, users should check for
    !x.empty() before removing elements from a container x.
    
    By default we shouldn't do sanity checking, I believe.
    The overhead imposed could be significant when pop_back
    is being called in a loop (which is what a double-ended
    queue could easily be used for).  The same holds for other
    functions which behave badly when invoked in undefined
    situations.  The penalty would be imposed for users which
    are correctly checking for empty containers, and would
    then be redundant.
    
    For 3.2 I hope to add some kind of super-safe debugging
    mode to the library.  Speed and efficiency would go
    down the toilet, but we could catch cases like these.
    The guiding documentation for users would be:  if your
    code works with this mode on, and it breaks without it,
    then you're doing something undefined.

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

Re: libstdc++/1853: <deque> deallocates unowned memory within .pop_back()

[pme]

Synopsis: <deque> deallocates unowned memory within .pop_back()

Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: pme
Responsible-Changed-When: Fri Dec 28 15:51:10 2001
Responsible-Changed-Why:
    I changed it.  Still an issue as of today.  The internals of
    deque aren't documented very well at all.  I want to figure
    out what memory games are being played before changing the
    code; the obvious solution may be too slow.

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

libstdc++/1853: <deque> deallocates unowned memory within .pop_back()

[stevemw]

>Number:         1853
>Category:       libstdc++
>Synopsis:       <deque> deallocates unowned memory within .pop_back()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 03 09:26:04 PST 2001
>Closed-Date:    
>Last-Modified:  
>Originator:     Stephen M Wynne
>Release:        libstdc++-2.9.0-24
>Organization:
>Environment:
Intel RedHat 6.1
>Description:
Coredumps occur after doing a D.pop_back() on an
empty object (declared by deque<int> D;).

After quickly reading it, I can only surmize that
stl_deque.h's class deque's pop_back() mutator
properly doesn't check to see if the object is empty.
(I didn't fully understand pop_back_aux(), but it may
be pointless to go into that function if we're empty.)

Note: I did a search for pop on libstdc++ and didn't
see a report for this bug. I think it's a major one,
so I hope we can fix it soon. Thanks for the work!
>How-To-Repeat:
int main() {
    deque<int> v;
 
    v.pop_back();
    v.push_back(1);
    return 0;
}
>Fix:
Add a check inside push_back() 
(before it does anything else) as follows:

if (finish == start) return;
>Release-Note:
>Audit-Trail:

Formerly PR libstdc++/31

>Unformatted: