[Bug libstdc++/52967] New: Segmentation fault on std::vector destruction

[Bug libstdc++/52967] New: Segmentation fault on std::vector destruction

[karlicoss at gmail dot com]

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

             Bug #: 52967
           Summary: Segmentation fault on std::vector destruction
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: karlicoss@gmail.com


GCC version:
4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 

Environment:
Ubuntu 11.10 amd64

I've also reproduced it at:
Ubuntu 11.10 amd64, gcc version 4.4.6
Windows 7 x64, mingw version 4.6.2. 
Gentoo x86, gcc-4.5.3-r2
Arch Linux x64, gcc version 4.7.0 


How to repeat:
main.cpp:
#include <vector>

struct Foo
{
    double a, b, c, d;
};

std::vector<Foo> v;
int steps = 3;

double run()
{
    if (steps == 0)
        return 1.0;

    steps--;
    v.push_back(Foo());

    v[0].a = run();

    //double tmp = run();
    //nodes[0].a = tmp;

    return 1.0;
}

int main()
{
    run();
    return 0;
}


$ g++ main.cpp -o main && ./main
results in segmentation fault. The backtrace shows the problem is in vector
destructor.


This one is very weird, for example:
1)
replacing 
nodes[0].a = run()
with
double tmp = run();
nodes[0].a = tmp;
does not give segfault anymore.

2)
Reducing the Foo structure size (for example, using only three doubles instead
of four or using two doubles and two ints) does not give segfault.

3)
Decreasing the steps variable does not result in segfault.

4)
Returning 0.0 in the run function does not result in segfault (any non-zero
value still does).

5)
Setting the initial size for v sometimes results in segfault, sometime does.

[Bug c++/52967] Segmentation fault on std::vector destruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c++

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-13 00:15:05 UTC ---
I don't know if this is not undefined code.
>    v[0].a = run();

Is this:
double &a = v[0].a;
a = run();
Or:
double tmp = run();
v[0].a = tmp;

I think both are correct because of the way the C++ standard defines =.

[Bug c++/52967] Segmentation fault on std::vector destruction

[karlicoss at gmail dot com]

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

--- Comment #2 from Dmitry Gerasimov <karlicoss at gmail dot com> 2012-04-13 08:26:08 UTC ---
(In reply to comment #1)
> I don't know if this is not undefined code.
> >    v[0].a = run();
> 
> Is this:
> double &a = v[0].a;
> a = run();
> Or:
> double tmp = run();
> v[0].a = tmp;
> 
> I think both are correct because of the way the C++ standard defines =.

Hm,
> double &a = v[0].a;
> a = run();
does result in segfault. Should it?

[Bug c++/52967] Segmentation fault on std::vector destruction

[karlicoss at gmail dot com]

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

--- Comment #3 from Dmitry Gerasimov <karlicoss at gmail dot com> 2012-04-13 08:44:10 UTC ---
(In reply to comment #1)
> I don't know if this is not undefined code.
> >    v[0].a = run();
> 
> Is this:
> double &a = v[0].a;
> a = run();
> Or:
> double tmp = run();
> v[0].a = tmp;
> 
> I think both are correct because of the way the C++ standard defines =.

Ok, I got this.
If v[0].a = run(); is equivalent to double &a = v[0].a; a = run();, we:
1. calculate the address of a;
2. recurse into run
3. push_back, causing vector to increase its capacity and reallocate its
memory, which makes a to point to free memory.
I guess I should mark bug as Invalid?

[Bug c++/52967] Segmentation fault on std::vector destruction

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-13 09:52:03 UTC ---
Yes, this is invalid.  If you want to do this then you need to call reserve on
the vector so that push_back doesn't cause reallocation (or decide if the code
shouldn't just be rewritten differently!)