I am having this problem as well...Was there a solution. I am using
the .net data provider and many threads. I tried to create a small
test program to try and replicate this problem but am unable to.

--- In firebird-support@yahoogroups.com, "Ann W.
Harrison" <aharrison@...> wrote:

>
> At 03:58 PM 11/4/2001 -0700, Brad Pepers wrote:
>
> > > ... each client being a separate process. The other... a server
> > > which support several clients.
> >
> >How do I verify this?
>
> One what is to make three connections and count the number of
> processes created.
>
> >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.
>
> They should work in Classic. I don't know about superserver.
>
> >...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.
>
> Right, of course.
>
> >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 assume it's a race condition or we'd see it all the time. I

doubt that

> it's firebird specific, though if it were, it would be easier to

find.

>
> >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.
>
> Right. Sloppy.
>
>
> Regards,
>
> Ann
> www.ibphoenix.com
>