Skip to Content.
Sympa Menu

freetds - Re: Hungry PHP

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Paul Schaap" <Paul.Schaap AT dingoblue.com.au>
  • To: freetds
  • Subject: Re: Hungry PHP
  • Date: Mon, 13 Sep 1999 21:57:1


Brian,

On 09/13/99, "Brian Bruns <camber AT umcc.ais.org>" wrote:
> Ok, I think I've got this one.
>
> PHP relies on some interesting undocumented behaviour on the part of the
> Sybase libraries. OpenClient apparently memset()'s strings to ' ' (space)
> before converting dates to char. So if you have say:
>
> Sep 13, 1999 18:00:00
>
> It would be followed by a null character and then the remainder of the
> string is spaces.
>
> Now when dbconvert() is passed a -1 for the destination length,
> which means the buffer is large enough to handle the string, and the
> string is to be null term'd, dblib still memset()'s it to spaces. The
> question is: where does it get this size? I set it to 30, because PHP has
> the dbdatlen() + 20 (which is 28). But it seems pretty dangerous to me to
> be initializing memory beyond the end of the string!
>
> Anyway, after PHP gets the string back he starts at the res_length (28)
> and works his way backward to find a non space character and this is the
> length of the string. Thus when freetds returned 'Sep 13, 1999 18:00:00'
> followed by the null character, followed by undefined values, the
> res_length remained 28 and the null and garbage characters were included
> in the output, which kills netscape and probably didn't look too pretty
> under IE either. So, freetds has been 'fixed' to replicate the OpenClient
> behaviour even though I don't agree with it.
>
> By the way for the curious, a better way of doing this is to use the
> return from dbconvert() to get the size of the resulting string. I am
> going to patch PHP to do this correctly.
>
> Anyway, once again get the latest CVS and give it a try.
>

I feel awful returning bad news after you have obviously put alot of effort
in ! I mostly get segfault 11's at the apache php side and it returns maybe
once every 10-30 requests with (here is the good news) no hungry behaviour,
but the dates are still wrong ! It still works correctly under sqsh :-)

On another report that used to work correctly about two cvs's ago I have
noticed that where sqsh returns 'NULL' freetds exhibits the hungry
behaviour so this may be related.

Do you need more detail, I happy to learn more to help ...

> Cheers,
>
> Brian
>
> On Mon, 13 Sep 1999, Brian Bruns wrote:
>
> >
> > Well, it seems to be the same issue in that you have a null in the output
> > stream. However, dbdatlen() shouldn't come into play here, so it's a
> > different cause (but same result). I'll look into later day (getting ready
> > to drop my son off at school now, so I only have a minute).
> >

Dads of the world unite, I have a boy and girl myself :-)

> > I've got a few ideas, I'll post back to the list if any of them pan
> out.
> >
> > Brian
> >
> > On Mon, 13 Sep 1999, Paul Schaap wrote:
> >
> > > Brian,
> > >
> > > > Ok, looking at things, I may not need to be so drastic. PHP does
> > > > something
> > > > like this:
> > > >
> > > > res_length = dbdatlen(dbproc, offset);
> > > > dbconvert(NULL,coltype(offset),dbdata(sybase_ptr->link,offset),
> > > > res_length,SYBCHAR,res_buf,-1);
> > > >
> > > > So it should indeed null terminate them (the -1 means to null term the
> > > > result), however dbdatlen() returns an incorrect value. I fixed that
> > > > and
> > > > also fixed it for the NULL case as well. I'm going to try all the test
> > > > cases tommorow on a real dblib machine and then I think I should be
> > > > able
> > > > to fix the other cases. But try the latest CVS and let me know.
> > > >
> > > > Brian
> > > >
> > >
> > > For the VARCHARS this is now OK. Back onto the DATETIME issue, certain
> > > in
> > > the knowledge that the library IS dynamically compiled, I have done a
> > > little more testing to reveal that DATETIME data is also hungry ! Could
> > > you
> > > safely apply this patch to the DATETIME data types ?
> > >
> > > As I mentioned before using sqsh worked perfectly but php did not.
> > > Therefore I tried a full recompile apache and php against the working
> > > freetds from scratch to no avail. I therefore think the next question is
> > > if
> > > datetimes are being treated differently, or, if the hungry issue is the
> > > cause, or, if we should bother wasting any more time on it ?
> > >
> > > >From php ...
> > > ID Raw Converted
> > > 10001486 Feb 25 2003 03:50AM Sep 13 1999 4:15PM
> > > 10001485 Jan 29 2003 03:50AM Sep 13 1999 3:48PM
> > > 10001484 Jan 10 2003 03:50AM Sep 13 1999 3:29PM
> > > 10001483 Nov 24 2002 03:50AM Sep 13 1999 2:42PM
> > > 10001480 Jun 03 2002 03:50AM Sep 13 1999 11:48AM
> > >
> > > >From sqsh ...
> > > ID DateAdded
> > > -------- ------------------- --------------------
> > > 10001486 Sep 13 1999 04:15PM Sep 13 1999 4:15PM
> > > 10001485 Sep 13 1999 03:48PM Sep 13 1999 3:48PM
> > > 10001484 Sep 13 1999 03:29PM Sep 13 1999 3:29PM
> > > 10001483 Sep 13 1999 02:42PM Sep 13 1999 2:42PM
> > > 10001480 Sep 13 1999 11:48AM Sep 13 1999 11:48AM
> > >
> > > I'm also concerned any change to fix the php link may affect sqsh :-(
> > >
> >
> >

REGARDS
Paul




Archive powered by MHonArc 2.6.24.

Top of Page