FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Steven J. Backus [mailto:backus AT math.utah.edu]
> Sent: July 30, 2003 4:30 PM
> 
> id          did         dmonth      dday        dyear       
> dage orderinlist i1   i2   i3   i4   i5   family
> ----------- ----------- ----------- ----------- ----------- 
> ---- ----------- ---- ---- ---- ---- ---- ------
> 176936      300004      2           5           1904        
> 79   1           NULL NULL NULL NULL I64TY Y      
> 
> That "TY" in there is mighty suspicious looking.  

Agreed.  

> Using gdb I get:
> 
> (gdb) print i5
> $1 = "\00064\000"

If you did that after the dbprrow, it wouldn't mean anything because dbprrow
ignore your bindings.  

This won't be easy to find, if in fact we find it at all.  Try this, if you
like.  

Set a breakpoint where you call dbresults, just before all the dbbind
statements.  Run to there, then set a watchpoint at the absolute location
you're interested in, something like this:

Breakpoint 8, main (argc=4, argv=0xbfbfd9e8) at t.c:46
46              if (dbresults(dbproc) == SUCCEED) {
(gdb) p &i5
$8 = (DBCHAR (*)[5]) 0xbfbfd978
                     ^^^^^^^^^^ i5[0]; you might want i5[3]
(gdb) watch *(DBCHAR (*))0xbfbfd978 == 0
Watchpoint 15: *(DBCHAR *) 3217021304 == 0

On my machine, i5[0] already had a zero in it.  Since you're watching for a
'T' in i5[3], you might want to initialize i5[3] to zero and have the
watchpoint look there.  Then continue and prepare to wait; watchpoints slow
down your program by about 100 times, afaict.  

(gdb) c
Continuing.

You should use an absolute location, not the i5 symbol, because gdb will
delete your watchpoint at its convenience otherwise.  

You might want to know what's "normal".   On my system, i5[0] was touched
here:

Watchpoint 15: *(DBCHAR *) 3217021304 == 0

Old value = 1
           ^^^ meaning 3217021304 == 0 was true
New value = 0
0x4811629f in memcpy ()
(gdb) bt
#0  0x4811629f in memcpy ()
#1  0x3 in ?? ()
#2  0x4806e5da in buffer_transfer_bound_data (rowtype=-1,
    compute_id=1208357376, buf=0x8052004, dbproc=0x8052000, row_num=1)
    at ../../../src/dblib/dblib.c:449
#3  0x4806f7da in dbnextrow (dbproc=0x8052000)
    at ../../../src/dblib/dblib.c:1542
#4  0x8048fa8 in main (argc=4, argv=0xbfbfd9e8) at t.c:68
#5  0x8048a1d in ___start ()

The call stack made sense, but when I set my frame to 2 and examined the
arguments to buffer_transfer_bound_data(), some of them didn't seem
possible.  Just a warning that if you see something down there you don't
believe, you're right to be skeptical.  On the other hand, you might have
stumbled on something subtle that the rest of us have been blissfully
avoiding.  

Good luck in any case.  

--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.