|
Home > Archive > Unix Programming > September 2007 > interpreting a gdb core dump
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
interpreting a gdb core dump
|
|
|
| hello everyone,
i am attempting to debug an application and for that i enabled core
dump on the target board running the application.
when that core dump was generated, i tried opening it as:
target_sys:~# gdb controller core.1472 # where 'controller' is the
application
the output i got is:
GNU gdb 6.1
Copyright 2004 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 "--host=i386-pc-linux-gnu --target=arm-
linux"...
Core was generated by `./controller'.
Program terminated with signal 6, Aborted.
warning: Wrong size fpregset in core file.
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x401c7944 in kill () from /lib/libc.so.6
.... how should i interpret this msg?? could there actually be bug in
libc.so.6 (actually points to libc-2.3.2) ??
could it be a libraries mismatch between the this libc that was used
to compile the executable and the lib existing on the target board
that is loaded during runtime??
im saying that because due to some unavoidable reasons the development
system along with its scratchbox installation where moved to a new
system... unfortunately its possible that not exactly the same
core,lib,toolchain files were installed in the 2 systems... so it is
possible that the same libc-2.3.2 file is somewhat different
version...
could that cause the crashes too?
thank you in advance for your help
nass
| |
| Paul Pluzhnikov 2007-09-17, 1:29 pm |
| nass <athanasios.silis@gmail.com> writes:
> target_sys:~# gdb controller core.1472
....
> Loaded symbols for /lib/ld-linux.so.2
> #0 0x401c7944 in kill () from /lib/libc.so.6
>
> ... how should i interpret this msg??
The application terminated with SIGABRT while in kill() libc
function.
> could there actually be bug in
> libc.so.6 (actually points to libc-2.3.2) ??
What makes you think that there is a bug in libc?
You certainly presented no evidence for such a conclusion.
The most interesting question you should ask is "where in the
applicaiton code is this happening?"; use gdb 'where' command to
find out.
> could it be a libraries mismatch
There could be anything ...
In general, you need the exact same version of libraries available
to gdb that were used when the core dump was generated. But your
symptoms do not (yet) give any indication (that I see) that there
is any mismatch.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
|
| On Sep 17, 5:37 pm, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
wrote:
> nass <athanasios.si...@gmail.com> writes:
> ...
>
>
> The application terminated with SIGABRT while in kill() libc
> function.
>
>
> What makes you think that there is a bug in libc?
> You certainly presented no evidence for such a conclusion.
>
> The most interesting question you should ask is "where in the
> applicaiton code is this happening?"; use gdb 'where' command to
> find out.
>
>
> There could be anything ...
>
> In general, you need the exact same version of libraries available
> to gdb that were used when the core dump was generated. But your
> symptoms do not (yet) give any indication (that I see) that there
> is any mismatch.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.
thank you for your reply.
well 'where' (didn;t know this command) returns:
(gdb) where
#0 0x401c7944 in kill () from /lib/libc.so.6
#1 0x402ca0ec in pthread_kill () from /lib/libpthread.so.0
#2 0x402ca43c in raise () from /lib/libpthread.so.0
#3 0x401c776c in raise () from /lib/libc.so.6
#4 0x401c891c in abort () from /lib/libc.so.6
#5 0x400f638c in __cxa_call_unexpected () from /usr/lib/libstdc++.so.
5
#6 0x400f63d8 in std::terminate () from /usr/lib/libstdc++.so.5
#7 0x400f6538 in __cxa_throw () from /usr/lib/libstdc++.so.5
#8 0x400f67c0 in operator new () from /usr/lib/libstdc++.so.5
#9 0x400f69b4 in operator new[] () from /usr/lib/libstdc++.so.5
#10 0x0002404c in LogBase::ThereIsFreeSpace (this=0x67060) at
logger.cpp:212
#11 0x00022a74 in LogBase::Update (this=0x67060) at logger.cpp:34
#12 0x0003bba4 in MainObj::Update (this=0xbec4b4f8) at core.cpp:630
#13 0x0003ed28 in MainObj::Run (this=0xbec4b4f8) at core.cpp:1595
#14 0x00040278 in main (argc=1, argv=0xbec4bdc4) at main.cpp:81
so this starts to make some sense in #10 . there in line 212 of
logger.cpp im using the 'new' operator to allocate some space for a
variable.
basically i open a file for read, seek its endpos , use that as a
length measurement and use that length to allocate memory space.
summarizing:
ifstream ds_stream;
ds_stream.open(DISK_SPACE_FILE, ios::in);
if (!ds_stream)
{
//cout<<"file didnt open!"<<endl;
}
else
{
ds_stream.seekg (0, ios::end);
int length = ds_stream.tellg();
ds_stream.seekg (1, ios::beg); //leave the 1st space that exists
in the file
char *buffer = new char [length-1];
ds_stream.read(buffer,length-1);
ds_stream.close();
string tmpStr(buffer);
delete[] buffer;
istringstream strToInt(tmpStr);
strToInt >> free_space;
basically the file contains the output number (only the number) of 'df
-k'... in the form ' 23454' (note the initial space). so i open the
file, get its length, allocate length-1 and read from pos=1 to end...
it should work... anyhow, line 212 is 'char *buffer = new char
[length-1];'...
am i missing something here?
nass
| |
| Michael Oswald 2007-09-18, 7:30 am |
| nass wrote:
>
> (gdb) where
> #0 0x401c7944 in kill () from /lib/libc.so.6
> #1 0x402ca0ec in pthread_kill () from /lib/libpthread.so.0
> #2 0x402ca43c in raise () from /lib/libpthread.so.0
> #3 0x401c776c in raise () from /lib/libc.so.6
> #4 0x401c891c in abort () from /lib/libc.so.6
> #5 0x400f638c in __cxa_call_unexpected () from /usr/lib/libstdc++.so.
> 5
> #6 0x400f63d8 in std::terminate () from /usr/lib/libstdc++.so.5
> #7 0x400f6538 in __cxa_throw () from /usr/lib/libstdc++.so.5
> #8 0x400f67c0 in operator new () from /usr/lib/libstdc++.so.5
> #9 0x400f69b4 in operator new[] () from /usr/lib/libstdc++.so.5
> #10 0x0002404c in LogBase::ThereIsFreeSpace (this=0x67060) at
> logger.cpp:212
> #11 0x00022a74 in LogBase::Update (this=0x67060) at logger.cpp:34
> #12 0x0003bba4 in MainObj::Update (this=0xbec4b4f8) at core.cpp:630
> #13 0x0003ed28 in MainObj::Run (this=0xbec4b4f8) at core.cpp:1595
> #14 0x00040278 in main (argc=1, argv=0xbec4bdc4) at main.cpp:81
>
>
> char *buffer = new char [length-1];
>
> am i missing something here?
Yes. If you look at frame #7 there is a __cxa_throw which calls
std::terminate(). This simply means, that the call to new[] throws an
exception (in this case a std::bad_alloc), which means, that the system
can't allocate that much menory, so the size passed to new is too large.
lg,
Michael
> nass
| |
|
| On Sep 18, 3:24 pm, Michael Oswald <muell...@gmx.net> wrote:[vbcol=seagreen]
> nass wrote:
>
>
>
>
> Yes. If you look at frame #7 there is a __cxa_throw which calls
> std::terminate(). This simply means, that the call to new[] throws an
> exception (in this case a std::bad_alloc), which means, that the system
> can't allocate that much menory, so the size passed to new is too large.
>
> lg,
> Michael
>
that much memory??? i usually require 7-8 bytes....
| |
|
| On Sep 18, 3:24 pm, Michael Oswald <muell...@gmx.net> wrote:[vbcol=seagreen]
> nass wrote:
>
>
>
>
> Yes. If you look at frame #7 there is a __cxa_throw which calls
> std::terminate(). This simply means, that the call to new[] throws an
> exception (in this case a std::bad_alloc), which means, that the system
> can't allocate that much menory, so the size passed to new is too large.
>
> lg,
> Michael
>
that much memory??? i usually require 7-8 bytes....
| |
|
| On Sep 18, 3:24 pm, Michael Oswald <muell...@gmx.net> wrote:[vbcol=seagreen]
> nass wrote:
>
>
>
>
> Yes. If you look at frame #7 there is a __cxa_throw which calls
> std::terminate(). This simply means, that the call to new[] throws an
> exception (in this case a std::bad_alloc), which means, that the system
> can't allocate that much menory, so the size passed to new is too large.
>
> lg,
> Michael
>
that much memory??? i usually require 7-8 bytes....
| |
|
| On Sep 18, 3:24 pm, Michael Oswald <muell...@gmx.net> wrote:[vbcol=seagreen]
> nass wrote:
>
>
>
>
> Yes. If you look at frame #7 there is a __cxa_throw which calls
> std::terminate(). This simply means, that the call to new[] throws an
> exception (in this case a std::bad_alloc), which means, that the system
> can't allocate that much menory, so the size passed to new is too large.
>
> lg,
> Michael
>
that much memory??? i usually require 7-8 bytes....
| |
|
| On Sep 18, 5:07 pm, nass <athanasios.si...@gmail.com> wrote:
> On Sep 18, 3:24 pm, Michael Oswald <muell...@gmx.net> wrote:
>
>
>
>
>
>
>
>
>
>
> that much memory??? i usually require 7-8 bytes....
ooops sorry about that
| |
| Scott Lurndal 2007-09-18, 1:27 pm |
| nass <athanasios.silis@gmail.com> writes:
>#10 0x0002404c in LogBase::ThereIsFreeSpace (this=0x67060) at
>logger.cpp:212
>so this starts to make some sense in #10 . there in line 212 of
>logger.cpp im using the 'new' operator to allocate some space for a
>variable.
> ds_stream.seekg (0, ios::end);
> int length = ds_stream.tellg();
> ds_stream.seekg (1, ios::beg); //leave the 1st space that exists
>in the file
>
> char *buffer = new char [length-1];
>
What if length == 0?
scott
| |
| Paul Pluzhnikov 2007-09-19, 1:29 am |
| nass <athanasios.silis@gmail.com> writes:
> well 'where' (didn;t know this command) returns:
If you don't know about 'where', you don't know much about debuggers,
and it's time to learn. In particular, this sequence of gdb commands:
frame 10
print length
may prove illuminating.
> summarizing:
....
> ds_stream.seekg (0, ios::end);
> int length = ds_stream.tellg();
> ds_stream.seekg (1, ios::beg); //leave the 1st space that exists in the file
>
> char *buffer = new char [length-1];
As Scott Lurndal probably correctly guessed, your abort is likely
caused by length == 0.
However, there are more bugs in your code. Assume the file contains
2 bytes: "<space>1". Your length == 2, you allocate 1 byte, and
read 1 character '1' into it:
> ds_stream.read(buffer,length-1);
At this point 'buffer' does not contain a properly terminated
C-style string (there is no terminating '\0' in the buffer).
> ds_stream.close();
> string tmpStr(buffer);
This string constructor expects a properly terminated C-style string,
which is not what you gave it. Calling it the way you do invokes
undefined behaviour.
If you are lucky, it will find the terminator close by.
If you are unlucky, tmpString may contain value
"123456789012345678901234567890exzy" at that point.
> delete[] buffer;
>
> istringstream strToInt(tmpStr);
> strToInt >> free_space;
So you just wanted to read an integer from the file stream?
Here is how you can kill 2 bugs at once, and make your code correct,
simple *and* more efficient all at the same time:
ifstream ds_stream(DISK_SPACE_FILE, ios::in);
if (ds_stream)
ds_stream >> free_space;
> am i missing something here?
I recommend reading up on iostreams (you probably didn't know their
extraction operators automatically skip white space either).
I also recommend running your program through Valgrind, and repeating
that very often for the next couple of month -- VG would have cought
your bug above even when your program didn't crash.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|