FreeTDS Development Group

[Paul Kiela <pkiela AT sendtec.com>]

Heya, 

I'm leaning towards PHP myself, since tsql can run the query no problem. I
twiddled with my config some more and now the query results in a 23MB (!!)
freetds.log file. I can put it up if anyone is really interested, but I
think I'm going to go find some PHP dev list to bug :)

Thanks for the info!


-----Original Message-----
From: Lowden, James K [mailto:LowdenJK AT bernstein.com] 
Sent: Friday, November 15, 2002 4:45 PM
To: TDS Development Group
Subject: [freetds] RE: 0.60 + PHP + MSSQL2K segfault -- depends on the que
ry (??)


> From: Paul Kiela [mailto
> tds version = 4.2
                ^^^ could be trouble, maybe try 7.0

$ grep type freetds.log.html |perl -ne'while (s/type = (\d\d)/$1/){ print
$1, $/;}' |sort |uniq |grep -w -f - include/tds.h |grep SYB
#define SYBCHAR      47   /* 0x2F */
#define SYBVARCHAR   39   /* 0x27 */
#define SYBDATETIME  61   /* 0x3D */
#define SYBBINARY    45   /* 0x2D */
#define SYBVARBINARY 37   /* 0x25 */

I wonder if our varbinary 4.2 support is completely good in the release
version.  It should be.  

Everything points to PHP trouble.  I say this as someone who expects FreeTDS
problems, given that PHP's user base is orders of magnitude bigger than
ours.  

Your log indicates your table has 24 colums of the above types, and
processes both rows:

$ grep nextrow freetds.log.html
2002-11-15 14:58:13 inside dbnextrow()
2002-11-15 14:58:13 leaving dbnextrow() returning -1
        [one]
2002-11-15 14:58:13 inside dbnextrow()
2002-11-15 14:58:13 leaving dbnextrow() returning -1
        [two]
2002-11-15 14:58:13 inside dbnextrow()
2002-11-15 14:58:13 leaving dbnextrow() returning -2
        [no more rows]

Completely normal.  


Not that FreeTDS can't goof things up, but the failure happened at
zend_alloc.c:467 in PHP, as part of its shutdown, while manipulating a list
of pointers.  I just really really doubt PHP's pointers are referencing
memory allocated by FreeTDS.  db-lib doesn't work that way.  Also, the stack
says FreeTDS isn't in the picture.  That is, the bt and the log both say PHP
is long done with FreeTDS when the segmentation fault is signalled.  

Of course, FreeTDS could have overwritten that pointer list if went wildly
out of control, but that would be a fine coincidence.  I bet the PHP folks
will want to know what "ptr" looks like.  

One note.  With version 0.60, FreeTDS changed its var/binary string
representation.  Previously, FreeTDS prepended "0x" to the character data.
Now it does not; you get two hex digits for every byte.  It might be that
PHP expects them or adds them or something.  Speculation.  

Regards, 

--jkl