Skip to Content.
Sympa Menu

freetds - RE: [freetds] Need Help on dblib program

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Need Help on dblib program
  • Date: Wed, 30 Jul 2003 17:32:07 -0400

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






Archive powered by MHonArc 2.6.24.

Top of Page