[freetds] FreeTDS (CVS version) hangs on reading column data larger than 256 bytes
James K. Lowden
jklowden at schemamania.org
Tue Apr 15 00:20:21 EDT 2003
On Mon, 14 Apr 2003 18:42:54 -0700 (PDT), Chad Wagner <vdr781 at yahoo.com>
> --- "James K. Lowden" <jklowden at schemamania.org>
> > Please tell us about anything else you find. I'm
> > gaining confidence that
> > we're now once more able to handle server-side UCS-2
> The only other thing I found, was that when UCS-2LE
> fails for a iconv conversion the login loops
> continously. It took me a little while (tracing
> through the application) to figure out that my iconv
> library was so old that it didn't support UCS-2LE.
Ouch. We could handle that better, eh?
> So, possibly, a check in configure for ability to
> convert from UCS-2LE to ISO-8859-1 (or local charset?)
> should be done.
The current Theory of Operation is that if iconv can't convert, we'll try
the trusty old bash-the-high-byte approach and hope for the best. We
should emit an error message warning you about what's going on, but I
think atm it's only logged.
I'll look into why this causes a problem during login.
> tds_iconv_open() would need to probably communicate
> back some sort of error conditions.
would be zero, and
TDSSOCKET::iconv_info->to_wire would be -1
and TDSSOCKET::iconv_info->from_wire would be -1
Probably, we should trap errno at that point (set on failure by
iconv_open) in the TDSICONVINFO structure.
> I am just not
> familiar enough with the internals, yet, to understand
> how errors are communicated back to application
> layers. I only learn more about the low level
> packet/communication as I encounter or investigate
I appreciate your help and diligence, Chad. I know it's unpleasant to
learn about broken code from crashing/hanging applications. Unfortunately
(for you), I'm working in unfamiliar territory with a wide variety of
implementation variables, so the bug potential is masochistically high.
Thanks for your patience. :-)
More information about the FreeTDS