Re: Bug#89637: exim_tidydb crashes

[Joey Hess <joeyh@debian.org>]

Mark Baker wrote:
> As I understand it, debian distributing stripped binaries that originally
> had symbols in (rather than not putting them in in the first place) means
> that if I get a non-stripped binary it should have everything at the same
> addresses as the distributed one so should let me debug your core dump.

Wow, really? If so, that's a very good rationalle for requiring packages
be built with -g, even if DEB_BUILD_OPTIONS does not contain "debug".

However...

joey@gumdrop:~>cat bad.c
main () {
  static char *p;
  int x;
  for (x=0; x < 100000; x++)
        p[x]=x;
}
joey@gumdrop:~>gcc bad.c -o bad   
joey@gumdrop:~>./bad
zsh: segmentation fault (core dumped)  ./bad
+ exit 139
joey@gumdrop:~>gdb bad core
...
Core was generated by `./bad'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x80483ed in main ()
(gdb) bt
#0  0x80483ed in main ()
#1  0x4003df3c in __libc_start_main () from /lib/libc.so.6
(gdb) exit
joey@gumdrop:~>gcc -g bad.c -o bad
joey@gumdrop:~>gdb bad core       
...

warning: exec file is newer than core file.
Core was generated by `./bad'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x80483ed in main () at bad.c:5
5               p[x]=x;
(gdb) bt
#0  0x80483ed in main () at bad.c:5
#1  0x4003df3c in __libc_start_main () from /lib/libc.so.6
(gdb) joey@gumdrop:~>

So either I got lucky, or gdb can use the -g - built binary even with a core
file from a version that was not built with -g, and get proper stack tracing
and so on. Hmmm.

-- 
see shy jo