Skip to Content.
Sympa Menu

freetds - Re: [freetds] MS-SQL ntext fields?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Rich Young" <rich AT experienceplus.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] MS-SQL ntext fields?
  • Date: Wed, 10 Jan 2007 15:32:53 -0700

I'll reissue the disclaimer that I'm a novice at this level of
bughunting, but is it possible that we're missing something more obvious
than all this? I mean, if I have a query that works in tsql and isql,
but fails when it's part of a PHP script, does that prove it's a PHP
bug? Because these queries *do* run fine in tsql, but choke when run in
PHP.

--------------------------
I'm Rich Young, and I approved this message.


> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James
> K. Lowden
> Sent: Tuesday, January 09, 2007 5:53 PM
> To: FreeTDS Development Group
> Subject: Re: [freetds] MS-SQL ntext fields?
>
> Rich Young wrote:
> > (gdb) bt
> > #0 0x0000003f6fd71f07 in memcpy () from /lib64/tls/libc.so.6
> > #1 0x00000000004f8030 in _estrndup ()
> > #2 0x0000002a98a82b2b in zif_odbc_result () from
> > /usr/lib64/php4/odbc.so
> ...
> > Unfortunately, I'm enough of a newbie here that I still
> don't understand
> > whether this is a PHP or FreeTDS bug. Any insight?
>
> Unfortunately, no. It says odbc.so (which belongs the DM,
> not FreeTDS)
> eventually asked memcpy(3) to copy something, probably a NULL
> pointer, but
> maybe _estrndup expects a null-terminated input and wasn't given one.
> Either way, it's impossible without a lot more information to
> know whether
> the bad pointer/data came from FreeTDS or not.
>
> Asked to guess, I always guess it's FreeTDS's fault because
> PHP is a much
> bigger project with a much bigger user base. Besides, it's
> humble. The
> theory is usually that some function is behaving in a way that is
> surprising the client. But unless we know which function under what
> circumstances, we don't have much to go on.
>
> A TDSDUMP log would at least show the result set being
> processed. I'm not
> sure that would tell us much. In theory, with that
> information and enough
> source code you could walk the stack of your dump figure out
> who passed
> what to whom. I wouldn't do that unless lives were at stake.
>
> You appear to be using 64-bit ODBC, which has some known issues.
>
> On the whole I wish you were using the mssql extension
> instead. It uses
> db-lib and so avoids one layer. That would make it easier,
> but still not
> easy. :-(
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>




Archive powered by MHonArc 2.6.24.

Top of Page