Skip to Content.
Sympa Menu

freetds - Re: DBD::Sybase main.t crash

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds
  • Subject: Re: DBD::Sybase main.t crash
  • Date: Wed, 25 Aug 1999 22:49:0


Actually Mark, I have to take all this back. You are absolutely correct.
When DBD::Sybase sets the property it passes &imp_dbh....imp_dbh is a local
variable and is subsequently tossed. So, simply storing 'buffer' is wrong.
Now I'm mallocing space and memcpy()'ing the data in. In this case the
data is a pointer.

All the tests work except for autocommit, which hangs on 2....I'll look at
it tommorow :)

Brian

Everything should be in CVS shortly.

On 08/25/99, "Brian Bruns <camber AT umcc.ais.org>" wrote:
> On Wed, 25 Aug 1999, Mark Schaal wrote:
>
> > >
> > > Mark Schaal writes:
> > > > >
> > > > > Actually that's changed and checked in. I found the same
> > > thing...but I
> > > > > still get main.t to crash. That's against a Sybase 11.x server
> > > (the JDBC
> > > > > server at Sybase)
> > > > >
> > > > > Brian
> > > >
> > > > I think you should be saving the data in the buffer and not the
> > > buffer
> > > > itself. I could be wrong...
> > >
> > > I don't think so.
> > >
> > > I sort of figured that you only store the pointer to the buffer that
> > > is passed in, and it's length. Otherwise, when the app changes the
> > > data in that buffer it won't be reflected in the CS_USERDATA buffer.
> > >
> > > Michael
> >
> > <*sigh*> If only we had ctlib documentation.
> >
>
> I've got dblib/cslib/ctlib/server lib manuals :P
>
> Seriously, you can go to sybooks.sybase.com and all the manuals are on
> line, although sqml to html garbage they use is slow enough to drive you
> crazy.
>
> The doc states *buffer is 'user allocated data'. Although a little vague
> it seems to indicate that the user is responsible for keeping the data
> and releasing it...If I was at work I could test it fairly simply, just
> store it change it and then ask for it back.
>
> > I think I look at the incoming buffer as just a generic buffer that
> > may be reused, resized, or thrown away. That's why I think the data
> > in the buffer is the critical item. Also my intuition favors looking
> > at the CS_USERDATA as private so I wouldn't want the app to change it.
> > This should be analogous to setting, say, CS_USERNAME where you don't
> > want the app to change it without going through ct_con_props().
> >
> > It doesn't seem to make sense to pass in the length of the buffer if
> > all you store is the buffer's pointer.
> >
>
> Well its a multifunction function, so to speak. So whether buflen has any
> application to this property is debatable.
>
> > The alternative of storing the pointer and the length doesn't make
> > sense because the buffer length is never returned.
> >
> > So, those are my arguments. (Also my version didn't core dump, which
> > should count for something. :-) Maybe I'll change my mind tomorrow.
> >
> Okay, but if I store a CS_CONNECTION structure as USERDATA now I have two
> places in memory with different states if I copy it. That is, close one
> connection does it think its duplicate is still open? It gets messy.
>
> Anyway, the USERDATA stuff works...I get a valid address for the
> struct and it is intact...It crashes later in a seemingly unrelated way.
>
> > Adios,
> >
> > Mark
> > --
> > Mark J. Schaal Phone: (909)
> > 620-7724
> > TST On Ramp Fax: (909) 620-8174
> > System Administrator E-Mail:
> > mark AT tstonramp.com
> >




Archive powered by MHonArc 2.6.24.

Top of Page