Double free exception with Vector

Discussion in 'C++' started by jois.de.vivre@gmail.com, Sep 14, 2005.

  1. Guest

    I am having some difficulty with the STL vector class throwing a double
    free exception. The problem is that I don't use pointers anywhere in
    my program. The double free currently occurs when I call push_back().
    The stack trace shows that the double free stems from the following
    lines in vector.tcc (from gcc):

    ....
    ....
    _M_deallocate(this->_M_impl._M_start,
    this->_M_impl._M_end_of_storage
    - this->_M_impl._M_start);
    ....
    ....

    This line is in the function:

    template<typename _Tp, typename _Alloc>
    vector<_Tp, _Alloc>&
    vector<_Tp, _Alloc>::
    operator=(const vector<_Tp, _Alloc>& __x);

    This happens when I try and use push_back() on a private variable from
    within the class. If I try it on a local variable everything operates
    as expected. I tried to trace the problem down to see what exactly the
    variable "_M_impl" is, but I couldn't find it. Also, the coding
    convention used is a bit unintuitive and I couldn't figure out from the
    code what exactly the purpose of this line was. I suppose it is
    deallocating something from start to end, and my problem is that this
    has been deallocated as some time in the past already. I would post my
    code, but it's part of a larger application and not very simple. I
    tried to contrive an example, but I couldn't reproduce the problem.
    Any ideas?
    , Sep 14, 2005
    #1
    1. Advertising

  2. Kai-Uwe Bux Guest

    wrote:

    > I am having some difficulty with the STL vector class throwing a double
    > free exception. The problem is that I don't use pointers anywhere in
    > my program. The double free currently occurs when I call push_back().
    > The stack trace shows that the double free stems from the following
    > lines in vector.tcc (from gcc):
    >
    > ...
    > ...
    > _M_deallocate(this->_M_impl._M_start,
    > this->_M_impl._M_end_of_storage
    > - this->_M_impl._M_start);
    > ...
    > ...
    >
    > This line is in the function:
    >
    > template<typename _Tp, typename _Alloc>
    > vector<_Tp, _Alloc>&
    > vector<_Tp, _Alloc>::
    > operator=(const vector<_Tp, _Alloc>& __x);
    >
    > This happens when I try and use push_back() on a private variable from
    > within the class. If I try it on a local variable everything operates
    > as expected. I tried to trace the problem down to see what exactly the
    > variable "_M_impl" is, but I couldn't find it. Also, the coding
    > convention used is a bit unintuitive and I couldn't figure out from the
    > code what exactly the purpose of this line was. I suppose it is
    > deallocating something from start to end, and my problem is that this
    > has been deallocated as some time in the past already. I would post my
    > code, but it's part of a larger application and not very simple. I
    > tried to contrive an example, but I couldn't reproduce the problem.
    > Any ideas?


    a) It does not help to post the same item several times all over the place.

    b) analysing carefully the two lines of the code you posted, I bet you that
    the bug is someplace else.
    c) For more helpful replies you need to provide more information.
    Particularly welcome would be a piece of code that would allow one to
    reproduce the error.


    Best

    Kai-Uwe Bux

    PS.: Here is a wild guess about your bug. Maybe you invoke undefined
    behavior by referencing an invalid object (something you deleted already).
    If that dead object has a vector-subobject and wants to operate on that
    vector, anything can happen since the memory is now filled with completely
    different data. In such a case, the bug could manifest itself while
    executing code from the library.

    PPS.: The bug is almost never within the STL implementation.
    Kai-Uwe Bux, Sep 14, 2005
    #2
    1. Advertising

  3. Guest

    Kai-Uwe Bux wrote:
    > wrote:
    >
    > > I am having some difficulty with the STL vector class throwing a double
    > > free exception. The problem is that I don't use pointers anywhere in
    > > my program. The double free currently occurs when I call push_back().
    > > The stack trace shows that the double free stems from the following
    > > lines in vector.tcc (from gcc):
    > >
    > > ...
    > > ...
    > > _M_deallocate(this->_M_impl._M_start,
    > > this->_M_impl._M_end_of_storage
    > > - this->_M_impl._M_start);
    > > ...
    > > ...
    > >
    > > This line is in the function:
    > >
    > > template<typename _Tp, typename _Alloc>
    > > vector<_Tp, _Alloc>&
    > > vector<_Tp, _Alloc>::
    > > operator=(const vector<_Tp, _Alloc>& __x);
    > >
    > > This happens when I try and use push_back() on a private variable from
    > > within the class. If I try it on a local variable everything operates
    > > as expected. I tried to trace the problem down to see what exactly the
    > > variable "_M_impl" is, but I couldn't find it. Also, the coding
    > > convention used is a bit unintuitive and I couldn't figure out from the
    > > code what exactly the purpose of this line was. I suppose it is
    > > deallocating something from start to end, and my problem is that this
    > > has been deallocated as some time in the past already. I would post my
    > > code, but it's part of a larger application and not very simple. I
    > > tried to contrive an example, but I couldn't reproduce the problem.
    > > Any ideas?

    >
    > a) It does not help to post the same item several times all over the place.
    >
    > b) analysing carefully the two lines of the code you posted, I bet you that
    > the bug is someplace else.
    > c) For more helpful replies you need to provide more information.
    > Particularly welcome would be a piece of code that would allow one to
    > reproduce the error.
    >
    >
    > Best
    >
    > Kai-Uwe Bux
    >
    > PS.: Here is a wild guess about your bug. Maybe you invoke undefined
    > behavior by referencing an invalid object (something you deleted already).
    > If that dead object has a vector-subobject and wants to operate on that
    > vector, anything can happen since the memory is now filled with completely
    > different data. In such a case, the bug could manifest itself while
    > executing code from the library.
    >
    > PPS.: The bug is almost never within the STL implementation.


    > a) It does not help to post the same item several times all over the place.


    Sorry, Google kept saying the server was busy and to try again in 30
    seconds, it seems as though every time I tried it posted a new copy,
    but told me it failed.

    > b) analysing carefully the two lines of the code you posted, I bet you that
    > the bug is someplace else.


    I think so too, I think it has to do with a reference pointing to a
    local variable. It's odd though that it would get as far as the STL
    code though.

    > c) For more helpful replies you need to provide more information.
    > Particularly welcome would be a piece of code that would allow one to
    > reproduce the error.


    I was trying to reproduce the problem, but couldn't figure out a simple
    example that would reproduce it. The code itself that produces the
    problem is huge and interacts with certain hardware, so I can't really
    post it. I thought that someone might have run into a similar problem
    and might know off-hand what this would be caused by.

    Thanks Anyway!
    , Sep 15, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sydex
    Replies:
    12
    Views:
    6,425
    Victor Bazarov
    Feb 17, 2005
  2. Ingo Nolden
    Replies:
    15
    Views:
    1,503
    Jerry Coffin
    Apr 30, 2005
  3. Replies:
    2
    Views:
    272
    John Harrison
    Sep 15, 2005
  4. Replies:
    0
    Views:
    465
  5. Replies:
    8
    Views:
    1,873
    Csaba
    Feb 18, 2006
Loading...

Share This Page