Skip to Content.
Sympa Menu

freetds - Re: Still no solution for Solaris+PHP+Freetds+MSSQL7?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Still no solution for Solaris+PHP+Freetds+MSSQL7?
  • Date: Tue, 13 Nov 2001 23:52:12 -0500 (EST)


Ok it might help if I actually checked in the change... ;-)

Here is the patch, it should be in CVS now. This is a side effect of
breaking the libtds API to report messages prior to returning from
tds_connect(). *sigh*

I also took t0013 and t0014 (writetext stuff) out of make check, as they
do not work under all protocol versions. ctlib t0004 seems to be broke,
but i have to verify behaviour under the real openclient, likewise for
dblib t0009 (this one has been broken for a while).

As a side note, I'm facing some deadlines on a paying job, so I'm likely
to be less able to work on freetds for a bit. I'll still try to field bug
reports as I can, but deeper stuff is probably going to be put on the back
burner.

Cheers,

Brian

[camber@brian dblib]$ cvs diff dbutil.c
Index: dbutil.c
===================================================================
RCS file: /cvsroot/freetds/freetds/src/dblib/dbutil.c,v
retrieving revision 1.4
diff -r1.4 dbutil.c
76c76
< tds_reset_msg_info(dbproc->tds_socket);
---
> tds_reset_msg_info(tds);

The trick here is that dbproc is cast from tds->parent if it's after
login. Otherwise dbproc is null. I corrected the rest of the function
when making the libtds changes, but missed this one line.

On Tue, 13 Nov 2001, Bob Kline wrote:

> On Tue, 13 Nov 2001, Brian Bruns wrote:
>
> >
> > This is fixed in CVS actually, I corrected it over the weekend.
>
> Are you sure? I think the sequence of events today was as follows:
>
> 1. I saw the message from Vladimir reporting core dumps with logs
> that looked suspiciously like the ones I was looking at when
> I offered to send you reports of failed unit tests.
>
> 2. I went back to the cvs snapshot I had pulled down a week or so
> ago and verified the similarity. Fired up the debugger and
> wrote up the description of the problems I had found in dbutil.c.
> This was early this morning, about 7:00 EST. Posted the
> description to the list.
>
> 3. Saw Scott's reply to Rudy, who was experiencing similar core
> dumps. Scott suggested Rudy try the latest CVS code, which
> he said had fixed what he thought was the same problem. So
> I thought to myself, perhaps my analysis this morning was
> premature, as I was working from code that was several days
> old. I moved that snapshot out of the way and pulled down
> a fresh snapshot from SourceForge CVS. Same problems were
> still there in the code. This was somewhere between 10:30
> and 11:00 this morning.
>
> 4. Saw Rudy's reply to Scott, reporting that he had tried the
> latest snapshot, and was still getting core dumps. He seemed
> very eager for any clues, and it sounded as if he hadn't seen
> my earlier message to Vladimir today, so I replied and gave
> him the URL for that message.
>
> So if you're saying that you checked in a fix last night, then perhaps
> we have a serious problem with SourceForge CVS, because as far as I can
> tell I have verified that the bugs are still in what I thought I pulled
> down midmorning today.
>
> In case the fix you thought you were checking in for this problem turns
> out to be a fix for something else, here's a little bit more to add to
> my analysis this morning.
>
> In main() there is a call to tdsdbopen() in dblib.c. In that function,
> at line 438, the following code appears:
>
> dbproc = (DBPROCESS *)malloc(sizeof(DBPROCESS));
> tds_set_server(login->tds_login, server);
> dbproc->tds_socket = (void*)tds_connect(login->tds_login,
> (void*)dbproc);
>
> Note that at this point the dbproc structure has garbage (except that in
> the debugger the bytes are zeroed out).
>
> In tds_connect() we have:
>
> tds = tds_alloc_socket(512);
> tds_set_parent(tds, parent);
> ....
> tds_process_login_tokens(tds);
>
> In this code, parent is the pointer corresponding to the second argument
> to the call to tds_connect -- in other words the pointer to a struct
> containing garbage. From here tds_process_login_tokens calls the
> function tds_process_default_tokens, which in turn calls tds_process_msg
> which then calls dblib_handle_info_message. That's where we hit the
> code that tries to dereference ((DBPROCESS*)tds->parent)->tds_socket.
> But since we're still deep in the stack from the call back in tdsdbopen
> which is assigning the return value from tds_connect to the tds_socket
> member of *dbproc, this will dump core every time.
>
> Hope this is useful.
>
>





Archive powered by MHonArc 2.6.24.

Top of Page