Issue Details (XML | Word | Printable)

Key: CORE-1726
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Mark Liermann
Votes: 0
Watchers: 0
Operations

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

Failure in isc_service_start()

Created: 04/Feb/08 02:37 PM   Updated: 18/Nov/08 01:09 PM
Component/s: API / Client Library, Engine
Affects Version/s: 2.0.3
Fix Version/s: 2.1 RC2, 2.0.4, 2.5 Alpha 1

Time Tracking:
Not Specified

File Attachments: 1. File test.exe (1.91 MB)

Environment:
Windows XP sp2
IBPP Library version 2.5.3.1
--compiled with GCC 3.4.5

Firebird version WI-V2.0.3.12981 Firebird 2 Classic & Super Server installs
  fresh install for each version prior to running the test included with IBPP

Firebird installed to C:\DBSRV and a \data subdirectory created to process test data creation.


Target: 2.1 RC2, 2.0.4 and 2.5 Alpha 1
Planning Status: Unspecified


 Description  « Hide
When running IBPP test included with IBPP version 2.5.3.1 on Firebird 2.0.1.12981 Super Server the following error is displayed. If the same version of firebird is installed as a Classic Server, then the manage user functions are successful.


*** IBPP::SQLException ***
Context: Service::RemoveUser
Message: isc_service_start failed

SQL Message : -902
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements

Engine Code : 335544344
Engine Message :
I/O error for file "C:\DBSRV\security2.fdb"
Error while trying to open file
The process cannot access the file because it is being used by another process.

Engine Code : 335544344

===================================================================================
SUPER SERVER - test log file :

IBPP Test Suite (Version 2.5.3.1)

Test 1 --- Checking Date/Time (no DB involved)
           Now : Y=2008 M=2 D=4, 13:5:9
Test 2 --- Exercise empty database creation & connection
           Sync Writes is enabled (Safety).
           Use 'speed' command-line argument to test the other mode.
           ODS Major 11
           ODS Minor 0
           Page Size 8192
           Pages 140
           Buffers 256
           Sweep 5000
           Reserve true
Test 3 --- Exercise basic DDL operations and IBPP::Exceptions
Test 4 --- Populate database and exercise Blobs and Arrays (100 rows)
           Plan: PLAN (TEST NATURAL)
Press any key to continue . . .
Test 5 --- Cocktail of DML statements (100 rows)
Test 6 --- Service APIs
           WI-V2.0.3.12981 Firebird 2.0
           Shutdown...
           Validate...
           Restart...
           Sweep...
           Backup...
           Restore...
           Manage users
*** IBPP::SQLException ***
Context: Service::RemoveUser
Message: isc_service_start failed

SQL Message : -902
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements

Engine Code : 335544344
Engine Message :
I/O error for file "C:\DBSRV\security2.fdb"
Error while trying to open file
The process cannot access the file because it is being used by another process.

Engine Code : 335544344
Test 7 --- Mass delete, AffectedRows() Statistics() and Counts()
           Affected rows : 100
           Fetches : 1093
           Marks : 105
           Reads : 68
           Writes : 18
           Inserts : 0
           Updates : 0
           Deletes : 100
           ReadIdx : 89
           ReadSeq : 171
Test 8 --- Events interface
           Adding a trigger to the test database...
           Registering 200 events (!)
           Inserting 2 records, that should trigger 'INSERT' event...
           Commit...
           First immediate call to Dispatch()
           Sleeping 2 sec...
           Adding an event
           Second call to Dispatch()
           Inserting 3 records, that should trigger 'INSERT' event...
           Third call to Dispatch (commit not done)...
           *** Event INSERT triggered, count = 2 ***
           Now committing (events should only trigger after commit)...
           Series of 20 calls to Dispatch(),
           with a 0.050 sec sleep after each
           *** Event INSERT triggered, count = 3 ***

           Start new transaction, trigger the event, drop it then dispatch...
           You should see NO event trigger (else it would be a bug)
           Series of 20 calls to Dispatch(),
           with a 0.050 sec sleep after each

           Re-registering a same event again...
           You should see NO event trigger (else it would be a bug)


*** FAILED ***


==================================================================================
CLASSIC SERVER - test log file:

IBPP Test Suite (Version 2.5.3.1)

Test 1 --- Checking Date/Time (no DB involved)
           Now : Y=2008 M=2 D=4, 13:3:49
Test 2 --- Exercise empty database creation & connection
           Sync Writes is enabled (Safety).
           Use 'speed' command-line argument to test the other mode.
           ODS Major 11
           ODS Minor 0
           Page Size 8192
           Pages 140
           Buffers 256
           Sweep 5000
           Reserve true
Test 3 --- Exercise basic DDL operations and IBPP::Exceptions
Test 4 --- Populate database and exercise Blobs and Arrays (100 rows)
           Plan: PLAN (TEST NATURAL)
Press any key to continue . . .
Test 5 --- Cocktail of DML statements (100 rows)
Test 6 --- Service APIs
           WI-V2.0.3.12981 Firebird 2.0
           Shutdown...
           Validate...
           Restart...
           Sweep...
           Backup...
           Restore...
           Manage users
               
           All users : SYSDBA, EPOCMAN
           Expected 2 users connected, found 1.
           Connected users : SYSDBA
Test 7 --- Mass delete, AffectedRows() Statistics() and Counts()
           Affected rows : 100
           Fetches : 1100
           Marks : 105
           Reads : 77
           Writes : 18
           Inserts : 0
           Updates : 0
           Deletes : 100
           ReadIdx : 89
           ReadSeq : 171
Test 8 --- Events interface
           Adding a trigger to the test database...
           Registering 200 events (!)
           Inserting 2 records, that should trigger 'INSERT' event...
           Commit...
           First immediate call to Dispatch()
           Sleeping 2 sec...
           Adding an event
           Second call to Dispatch()
           Inserting 3 records, that should trigger 'INSERT' event...
           Third call to Dispatch (commit not done)...
           *** Event INSERT triggered, count = 2 ***
           Now committing (events should only trigger after commit)...
           Series of 20 calls to Dispatch(),
           with a 0.050 sec sleep after each
           *** Event INSERT triggered, count = 3 ***

           Start new transaction, trigger the event, drop it then dispatch...
           You should see NO event trigger (else it would be a bug)
           Series of 20 calls to Dispatch(),
           with a 0.050 sec sleep after each

           Re-registering a same event again...
           You should see NO event trigger (else it would be a bug)



 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Liermann added a comment - 04/Feb/08 02:42 PM
The following file, TEST.exe is the test sequence executable that I run.

test.exe scanned with AVG, certified virus free

The file is IBPP version 2.5.3.1
compiled using wxDevCpp 6.10.2 and GCC 3.4.5
  no difference compiling with GCC 3.4.2


Alexander Peshkov added a comment - 08/Feb/08 12:03 PM
An amazing fact - after using security database in sevrices it was never closed till first database detach. And it was no matter, was services manager already detached at that moment or not. Therefore, if normal database was detached before service manager, this bug showed itself.

Current fix is not complete - an additional check in jrd.cpp is needed to always avoid such failures, but keeping buggy services behavior is also not OK.

Alexander Peshkov added a comment - 13/Feb/08 08:12 AM
In pre-2.5 versions I've applied partial fix for this problem, which should be enough for versions which will not contain new features in the future.