On November 2, 2001 11:45 am, Ann W. Harrison wrote:

> At 07:24 PM 11/1/2001 -0700, Brad Pepers wrote:
> >I'm still trying to track down then why it doesn't work. I'm using Linux
> >(Mandrake 8.0) and the Classic version of Firebird.
>
> That's interesting. The classic version comes in two modest
> varieties. One creates a new gds_inet for each incoming connection.
> That process uses the libgds.so to access the database - each client
> being a separate process. The other variant creates a server -
> eventually a set of servers - which support several clients. My
> guess is that the build you're using follows that model. Could you
> verify that?

How do I verify this?

> I believe the problem with local connections occurs only on Windows
> where there is a "special" memory transport mechanism that was grafted
> on at some point.

Ok so even local connections with threads should work on Linux? Good to know
but not a worry right now since I always treat even local connections as
remote.

> >The error has also happened at other times in isc_sql_execute2 as well as
> >isc_dsql_fetch so its not localized to isc_dsql_allocate_statement.
>
> Right. It wouldn't be. It looks as if pthread_getspecific (specific_key)
> is returning a thread context that doesn't have a prior context (or no
> context at all) and the reference to current_context->thdd_prior_context
> blows up. Interesting.

I compiled the latest CVS sources as a debug version and what I found was
that the error was that current_context returned by THD_get_specific() in
THD_restore_specific is null so the next line that uses the current context
to get the thdd_prior_context is referencing a null.

So the question is just how THD_get_specific can return NULL. Is it a set of
mismatched code somewhere else? The THD_put_specific acts like a push and
the THD_restore_specific like a pop so if these are not matched somewhere in
the code, you could get too many pops. Or is it a race condition that just
takes tons of concurrent client requests to show up?

I found another small thing when looking at the code. The THD_cleanup code
does a --initialized even though everywhere else initialized is treated as
just a thrue/false value and *not* a count of uses. The code in THD_cleanup
should just be setting initialized to FALSE rather than pretending its a
reference count or something.

Has anyone else tested with multiple threads hitting the database constantly
like I am?

--
Brad Pepers
brad@...