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 umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: DBD::Sybase main.t crash
  • Date: Wed, 25 Aug 1999 22:14:44 -0400 (EDT)




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