freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Michael Peppler <mpeppler AT peppler.org>
- To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
- Subject: Re: DBD::Sybase main.t crash
- Date: Thu, 26 Aug 1999 09:53:39 -0700 (PDT)
Mark Schaal writes:
> >
> > I think so. And it's similar to the dbsetuserdata() call in the DBlib
> > side. I think the explanation of the dbsetuserdata() functionality
> > (and teh deadlock example code that is included there) explains this
> > functionality well.
> >
> > In DBD::Sybase I definitely expect the buffer returned by the
> > CS_USERDATA property to be the same buffer that I passed in earlier -
> > its elements can change and the action I take in the server or client
> > callbacks depend on those values (typically whether to call a perl
> > callback from the C error handler or not).
> >
> > Michael
>
> Time to be more precise. The buffer in this case is a **imp_dbh_st.
> Do you really want to store the **imp_dbh_st, or just the *imp_dbh_st?
> By storing the contents of the buffer (*imp_dbh_st) you still get the
> changes to the actual imp_dbh_st, which I believe is what is desired,
> but you can't change that around to be some other $dbh.
>
> Clear? (as mud?)
Yeah. I got confused by the double indirection (as usual :-0)
Anyway - on linux I still core dump on the ct_connect(). The stack
trace gives me:
(gdb) bt
#0 strncpy (s1=0x8192929 "", s2=0x0, n=30) at ../sysdeps/generic/strncpy.c:37
#1 0x2abd9a21 in tds_set_server (tds_login=0x81928b0, server=0x0)
at login.c:68
#2 0x2abd5e27 in ct_connect (con=0x8127378, servername=0x81aabf8 "",
snamelen=0) at ct.c:167
#3 0x2abcbf1a in syb_db_connect ()
#4 0x2abcb75f in syb_db_login ()
#5 0x2abc89a9 in XS_DBD__Sybase__db__login ()
#6 0x8087b7e in Perl_pp_entersub ()
#7 0x80b162e in Perl_runops_standard ()
#8 0x8058e01 in perl_call_sv ()
#9 0x2abbea3c in XS_DBI_dispatch ()
#10 0x8087b7e in Perl_pp_entersub ()
#11 0x80b162e in Perl_runops_standard ()
#12 0x8058791 in perl_run ()
#13 0x8056bdb in main ()
So there seems to be an invalid strcpy going on here - note that I'm
not setting the server to anything, and expect the library to use the
contents of $DSQUERY or, if that is empty, 'SYBASE'.
I'll make a patch in a minute.
Michael
--
Michael Peppler -||- Data Migrations Inc.
mpeppler AT peppler.org -||- http://www.mbay.net/~mpeppler
Int. Sybase User Group -||- http://www.isug.com
Sybase on Linux mailing list: ase-linux-list AT isug.com
-
Re: DBD::Sybase main.t crash,
Brian Bruns, 08/25/1999
- <Possible follow-up(s)>
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/25/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/25/1999
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/25/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/25/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/26/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/26/1999
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/27/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/28/1999
- Re: DBD::Sybase main.t crash, Bill Tutt, 08/28/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/28/1999
- Re: DBD::Sybase main.t crash, Bill Tutt, 08/29/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/29/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/29/1999
Archive powered by MHonArc 2.6.24.