FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

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