Issue Details (XML | Word | Printable)

Key: CORE-1330
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Vitaly
Votes: 0
Watchers: 0
Operations

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

double semaphore locking when query the monitoring tables during long fetches

Created: 21/Jun/07 07:05 AM   Updated: 22/Sep/11 12:38 AM
Component/s: API / Client Library
Affects Version/s: 2.1 Alpha 1, 2.1 Beta 1
Fix Version/s: 2.1 Beta 2

Time Tracking:
Not Specified

File Attachments: 1. File test.mon.tgz (4 kB)

Environment: Debian GNU Linux 3.1, Debian GNU Linux 4.0


 Description  « Hide
I wrote a programm which in infinite loop makes the following actions: queries the monitoring tables, commits transaction and sleeps for a second than repeat it again.

Very often, when this programm already being runned, if I would run at least two procceses, connected to the same database and which made a long time fetches, everything is hanging and it is impossible even to make a new connection to this database. The reason is that operation "-1" performed twice to the "monitoring" semaphore and because its value already zero when trying to perform this operation second time, "semop" system call waiting till it (semaphore) becames nonzero. So the only way to solve this problem is to use some external programm to perfom opertion "+1" or remove at all this semaphore.

May be this is the Linux-specific bug, because I failed to reproduce it when server running on Windows

I can attach test-files If needed


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 21/Jun/07 08:49 AM
Yes, please attach test files.
One more question - may be you have something interesting in firebird.log?

Vitaly added a comment - 21/Jun/07 01:38 PM
This test for Linux only.

Unpack and run "prepare.sh". It should create /tmp/testdb.fdb, table test with 100000 records in it and compile three executables - monquery, query and sema
Than first run "monquery". After this, simultaniosly run at least two copies of "query" from another terminals. If you get "hanging" effect try to run "sema -s"

May be you will need to try it several times, because it can work properly for a time. The order is important: first should be "monquery," than at least two "query" with as short interval between starting as possible



"hanging" happens because of semop trying to perform "-1" operation with 0 valued semaphore, so there are no messages in fierbird.log at that time. After applying "+1" operation by means of the external programm, gettng error message "Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long" on console and records like that in firebird.log:

vitaly-home Thu Jun 21 22:30:52 2007
        Clump 8 at offset 1846: <c2><0c><00><00>


vitaly-home Thu Jun 21 22:30:52 2007
        Clump 12 at offset 1855: /home/vitaly/programms/C/myibase.new/tests/test.mon/monquery


vitaly-home Thu Jun 21 22:30:52 2007
        Clump 9 at offset 1920: <00><00><00><00>


vitaly-home Thu Jun 21 22:30:52 2007
        Clump 10 at offset 1929: <00><d4><00><00>*<ea>R/


vitaly-home Thu Jun 21 22:30:52 2007
        Clump 11 at offset 1942: <01><00><00><00>



Alexander Peshkov added a comment - 22/Jun/07 04:07 AM
Confirm the bug for linux classic.