Issue Details (XML | Word | Printable)

Key: CORE-1820
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Paul Reeves
Reporter: Vit Kanevsky
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

Bug in FB2.0 Setup. Setup program don't detect runned server.

Created: 03/Apr/08 07:42 AM   Updated: 22/Aug/16 06:51 AM
Component/s: Installation
Affects Version/s: 2.0.3
Fix Version/s: 2.1.0, 2.5 Alpha 1, 2.0.5

Environment: windows (probably all versions)

QA Status: Cannot be tested

 Description  « Hide
In case of installing firebird server (and probably all other of 2.0 family) with the option "Guardian controlling server" swithed off, setup program don't detect runned server and try to overwrite it, with an appropriate errors, while trying to rewrite fbserver.exe and all of DLLs.

Research shows:

Setup detect a runned server as here (Innosetup code fragment from original setup program):

function FirebirdDefaultServerRunning: boolean;
  Handle: Integer;
  mutex_found: boolean;
  result := False;

  //Look for a running version of Firebird 1.5 or later
  Handle := FindWindowByClassName('FB_Disabled');
  if ( Handle = 0 ) then
    Handle := FindWindowByClassName('FB_Server');
  if ( Handle = 0 ) then
    Handle := FindWindowByClassName('FB_Guard');

  if (Handle > 0) then
     result := True
  else begin
    mutex_found := CheckForMutexes('FirebirdGuardianMutex,FirebirdServerMutex');
    if mutex_found then
      result := true;

Researching of runned server by Handles.exe shows the next:
There are no window with class name FB_Disabled
There are no window with class name FB_Server
There are no window with class name FB_Guard
??? Why its scanned, I don't know ????

There are no named mutexes with names FirebirdGuardianMutex or FirebirdServerMutex.
So, setup procedure can't find runned server.

In case of installing firebird with guardian swithed on, mutex FirebirdGuardianMutex created and setup works good, but with the guardian switched off there are no thats mutexes.

There are 2 named mutexes in server FIREBIRD_CONNECT_MUTEX & firebird_trace_mutex.

Possible FIXes:
1. Check for mutexes FIREBIRD_CONNECT_MUTEX or firebird_trace_mutex in the setup procedure.
2. Create a named mutex FirebirdServerMutex in the server.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Paul Reeves added a comment - 03/Apr/08 08:49 AM
FB_Disabled, FB_Server, FB_Guard were all used in previous versions, which is why the test exists.

Testing for FirebirdServerMutex demonstrates a certain amount of optimism, considering this mutex has never existed.

However, the underlying problem is that this area has always been a bad hack. Neither InterBase before us, nor Firebird since has paid proper attention to this issue.

Now is probably not the best time to add a new mutex. FIREBIRD_CONNECT_MUTEX wont work, because it is actually declared as %s_CONNECT_MUTEX and there is no guarantee that the prefix will be FIREBIRD.

This leaves us with adding a test for firebird_trace_mutex. As the change only affects the binary installer there is a good chance we can get this into 2.0.4. Unfortunately it is not likely to be in the release candidate, which is currently in QA.

Dmitry Yemanov added a comment - 03/Apr/08 09:00 AM
firebird_trace_mutex is a debugging facility that can disappear in some future build, so it doesn't look like a good option. Also, this mutex exists in the client library as well, so the check could fail if some other version of fbembed.dll is loaded by a running application.

Dmitry Yemanov added a comment - 03/Apr/08 09:07 AM
Wouldn't it be better to rely on EnumProcesses + OpenProcess + GetProcessImageFileName?

Paul Reeves added a comment - 03/Apr/08 09:44 AM
Actually, it doesn't matter if firebird_trace_mutex disappears in a future version - the tests are version specific. But the fact that it is in the client library means it won't work.

I don't think that EnumProcesses + OpenProcess + GetProcessImageFileName is easily available within InnoSetup. They could be made available by making various declarations (heck, we could even create our own install.dll and declare it if we wanted to) but I'd rather keep things as simple as possible. It looks like the correct solution is to actually create the FirebirdServerMutex, although this will mean a change to the engine code.

Alternatively, how reliable is FIREBIRD_CONNECT_MUTEX? Doesn't this depend on a value in firebird.conf?

Dmitry Yemanov added a comment - 03/Apr/08 11:29 AM
FIREBIRD_CONNECT_MUTEX does depend on IpcName from firebird.conf. More tomorrow :-)

Dmitry Yemanov added a comment - 04/Apr/08 04:52 AM
OK, I agree to create a mutex named FirebirdServerMutex for v2.0.x and FirebirdServerMutexDefaultInstance for v2.1 and above.

Dmitry Yemanov added a comment - 04/Apr/08 05:01 AM
BTW, the script contains a bug for the result of FirebirdDefaultServerRunning. One its caller misses the Format1() call, thus causing "Firebird %s Version" to be printed.

Dmitry Yemanov added a comment - 04/Apr/08 05:27 AM
As the fix affects the server binaries, I'm not going to include the fix into the v2.0.4.