Re: Question about core files

On Tue, Oct 6, 2009 at 7:34 PM, Holger Kiehl <[email protected]> wrote:
> Hello
>
> Most the time I compile my application without the -g option due to
> performance reasons. Problem is that when it hits some bug and dumps
> core, this is not very useful because there is hardly any information
> in it. Is there some way to get some useful information out of
> the core file.

Is it possible to post your code ? Atleast the start_process()
function. Given that you have got a sigsegv it is probably an invalid
pointer access.

You can also try to print $eip (or rip since this is 64 bit machine)
and look around the assembly . Output of "disas start_process" from
gdb will also help.


> For example one of my program crashed and with gdb
> I see the following:
>
>   afd@helena:~$ gdb fd core.2515
>   GNU gdb Fedora (6.8-24.fc9)
>   Copyright (C) 2008 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>   and "show warranty" for details.
>   This GDB was configured as "x86_64-redhat-linux-gnu"...
>   (no debugging symbols found)
>
>   warning: Can't read pathname for load map: Input/output error.
>   Reading symbols from /lib64/libc-2.8.so...Reading symbols from
> /usr/lib/debug/lib64/libc-2.8.so.debug...done.
>   done.
>   Loaded symbols for /lib64/libc-2.8.so
>   Reading symbols from /lib64/ld-2.8.so...Reading symbols from
> /usr/lib/debug/lib64/ld-2.8.so.debug...done.
>   done.
>   Loaded symbols for /lib64/ld-2.8.so
>   Reading symbols from /lib64/libnss_files-2.8.so...Reading symbols from
> /usr/lib/debug/lib64/libnss_files-2.8.so.debug...done.
>   done.
>   Loaded symbols for /lib64/libnss_files-2.8.so
>   Core was generated by `fd -w /home/afd'.
>   Program terminated with signal 6, Aborted.
>   [New process 2515]
>   #0  0x000000304cc32215 in raise (sig=<value optimized out>)
>       at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>   64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
>   (gdb) where
>   #0  0x000000304cc32215 in raise (sig=<value optimized out>)
>       at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>   #1  0x000000304cc33d83 in abort () at abort.c:88
>   #2  0x000000000040b174 in sig_segv ()
>   #3  <signal handler called>
>   #4  0x0000000000404b5f in start_process ()
>   #5  0x0000000000407b9a in main ()
>
> At least I know that the bug is in my function start_process. But is
> there some way to find out at what line it happened?
>
> Thanks,
> Holger
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in
> the body of a message to [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Thanks -
Manish
==================================
[$\*.^ -- I miss being one of them
==================================
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html