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: Bob Kline <bkline AT rksystems.com>
  • 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 18:01:10 -0500 (EST)


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.

--
Bob Kline
mailto:bkline AT rksystems.com
http://www.rksystems.com













Archive powered by MHonArc 2.6.24.

Top of Page