FreeTDS Development Group

["Cooperstock, Dan" <dan.cooperstock AT hepcoe.com>]

OK, I'm back from 2 weeks' vacation. 

I tried that gdb run. I'm doing it from the directory that includes tsql.c.
I don't think I got the expected results though:

(gdb) b main
Breakpoint 1 at 0x4000000000004250: file tsql.c, line 410.
(gdb) r
Starting program: /usr/local/bin/tsql

Breakpoint 1, main (argc=1, argv=0x800003ffff7f0798) at tsql.c:410
410             if (msg->msg_number == 0) {
(gdb) watch dumpfile != 0
No symbol "dumpfile" in current context.

What do I try next?

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops AT hepcoe.com    416-597-5055

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK AT bernstein.com]
Sent: Friday, May 16, 2003 1:39 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

> From: Cooperstock, Dan [mailto:dan.cooperstock AT hepcoe.com]
> Sent: May 16, 2003 12:44 PM
>
> Then, if I run tsql with no arguments, I still get the same outputs as
> before - very verbose, and with the weird locale.

I think I know what's wrong, Dan, but not why.  It's tow things:

1.  We're still misdetecting some header file's function prototype. 
2.  Early on, a 1 (one) is written to the static variable
src/tds/util.c::dumpfile, tricking the logging functions into writing to
stdout. 

What should happen if you start tsql without arguments:

$ tsql
locale is "C"
locale charset is "646"
Missing argument -S or -H
Usage:  tsql [-S <server> | -H <hostname> -p <port>] ...

Perhaps a backtrace will help Frediano track down what's going on.  Could
you try this:

gdb tsql
(gdb) b main
(gdb) r [arguments]
(gdb) watch dumpfile != 0
Watchpoint 5: dumpfile != 0
(gdb) c
Continuing.
locale is "C"
locale charset is "646"
Watchpoint 5: dumpfile != 0

Old value = 0
New value = 1
0x4807efc1 in tdsdump_open (filename=0x804f240 "dump")
    at src/tds/util.c:195
195             } else if (NULL == (dumpfile = fopen(filename, "w"))) {
(gdb) bt
#0  0x4807efc1 in tdsdump_open (filename=0x804f240 "dump")
    at src/tds/util.c:195
#1  0x4807f7b1 in tds_connect (tds=0x8050000, connect_info=0x8050100)
    at src/tds/login.c:227
#2  0x804a31a in main (argc=7, argv=0xbfbfba20)
    at src/apps/tsql.c:483

My guess is you won't get anywhere near that far, that "dumpfile" is being
corrupted early and often.  The bt should expose the awry assignment. 

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.