• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 337
  • Last Modified:

gdb backtrace only displays frame 0, why can't I see the call stack?

My C++ data server ran for 5 days until it dumped the core
by throwing St9bad_alloc.  When I gdb the core file and enter bt to
trace the call stack, here is what I get:

GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./Nqds.exe -P46090 -S nqds.cfg -L nqds.log -E 1'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.4...done.
Loaded symbols for /usr/lib/libstdc++.so.4
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
Error accessing memory address 0xbfffe75c: Invalid argument.
(gdb)  up
Error accessing memory address 0xbfffe75c: Invalid argument.
(gdb)  frame 1
Error accessing memory address 0xbfffe75c: Invalid argument.

So you see that I cannot tell where my code threw the exception.
And the core file is over 200M.  Any ideas?

Steven Katz
0
crownskatz
Asked:
crownskatz
1 Solution
 
brettmjohnsonCommented:
It is highly likely that your code has corrupted the stack,
quite probably a massive overrun of a local buffer on the
stack, trashing the return address to the calling routine.

0
 
ahoffmannCommented:
recompile your program with -g option, then start and check if it crashes again
If not it's most likely as brettmjohnson assumed: stack overflow, and as the function name suggests it's not only the stack but the heap also
0
 
crownskatzAuthor Commented:
Thanks for your responses.
I am already compiling using the -g option.
I think the error is caused when the application receives a delete transaction.
I coded the delete logic to call erase on the container element holding the data
but not the delete operator.  So after a while, the container still holds the memory for
all deleted elements.  This could run out the memory allocation.  I do not know if
this would corrupt the stack itself.  I still need to do more analysis and testing.
0
 
crownskatzAuthor Commented:
I recoded my delete logic to call erase on the container element and then to call
the delete operator.  The program has now been running for 8 days without a core
dump.  I never found out why the backtrace did not work.
When a program exhausts the memory allocator, does that corrupt the stack?
Thanks for your insights.
0
 
moduloCommented:
PAQed with points refunded (250)

modulo
Community Support Moderator
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Tackle projects and never again get stuck behind a technical roadblock.
Join Now