core dump in std::list push_back

Discussion in 'C++' started by Jaydeep Chovatia, Mar 24, 2011.

  1. Hi,

    I am getting core dump while using push_back of std::list. What could
    be the reason for this?
    std::list is of type: std::list<MyClient*>

    #0 0x0000003f9b063803 in
    std::_List_node_base::hook(std::_List_node_base*) () from /usr/lib64/
    libstdc++.so.6
    #1 0x00000000007ad596 in std::list<::MyClient*,
    std::allocator<::MyClient*> >::_M_insert (
    this=0x1e19780, __position=, __x=@0x7fdbbbdbdd38)
    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:1140
    #2 0x00000000007ad5c1 in std::list<::MyClient*,
    std::allocator<::MyClient*> >::push_back (
    this=0x1e19780, __x=@0x7fdbbbdbdd38)
    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:761
    #3 0x00000000007ac356 in ::MyClientObjPool::addNewObject
    (this=0x1e19678)
    at objpool/MyClientObjPool.cxx:254
    #4 0x00000000007ac744 in ::MyClientObjPool::checkUpdate
    (this=0x1e19678)
    at objpool/MyClientObjPool.cxx:175
    #5 0x00000000007ac82d in careTakerThreadMain (p=0x1e19678) at objpool/
    MyClientObjPool.cxx:28
    #6 0x0000003f978077e1 in start_thread () from /lib64/libpthread.so.0
    #7 0x0000003f974e153d in clone () from /lib64/libc.so.6

    Thank you,
    Jaydeep
    Jaydeep Chovatia, Mar 24, 2011
    #1
    1. Advertising

  2. On 3/24/2011 3:48 PM, Jaydeep Chovatia wrote:
    > I am getting core dump while using push_back of std::list. What could
    > be the reason for this?
    > std::list is of type: std::list<MyClient*>


    There is a logic error on line 42 of your program. At least that's what
    my crystal ball says.

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Mar 24, 2011
    #2
    1. Advertising

  3. On Mar 24, 12:53 pm, Victor Bazarov <> wrote:
    > On 3/24/2011 3:48 PM, Jaydeep Chovatia wrote:
    >
    > > I am getting core dump while using push_back of std::list. What could
    > > be the reason for this?
    > > std::list is of type: std::list<MyClient*>

    >
    > There is a logic error on line 42 of your program.  At least that's what
    > my crystal ball says.
    >
    > V
    > --
    > I do not respond to top-posted replies, please don't ask


    Hi Victor,

    Thanks for your response.
    Sorry, I didn't get what is the logic error in code. Can you please
    elaborate little bit more?

    Thank you,
    Jaydeep
    Jaydeep Chovatia, Mar 24, 2011
    #3
  4. On 3/24/2011 4:10 PM, Jaydeep Chovatia wrote:
    > On Mar 24, 12:53 pm, Victor Bazarov<> wrote:
    >> On 3/24/2011 3:48 PM, Jaydeep Chovatia wrote:
    >>
    >>> I am getting core dump while using push_back of std::list. What could
    >>> be the reason for this?
    >>> std::list is of type: std::list<MyClient*>

    >>
    >> There is a logic error on line 42 of your program. At least that's what
    >> my crystal ball says.
    >>
    >> V
    >> --
    >> I do not respond to top-posted replies, please don't ask

    >
    > Hi Victor,
    >
    > Thanks for your response.
    > Sorry, I didn't get what is the logic error in code. Can you please
    > elaborate little bit more?


    A logic error is not a syntax error. Most likely to manifest itself as
    a run-time malfunction. Sometimes it's relatively harmless (like
    outputting 'a' when 'b' should be output), sometimes it leads to crash
    (access to memory that doesn't belong to the process, for instance).

    My crystal ball is clouding up; I'm afraid I can't help you any further
    without additional information about your program. See FAQ 5.8.

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Mar 24, 2011
    #4
  5. On Mar 24, 1:10 pm, Jaydeep Chovatia <>
    wrote:
    > On Mar 24, 12:53 pm, Victor Bazarov <> wrote:
    >
    > > There is a logic error on line 42 of your program.  At least that's what
    > > my crystal ball says.

    >
    > Hi Victor,
    >
    > Thanks for your response.
    > Sorry, I didn't get what is the logic error in code. Can you please
    > elaborate little bit more?


    http://en.wikipedia.org/wiki/Phrase...fe.2C_the_Universe.2C_and_Everything_.2842.29

    It's a sarcastic reply. You should read the newsgroup FAQ about how to
    post questions.
    Joshua Maurice, Mar 24, 2011
    #5
  6. Jaydeep Chovatia

    Drew Lawson Guest

    In article <>
    Jaydeep Chovatia <> writes:
    >Hi,
    >
    >I am getting core dump while using push_back of std::list. What could
    >be the reason for this?
    >std::list is of type: std::list<MyClient*>


    Without the code, it will be pretty hard to even guess.

    However, I'll take a "frequently burned" guess. The last two frames
    in your stack trace are in std::allocator. In my experience, there
    are only two reasons for a production memory allocator to crash.

    One is that your program is using up all available memory. That's
    (in my experiece) the less common reason.

    The most common reason is that something, before the allocation was
    started, corrupted the memory that the allocator is using.

    Look at your pointer/new/delete usage. I'd bet that you use a
    pointer somewhere after you deleted the object that it pointed to.


    >#0 0x0000003f9b063803 in
    >std::_List_node_base::hook(std::_List_node_base*) () from /usr/lib64/
    >libstdc++.so.6
    >#1 0x00000000007ad596 in std::list<::MyClient*,
    >std::allocator<::MyClient*> >::_M_insert (
    > this=0x1e19780, __position=, __x=@0x7fdbbbdbdd38)
    > at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:1140
    >#2 0x00000000007ad5c1 in std::list<::MyClient*,
    >std::allocator<::MyClient*> >::push_back (
    > this=0x1e19780, __x=@0x7fdbbbdbdd38)
    > at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:761
    >#3 0x00000000007ac356 in ::MyClientObjPool::addNewObject
    >(this=0x1e19678)
    > at objpool/MyClientObjPool.cxx:254
    >#4 0x00000000007ac744 in ::MyClientObjPool::checkUpdate
    >(this=0x1e19678)
    > at objpool/MyClientObjPool.cxx:175
    >#5 0x00000000007ac82d in careTakerThreadMain (p=0x1e19678) at objpool/
    >MyClientObjPool.cxx:28
    >#6 0x0000003f978077e1 in start_thread () from /lib64/libpthread.so.0
    >#7 0x0000003f974e153d in clone () from /lib64/libc.so.6
    >
    >Thank you,
    >Jaydeep



    --
    Drew Lawson | Savage bed foot-warmer
    | of purest feline ancestry
    | Look out little furry folk
    | it's the all-night working cat
    Drew Lawson, Mar 24, 2011
    #6
  7. Jaydeep Chovatia

    Angus Guest

    On Mar 24, 8:24 pm, (Drew Lawson) wrote:
    > In article <..com>
    >         Jaydeep Chovatia <> writes:
    >
    > >Hi,

    >
    > >I am getting core dump while using push_back of std::list. What could
    > >be the reason for this?
    > >std::list is of type: std::list<MyClient*>

    >
    > Without the code, it will be pretty hard to even guess.
    >
    > However, I'll take a "frequently burned" guess.  The last two frames
    > in your stack trace are in std::allocator.  In my experience, there
    > are only two reasons for a production memory allocator to crash.
    >
    > One is that your program is using up all available memory.  That's
    > (in my experiece) the less common reason.
    >
    > The most common reason is that something, before the allocation was
    > started, corrupted the memory that the allocator is using.
    >
    > Look at your pointer/new/delete usage.  I'd bet that you use a
    > pointer somewhere after you deleted the object that it pointed to.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > >#0  0x0000003f9b063803 in
    > >std::_List_node_base::hook(std::_List_node_base*) () from /usr/lib64/
    > >libstdc++.so.6
    > >#1  0x00000000007ad596 in std::list<::MyClient*,
    > >std::allocator<::MyClient*> >::_M_insert (
    > >    this=0x1e19780, __position=, __x=@0x7fdbbbdbdd38)
    > >    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    > >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:1140
    > >#2  0x00000000007ad5c1 in std::list<::MyClient*,
    > >std::allocator<::MyClient*> >::push_back (
    > >    this=0x1e19780, __x=@0x7fdbbbdbdd38)
    > >    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    > >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:761
    > >#3  0x00000000007ac356 in ::MyClientObjPool::addNewObject
    > >(this=0x1e19678)
    > >    at objpool/MyClientObjPool.cxx:254
    > >#4  0x00000000007ac744 in ::MyClientObjPool::checkUpdate
    > >(this=0x1e19678)
    > >    at objpool/MyClientObjPool.cxx:175
    > >#5  0x00000000007ac82d in careTakerThreadMain (p=0x1e19678) at objpool/
    > >MyClientObjPool.cxx:28
    > >#6  0x0000003f978077e1 in start_thread () from /lib64/libpthread.so.0
    > >#7  0x0000003f974e153d in clone () from /lib64/libc.so.6

    >
    > >Thank you,
    > >Jaydeep

    >
    > --
    > Drew Lawson            |  Savage bed foot-warmer
    >                        |    of purest feline ancestry
    >                        |  Look out little furryfolk
    >                        |    it's the all-night working cat


    If the pointers in the list are new'd then you need to call delete on
    the object BEFORE erasing the object in the list. This is a common
    mistake. It is one of the not to do items in Effective C++.

    But without seeing other bits of your code this is pure speculation.
    Angus, Mar 24, 2011
    #7
  8. Jaydeep Chovatia

    Noah Roberts Guest

    On 3/24/2011 1:10 PM, Jaydeep Chovatia wrote:
    > On Mar 24, 12:53 pm, Victor Bazarov<> wrote:
    >> On 3/24/2011 3:48 PM, Jaydeep Chovatia wrote:
    >>
    >>> I am getting core dump while using push_back of std::list. What could
    >>> be the reason for this?
    >>> std::list is of type: std::list<MyClient*>

    >>
    >> There is a logic error on line 42 of your program. At least that's what
    >> my crystal ball says.
    >>
    >> V
    >> --
    >> I do not respond to top-posted replies, please don't ask

    >
    > Hi Victor,
    >
    > Thanks for your response.
    > Sorry, I didn't get what is the logic error in code. Can you please
    > elaborate little bit more?


    The operand you're supplying to the towel operator is a dead babelfish.
    This always results in undefined behavior, usually manifested as the
    absurd.


    --
    http://crazycpp.wordpress.com
    Noah Roberts, Mar 24, 2011
    #8
  9. On Mar 24, 1:34 pm, Angus <> wrote:
    > On Mar 24, 8:24 pm, (Drew Lawson) wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > In article <>
    > >         Jaydeep Chovatia <> writes:

    >
    > > >Hi,

    >
    > > >I am getting core dump while using push_back of std::list. What could
    > > >be the reason for this?
    > > >std::list is of type: std::list<MyClient*>

    >
    > > Without the code, it will be pretty hard to even guess.

    >
    > > However, I'll take a "frequently burned" guess.  The last two frames
    > > in your stack trace are in std::allocator.  In my experience, there
    > > are only two reasons for a production memory allocator to crash.

    >
    > > One is that your program is using up all available memory.  That's
    > > (in my experiece) the less common reason.

    >
    > > The most common reason is that something, before the allocation was
    > > started, corrupted the memory that the allocator is using.

    >
    > > Look at your pointer/new/delete usage.  I'd bet that you use a
    > > pointer somewhere after you deleted the object that it pointed to.

    >
    > > >#0  0x0000003f9b063803 in
    > > >std::_List_node_base::hook(std::_List_node_base*) () from /usr/lib64/
    > > >libstdc++.so.6
    > > >#1  0x00000000007ad596 in std::list<::MyClient*,
    > > >std::allocator<::MyClient*> >::_M_insert (
    > > >    this=0x1e19780, __position=, __x=@0x7fdbbbdbdd38)
    > > >    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    > > >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:1140
    > > >#2  0x00000000007ad5c1 in std::list<::MyClient*,
    > > >std::allocator<::MyClient*> >::push_back (
    > > >    this=0x1e19780, __x=@0x7fdbbbdbdd38)
    > > >    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    > > >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:761
    > > >#3  0x00000000007ac356 in ::MyClientObjPool::addNewObject
    > > >(this=0x1e19678)
    > > >    at objpool/MyClientObjPool.cxx:254
    > > >#4  0x00000000007ac744 in ::MyClientObjPool::checkUpdate
    > > >(this=0x1e19678)
    > > >    at objpool/MyClientObjPool.cxx:175
    > > >#5  0x00000000007ac82d in careTakerThreadMain (p=0x1e19678) at objpool/
    > > >MyClientObjPool.cxx:28
    > > >#6  0x0000003f978077e1 in start_thread () from /lib64/libpthread.so.0
    > > >#7  0x0000003f974e153d in clone () from /lib64/libc.so.6

    >
    > > >Thank you,
    > > >Jaydeep

    >
    > > --
    > > Drew Lawson            |  Savage bed foot-warmer
    > >                        |    of purest feline ancestry
    > >                        |  Look out little furry folk
    > >                        |    it's the all-night working cat

    >
    > If the pointers in the list are new'd then you need to call delete on
    > the object BEFORE erasing the object in the list.  This is a common
    > mistake.  It is one of the not to do items in Effective C++.
    >
    > But without seeing other bits of your code this is pure speculation.


    Hi Drew,

    I am calling delete on object after erasing from the list. Do you
    thing this might have triggered core dump?

    Thank you,
    Jaydeep
    Jaydeep Chovatia, Mar 25, 2011
    #9
  10. Jaydeep Chovatia

    Angus Guest

    On Mar 25, 2:09 am, Jaydeep Chovatia <>
    wrote:
    > On Mar 24, 1:34 pm, Angus <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Mar 24, 8:24 pm, (Drew Lawson) wrote:

    >
    > > > In article <>
    > > >         Jaydeep Chovatia <> writes:

    >
    > > > >Hi,

    >
    > > > >I am getting core dump while using push_back of std::list. What could
    > > > >be the reason for this?
    > > > >std::list is of type: std::list<MyClient*>

    >
    > > > Without the code, it will be pretty hard to even guess.

    >
    > > > However, I'll take a "frequently burned" guess.  The last two frames
    > > > in your stack trace are in std::allocator.  In my experience, there
    > > > are only two reasons for a production memory allocator to crash.

    >
    > > > One is that your program is using up all available memory.  That's
    > > > (in my experiece) the less common reason.

    >
    > > > The most common reason is that something, before the allocation was
    > > > started, corrupted the memory that the allocator is using.

    >
    > > > Look at your pointer/new/delete usage.  I'd bet that you use a
    > > > pointer somewhere after you deleted the object that it pointed to.

    >
    > > > >#0  0x0000003f9b063803 in
    > > > >std::_List_node_base::hook(std::_List_node_base*) () from /usr/lib64/
    > > > >libstdc++.so.6
    > > > >#1  0x00000000007ad596 in std::list<::MyClient*,
    > > > >std::allocator<::MyClient*> >::_M_insert (
    > > > >    this=0x1e19780, __position=, __x=@0x7fdbbbdbdd38)
    > > > >    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    > > > >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:1140
    > > > >#2  0x00000000007ad5c1 in std::list<::MyClient*,
    > > > >std::allocator<::MyClient*> >::push_back (
    > > > >    this=0x1e19780, __x=@0x7fdbbbdbdd38)
    > > > >    at /home/linux/rhes4_x64/bin/../lib/gcc/x86_64-unknown-linux-gnu/
    > > > >4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:761
    > > > >#3  0x00000000007ac356 in ::MyClientObjPool::addNewObject
    > > > >(this=0x1e19678)
    > > > >    at objpool/MyClientObjPool.cxx:254
    > > > >#4  0x00000000007ac744 in ::MyClientObjPool::checkUpdate
    > > > >(this=0x1e19678)
    > > > >    at objpool/MyClientObjPool.cxx:175
    > > > >#5  0x00000000007ac82d in careTakerThreadMain (p=0x1e19678) at objpool/
    > > > >MyClientObjPool.cxx:28
    > > > >#6  0x0000003f978077e1 in start_thread () from /lib64/libpthread.so.0
    > > > >#7  0x0000003f974e153d in clone () from /lib64/libc.so.6

    >
    > > > >Thank you,
    > > > >Jaydeep

    >
    > > > --
    > > > Drew Lawson            |  Savage bed foot-warmer
    > > >                        |    of purest feline ancestry
    > > >                        |  Look out little furry folk
    > > >                        |    it's the all-night working cat

    >
    > > If the pointers in the list are new'd then you need to call delete on
    > > the object BEFORE erasing the object in the list.  This is a common
    > > mistake.  It is one of the not to do items in Effective C++.

    >
    > > But without seeing other bits of your code this is pure speculation.

    >
    > Hi Drew,
    >
    > I am calling delete on object after erasing from the list. Do you
    > thing this might have triggered core dump?
    >
    > Thank you,
    > Jaydeep


    I thought that was a good guess.

    If you have erased the element in the container then what are you
    deleting?

    A few points:
    1. Definitely delete before erase.
    2. If possible use a smart pointer. That way you don't have to worry
    about managing the lifetime of the pointer.
    Angus, Mar 25, 2011
    #10
    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. Ganesh Gella
    Replies:
    5
    Views:
    1,137
    John Harrison
    Jul 14, 2003
  2. halfdog
    Replies:
    12
    Views:
    12,409
  3. Matthias =?ISO-8859-1?Q?K=E4ppler?=

    std::string::push_back vs. std::string::operator+=

    Matthias =?ISO-8859-1?Q?K=E4ppler?=, Nov 22, 2004, in forum: C++
    Replies:
    2
    Views:
    4,117
    Jonathan Mcdougall
    Nov 23, 2004
  4. SpreadTooThin
    Replies:
    9
    Views:
    1,583
    SpreadTooThin
    Jun 25, 2009
  5. robeson
    Replies:
    3
    Views:
    627
    White Wolf
    Nov 19, 2009
Loading...

Share This Page