double semaphore locking when query the monitoring tables during long fetches [CORE1330] #1749
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
|
Commented by: @AlexPeshkoff Yes, please attach test files. |
|
Commented by: Vitaly (v6y) This test for Linux only. Unpack and run "http://prepare.sh". It should create /tmp/testdb.fdb, table test with 100000 records in it and compile three executables - monquery, query and sema 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 vitaly-home Thu Jun 21 22:30:52 2007 vitaly-home Thu Jun 21 22:30:52 2007 vitaly-home Thu Jun 21 22:30:52 2007 vitaly-home Thu Jun 21 22:30:52 2007 |
Modified by: Vitaly (v6y)Attachment: test.mon.tgz [ 10420 ] |
|
Commented by: @AlexPeshkoff Confirm the bug for linux classic. |
Modified by: @dyemanovassignee: Alexander Peshkov [ alexpeshkoff ] => Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.1 Beta 2 [ 10190 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pcisarWorkflow: jira [ 12410 ] => Firebird [ 14888 ] |
Modified by: @pavel-zotovQA Status: No test |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: No test => Cannot be tested |
Submitted by: Vitaly (v6y)
Attachments:
test.mon.tgz
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
Commits: d8700f3
The text was updated successfully, but these errors were encountered: