Bug in std containers?

Discussion in 'C++' started by janzon@gmail.com, Nov 16, 2006.

  1. Guest

    Hi

    I have a really weird bug. An object in my program contains a
    std::stack<T>. When push is called, the program crashes. To eliminate
    that the error has to do with what is pushed, I create a new local
    stack that has nothing to do with any other code. Then I push a 5 and
    the program crashes. In detail, i added

    stack<double> anewstack; // Code that has nothing to do with the
    rest of the program
    anewstack.push(5);

    instead of the call to the other stack (that call I out-commented). If
    I remove "irrelevant" code the bug disappears so I can't provide a
    small complete program that generates the bug.

    Does anyone have any clue how this kind of bug can appear, and be
    resolved? Below some output from the debugger. I'm working in Sun
    Solaris on a Sun X-Ray computer.


    t@1 (l@1) stopped in Solver::feed at line 249 in file "solver.cc"
    249 stack<double> anewstack;
    (dbx) next
    t@1 (l@1) stopped in Solver::feed at line 250 in file "solver.cc"
    250 anewstack.push(4);
    (dbx) next
    t@1 (l@1) signal SEGV (no mapping at the fault address) in
    _malloc_unlocked at 0xfed47090
    0xfed47090: _malloc_unlocked+0x023c: ld [%o0 + 8], %o1
    Current function is std::allocator<double>::allocate
    391 void * tmp = _RWSTD_STATIC_CAST(void*,:):eek:perator
    new(_RWSTD_STATIC_CAST(size_t,(n)))));
    (dbx)
    , Nov 16, 2006
    #1
    1. Advertising

  2. Guest


    > t@1 (l@1) stopped in Solver::feed at line 249 in file "solver.cc"
    > 249 stack<double> anewstack;
    > (dbx) next
    > t@1 (l@1) stopped in Solver::feed at line 250 in file "solver.cc"
    > 250 anewstack.push(4);
    > (dbx) next
    > t@1 (l@1) signal SEGV (no mapping at the fault address) in
    > _malloc_unlocked at 0xfed47090
    > 0xfed47090: _malloc_unlocked+0x023c: ld [%o0 + 8], %o1
    > Current function is std::allocator<double>::allocate
    > 391 void * tmp = _RWSTD_STATIC_CAST(void*,:):eek:perator
    > new(_RWSTD_STATIC_CAST(size_t,(n)))));
    > (dbx)



    Ok. I have a theory: Somewhere I write outside allocated memory. This
    corrupts data malloc needs for allocation, and hence an ordinary buffer
    overflow causes malloc to crash later on.
    , Nov 16, 2006
    #2
    1. Advertising

  3. Jim Langston Guest

    <> wrote in message
    news:...
    >
    >> t@1 (l@1) stopped in Solver::feed at line 249 in file "solver.cc"
    >> 249 stack<double> anewstack;
    >> (dbx) next
    >> t@1 (l@1) stopped in Solver::feed at line 250 in file "solver.cc"
    >> 250 anewstack.push(4);
    >> (dbx) next
    >> t@1 (l@1) signal SEGV (no mapping at the fault address) in
    >> _malloc_unlocked at 0xfed47090
    >> 0xfed47090: _malloc_unlocked+0x023c: ld [%o0 + 8], %o1
    >> Current function is std::allocator<double>::allocate
    >> 391 void * tmp = _RWSTD_STATIC_CAST(void*,:):eek:perator
    >> new(_RWSTD_STATIC_CAST(size_t,(n)))));
    >> (dbx)

    >
    >
    > Ok. I have a theory: Somewhere I write outside allocated memory. This
    > corrupts data malloc needs for allocation, and hence an ordinary buffer
    > overflow causes malloc to crash later on.


    Yep, that was going to be my suggestion. Most bugs of this type (I change
    something that should absolutely have nothing to do with it and the behavior
    changes) has to do with corrputed memory. You wrote somewhere you shouldn't
    of. Buffer over, unallocated pointer, etc...
    Jim Langston, Nov 16, 2006
    #3
  4. Markus Moll Guest

    Hi

    wrote:

    > stack<double> anewstack; // Code that has nothing to do with the
    > rest of the program
    > anewstack.push(5);
    >
    > instead of the call to the other stack (that call I out-commented). If
    > I remove "irrelevant" code the bug disappears so I can't provide a
    > small complete program that generates the bug.


    Ever thought that the code you removed might not be irrelevant at all? :)
    This is something that very much looks like undefined behavior. You have
    done something wrong before which now causes a crash. That's the bad thing
    with undefined behavior: your program might run, but it might also crash at
    any time.

    > Does anyone have any clue how this kind of bug can appear, and be
    > resolved? Below some output from the debugger. I'm working in Sun
    > Solaris on a Sun X-Ray computer.


    Look for the bug in your program. Those generally include free/delete-ing
    memory twice, falling off the end of a non-void function and so on...
    You should turn on all compiler warnings, it might help. If there is some
    sort of memory debugger for your platform, it might also be helpful.

    Markus
    Markus Moll, Nov 16, 2006
    #4
    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. Anton
    Replies:
    1
    Views:
    360
    Peter van Merkerk
    Aug 6, 2003
  2. Peter Jansson
    Replies:
    5
    Views:
    6,263
    Ivan Vecerina
    Mar 17, 2005
  3. Vinu
    Replies:
    4
    Views:
    342
    Jim Langston
    Jul 7, 2005
  4. Replies:
    7
    Views:
    534
    Pete Becker
    Jan 25, 2008
  5. Sebastian Mach
    Replies:
    5
    Views:
    301
Loading...

Share This Page