Skip to Content.
Sympa Menu

freetds - RE: [freetds] tdsdump SIGSEGV with mt apps

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] tdsdump SIGSEGV with mt apps
  • Date: Tue, 17 May 2005 09:17:34 +0200

>
> > Once a query is sent to the server, the line is absolutely
> quiet until the
> > server answers (if ever). There is no interim message or
> heartbeat of any
> > kind.
> >
> > I don't understand why the stack would close the connection
> merely because
> > it's idle. A telnet session can stay up indefinitely without anyone
> > typing anything.
>
> Well, there have to be TCP keep-alives but this will happen
> transparent
> to the application, etc.
>
> Let's assume for now that based on this information about how
> the protocol
> works, a seperate network timeout is not required.
>
> In this case, select needs to be populated with query_timeout. Do you
> want me to update the patch or do you want to do that Frediano?
>

I posted patch from CVS but I think it's easier for me to provide an
updated patch.

> > ISTM that a big lock in db-lib is OK. The db-lib
> "threading" model, if we
> > can call it that, is that threads may not share a dbproc. Mutual
> > exclusion, then, is required only when inter-process lists
> are maintained
> > (e.g.connection_list, as you mentioned). I haven't been
> able to look at
> > your code yet, but do I understand correctly from your
> postings that we
> > agree?
>
> Yes, I think we agree. I don't like the big lock model
> either, but until
> I (or someone else) does a partial re-write of dblib, I think
> it's the
> best solution.
>

I committed a week ago (or more) code for mutual exclusion of connection
list.

>
> > Are you using current CVS? Do you call dbexit while other thread are
> > processing data? Try to remove dbexit call with current
> CVS. Where does
>
> Of course not! That would most certainly result in a
> disaster. The version
> of FreeTDS I use currently is a heavily patched 0.63.
>

It's hard to discuss the same changes from two different trunks. Can you
post your patch. Why does 0.63 need a so heavy patch?
I think that dbexit can be update even to be called from multi-thread.
This at this library problem:
- library A use dblib
- library B use dblib
Both library
- dbinit
- connect
- select
- get reply
- close connection
- dbexit
Now program C use both library but it do not know that A and B use
dblib. Now it can happen that
- A call dbinit
- B call dbinit
- B connect
- A connect, select and close
- A call dbexit (that free all connection)
- B try to select... crash...
Not so fine. A solution is to count dbinit calls and decrement in dbexit
so when A call dbexit nothing happen.
This is why I also proposed a counter for context.

> >From memory, I saw crashes and corruption mostly during things like
> closing and opening dblib connections while other threads process
> queries on other untouched dblib connections. Obviously, each
> connection
> is protected by an application mutex. The underlying dblib routines
> modify connection_list and this will not work well with other threads
> access it without mutual exclusion.
>
> I don't think it's necessary to discuss this matter any further. I
> think we all agree that we need mutual exclusion and thread
> safety measures
> of one form of another in dblib. Let's concentrate on the solution.
>

Your patch has been partially committed to CVS. I'll try to reproduce
your problem.

> > your application hang inside dblib? I think that a solution
> is to use a
> > reference counter for tds_ctx. Increment while creating TDSSOCKET or
> > dbinit and decrement while destroying TDSSOCKET or dbexit.
>
> I disagree, I would say the right solution is a tds_ctx per DBPROCESS.
> That way, almost all the thread safety and mutual exclusion problems
> go away.
>

I agree this is a correct solution. I'll try to reproduce your problem.

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page