On Tue, Oct 6, 2009 at 7:34 PM, Holger Kiehl <Holger.Kiehl@xxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
