FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On Fri, 21 Feb 2003 10:31:54 +1100, "Steve Dumbrell"
<steve.dumbrell AT cogent.bnpparibas.com.au> wrote:
> 
> The snapshot we are using is a download from the freetds site dated the
> 19-feb-2003.

Well, that's pretty current. ;-)  It shouldn't be too hard to diagnose.  

> Tsql crashes after the core dump so the 'bt' command doesn't work.

If you start tsql from within gdb, gdb will trap the segment fault signal
and give you control.  Here's a trivial example:

$ cat t.c
#include <stdlib.h>
main() { 
puts("hi");
strcpy( "oops", NULL);
return 0;
}
$ make CFLAGS=-g t
cc -g   -o t t.c 
$ script t.err
Script started, output file is t.err
$ gdb t
(gdb) r
Starting program: /tmp/t 
hi

Program received signal SIGSEGV, Segmentation fault.
0x480c32d4 in strcpy ()
(gdb) bt
#0  0x480c32d4 in strcpy ()
#1  0x804892a in _fini ()
#2  0x80485e9 in ___start ()
(gdb) l
1       #include <stdlib.h>
2       main() { 
3       puts("hi");
4       strcpy( "oops", NULL);
5       return 0;
6       }
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) quit
$ exit
Script done, output file is t.err

t.c obviously attempts to copy from a null pointer on line 4.  gdb hears
the segfault, stops, and tells us where we were: in strcpy().  In FreeTDS
the stack trace will be much deeper, of course.  

You're at GMT +11.  Maybe you want to get some lunch first?  

--jkl