Bug in std containers?

[janzon]

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*,perator
new(_RWSTD_STATIC_CAST(size_t,(n)))));
(dbx)

 

[janzon]

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*,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.

 

[Jim Langston]

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*,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...

 

[Markus Moll]

Hi

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