Re: Question about core files

[vinit dhatrak <vinit.dhatrak@gmail.com>]

On Tue, Oct 6, 2009 at 7:34 PM, Holger Kiehl <Holger.Kiehl@dwd.de> 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

GCC allows you to use -g option with -O flag. Here is what "man gcc" says,
[snip]

         GCC allows you to use -g with -O.  The shortcuts taken by
optimized code may occasionally produce surprising results: some
variables you declared may not exist at all; flow of control may
briefly move where you did not expect it; some statements may not be
executed because they compute constant results or their values were
already at hand; some statements may execute in different places
because they were moved out of loops.

[\snip]


-Vinit


> 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. 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html