Running fbserver.exe and fbembed.dll on the same computer (same session) with different locations for FIREBIRD_LOCK leads to deadlock because of fb_trace file [CORE4046]

[firebird-automations]

Submitted by: Martin Schwedhelm (schwedhelm_m)

1. Start fbServer with FIREBIRD_LOCK="C:\A"
2. Start client application which uses fbembed.dll with FIREBIRD_LOCK="C:\B"
3. Try to open a database in the client application via fbembed.dll.

The problem only occurs if the user has full rights. In my opinion the reason for that is the following code snippet:

TraceConfigStorage.cpp (line 101)

if (fb_utils::isGlobalKernelPrefix() ||
!pfnProcessIdToSessionId ||
pfnProcessIdToSessionId(GetCurrentProcessId(), &sesID) == 0 ||
sesID == 0)
{
filename.printf(TRACE_FILE); // TODO: it must be per engine instance
}
else
{
filename.printf("%s.%u", TRACE_FILE, sesID);
}

Without "fb_utils::isGlobalKernelPrefix()" everything works as expected, but I don't know if that could have side effects.

[firebird-automations]

Commented by: @dyemanov

Just as a side note, I hope you will never start different instances of your client application using different FIREBIRD_LOCK values, as otherwise you'll get a corrupted database.

[firebird-automations]

Commented by: @hvlad

I don't think Firebird support different LOCK directories for different instances at the same machine at the same time.
It allows to open same database using different lock tables and corrupt it.
Why do you need such configuration ?

As for the trace, i'd said it is more-or-less known limitation of current implemetation, not a bug.

[firebird-automations]

Commented by: Martin Schwedhelm (schwedhelm_m)

We need it to implement our server / client architecture. The server side uses fbserver, the clients use fbembed.dll.
Normally the clients are not installed on the same machine as the server but it should be possible.
(Server and client have different directorys to work with, so this should be no problem).

We'd like to change the FIREBIRD_LOCK value to point to our working directory, which we know the user has rights to write to.

If we don't change FIREBIRD_LOCK value, both instances write to the same trace file, isn't that a problem too?
As we don't need the trace feature it would be ok if we could disable it, but I found no way to do that.

[firebird-automations]

Commented by: @hvlad

> We need it to implement our server / client architecture. The server side uses fbserver, the clients use fbembed.dll.
> Normally the clients are not installed on the same machine as the server but it should be possible.
> (Server and client have different directorys to work with, so this should be no problem).
>
> We'd like to change the FIREBIRD_LOCK value to point to our working directory, which we know the user has rights to write to.

Just make it equal when client and server are on the same machine.

> If we don't change FIREBIRD_LOCK value, both instances write to the same trace file, isn't that a problem too?

No, it is not a problem. More, it is as designed - all instances used the same set of syncronization objects.
The only exception is when some instance have no enough privileges to use "global" set of objects.

> As we don't need the trace feature it would be ok if we could disable it, but I found no way to do that.

You can remove fbtrace.dll to disable ability to trace something, but trace configuration storage will be initialized despite of it.