Skip to Content.
Sympa Menu

freetds - RE: 0.60 + PHP + MSSQL2K segfault -- depends on the que ry (??)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: 0.60 + PHP + MSSQL2K segfault -- depends on the que ry (??)
  • Date: Fri, 15 Nov 2002 16:45:25 -0500


> From: Paul Kiela [mailto:pkiela AT sendtec.com]
> Sent: November 15, 2002 3:14 PM
>
> Hey guys,

Hi Paul,

Kudos on your excellent problem report!

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

> when I run it with php -q from the commandline, as from
> apache, I receive a Segmentation Fault either to the
> commandline or in my apache error log.
>
> Since the freetds.log is rather large, you can access it via
>
> http://www.initsix.org/freetds.log.html

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.

> here's the backtrace. I'm very new to gdb so I'm not even
> sure where to begin with this file. I can figure out a little
> of what its doing, but i'm pretty lost:
>
> (gdb) run blah.php
> Starting program: /usr/local/bin/php blah.php
> X-Powered-By: PHP/4.2.2
> Content-type: text/html
>
> 0
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x080da4e4 in shutdown_memory_manager (silent=0, clean_cache=0)
> at zend_alloc.c:467
> 467 REMOVE_POINTER_FROM_LIST(ptr);
> (gdb) bt
> #0 0x080da4e4 in shutdown_memory_manager (silent=0, clean_cache=0)
> at zend_alloc.c:467
> #1 0x0806293b in php_request_shutdown (dummy=0x0) at main.c:794
> #2 0x0806176b in main (argc=2, argv=0xbffffb64) at cgi_main.c:827
> #3 0x400f5507 in __libc_start_main (main=0x8060e74 <main>, argc=2,
> ubp_av=0xbffffb64, init=0x805f858 <_init>, fini=0x81052b0 <_fini>,
> rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffffb5c)
> at ../sysdeps/generic/libc-start.c:129
> (gdb)

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.

> I guess what's funnier is that when I change the SQL query
> from select * to select count(*), I get the following:

Not too surprising; I bet other queries work, too.

> Any suggestions as to what may be wrong, how I should go
> about fixing this?

1. Try doing the varbinary->char conversion on the server in the query.
2. Try TDS 7.0 (long shot).
3. Try to narrow it down to 1 column and 1 row
4. Try the PHP list.
5. Convert the query to a view and extract it with freebcp. That will
demonstrate that at least one db-lib tool can process the result set. Use
"-c" to write a text file.

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


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.





  • RE: 0.60 + PHP + MSSQL2K segfault -- depends on the que ry (??), Lowden, James K, 11/15/2002

Archive powered by MHonArc 2.6.24.

Top of Page