FreeTDS Development Group

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

> From: Gustavo A. Gonzalez
> Sent: Tuesday, August 30, 2005 1:25 PM
> 
> ...thanks regards J., and like a 2nd part of the same problem i saw
that the
> application crashes again and generates a core dump while get the
> following lines from a dberrhandle(err_handler) function:
> 
> Aug 29 20:43:51 ERROR[-187450448]: DB-Library error: Read from SQL
> server failed.  Aug 29 20:43:51 ERROR[-187450448]: Operating-system
> error: OpenClient
> 
> I can't caught the error message  from sql server and using gdb it
> shows a bt like this:
> 
> #0  0xf64e19de in tdsdump_dump_buf (buf=0x5fc868, length=153191704) at
> util.c:274
> #1  0xf64e1c99 in tdsdump_log (debug_lvl=4, fmt=0xf64f9646 
> "Sending packet @ %L\n%D\n") at util.c:378
> #2  0xf64e422c in tds_write_packet (tds=0x5fc848, final=104 'h') at
> write.c:481
> #3  0xf64e4c34 in tds_flush_packet (tds=0x5fc848) at write.c:513
> #4  0xf64ed310 in tds_send_cancel (tds=0x5feff8) at query.c:1563
> #5  0xf64d038e in dbcancel (dbproc=0x9a7c5e0) at dblib.c:2500
> 
> well ...i can suppose that a network problem causes that error 

Wow, that's very ugly.  Network errors are supposed to be reported to
the application (as yours seems to have been).  They're not supposed to
wreak havoc by pointing wildly to random places in memory.  

What version of FreeTDS are you using?  If it's anything older than
0.63, I suggest upgrading, for the simple reason that we've made many
changes to the network layer and aren't about to debug old versions.  If
0.63, you might want to check the archives for Frediano's "0.63.1"
patch.  These are changes that will be incorporated in the forthcoming
0.63.1 release.  

I'm sorry you don't have a TDSDUMP log for the above session.  It would
help isolate what went wrong. 

> i think that putting a dbcancel() in that instance of a problem
> would prevent me for any crashes, clearing all request pending and
> let me make other/s request
> .....is that correct?....

Unlikely.  By the time you're notified, I doubt whatever's broken is
recoverable.  Just my surmise, of course.  The only fix for a bug like
this is to find it and squish it.  

> and someone can explain me how to use properly
> dberrhandle(err_handler) and dbcancel to prevent that situations

It's inadvisable to call any db-lib function from within your error
handler; rtfm for dberrhandle().  Basically you'd have to avoid
recursion, and the suggested technique (setting the handler to NULL)
obviously blinds you to further errors.  

If you're running fairly current code, I'm afraid the only answer is to
fix the bug.  

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential 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.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.