By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,605 Members | 1,488 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,605 IT Pros & Developers. It's quick & easy.

Bug in std containers?

P: n/a

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<doubleanewstack; // 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<doubleanewstack;
(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*,(::operator
new(_RWSTD_STATIC_CAST(size_t,(n)))));
(dbx)

Nov 16 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
t@1 (l@1) stopped in Solver::feed at line 249 in file "solver.cc"
249 stack<doubleanewstack;
(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*,(::operator
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 '06 #2

P: n/a
<ja****@gmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
>
>t@1 (l@1) stopped in Solver::feed at line 249 in file "solver.cc"
249 stack<doubleanewstack;
(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*,(::operator
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...
Nov 16 '06 #3

P: n/a
Hi

ja****@gmail.com wrote:
stack<doubleanewstack; // 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

Nov 16 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.