Issue Details (XML | Word | Printable)

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

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

Firebird 3 events broken

Created: 19/Apr/15 12:14 PM   Updated: 23/Sep/15 11:34 AM
Component/s: API / Client Library
Affects Version/s: 3.0 Beta 2
Fix Version/s: 3.0 Beta 2

File Attachments: 1. File CORE-4756.7z (842 kB)

Environment: Jaybird 2.2 branch (head), Jaybird 3.0 (trunk, head), fbclient.dll 3.0.0.31794 (64 bit) against Firebird server 3.0.0.31794 (64 bit)
Issue Links:
Relate
 


 Description  « Hide
I have several problems using events in both Jaybird 2.2 and Jaybird 3.0 when testing the native implementation in combination with a recent Firebird 3 fbclient.dll (3.0.0.31794). Depending on the exact test and timing, I get the following errors:

Unrecognized events block (335544973) when calling isc_que_events for the second time.
invalid events id (handle) (335545021) when calling isc_cancel_events

Adding extra pauses and delays sometimes seems to remove the error only to have it replaced by a different error. Running the same test multiple times can give different errors. Sometimes it also looks like the callback is triggered when no events have been raised.

When switching to the Firebird 2.5.4 fbclient.dll the problems go away.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 22/Apr/15 10:56 AM
Please provide test case

Mark Rotteveel added a comment - 22/Apr/15 11:04 AM
It can be reproduced with org.firebirdsql.event.TestFBEventManager when tests are run for native (on Windows 64 bit); I haven't tried 32 bit or linux yet. Given the current state of the events implementation in trunk, I'd suggest using the Jaybird 2.2 branch. As running the tests in native is a bit arcane, I'll add a more explicit reproduction script tonight or tomorrow evening.

Mark Rotteveel added a comment - 23/Apr/15 05:25 PM
It will have to wait until Sunday; sorry.

Mark Rotteveel added a comment - 27/Apr/15 08:07 AM
To reproduce with attachment: Windows 8.1 64 bit, Java 1.8.0_45 (on PATH), fbclient.dll of 3.0.0.31794-0_x64 installed.

Run from the root of the zip:
java -cp .\classes;jaybird-full-2.2.7.jar nl.lawinegevaar.fb.event.CORE4756

This causes a StackOverflowException that is triggered in the native code. This test is the equivalent of TestFBEventManager.testBasicEventMechanism; the other test in that class have similar problems. This is not exactly the same problem as I see in the new events implementation in Jaybird 3 (master), but I assume they are related (and I think it is better to compare/test this with a "known to work" implementation that has been largely untouched in the last 10 years than something new).

Alexander Peshkov added a comment - 28/Apr/15 02:09 PM
Mark, I can't test using windows therefore tried to reproduce on linux.
Exception is not reproduced. I get:
# java -cp ./classes:jaybird-full-2.2.7.jar nl.lawinegevaar.fb.event.CORE4756
Count: 0 (should be 1)
#

But twice it hanged, and what I see is hard to explain. Threaed is waiting on port sync mutex in isc_cancel_events(). That's OK, mutex is reported to be locked in queEvents, which is also OK. But thread which owns that mutex has nothing to do with firebird client, it contains:
#0 0x00007f4ef786cc18 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f4ef69ef53f in os::PlatformEvent::park(long) () from /opt/oracle-jdk-bin-1.8.0.45/jre/lib/amd64/server/libjvm.so
#2 0x00007f4ef69d8b45 in ObjectMonitor::EnterI(Thread*) () from /opt/oracle-jdk-bin-1.8.0.45/jre/lib/amd64/server/libjvm.so
#3 0x00007f4ef69dabf9 in ObjectMonitor::enter(Thread*) () from /opt/oracle-jdk-bin-1.8.0.45/jre/lib/amd64/server/libjvm.so
#4 0x00007f4ef6a8d14f in SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*) ()
   from /opt/oracle-jdk-bin-1.8.0.45/jre/lib/amd64/server/libjvm.so
For me it looks like pure java stack.

Just to add that mutex is always locked using RAII holder, i.e. when control flow is leaving queEvents in both normal return and after exception mutex should get unlocked.

One question - may be Java VM is doing something like thread context switch on the fly?

Mark Rotteveel added a comment - 28/Apr/15 06:32 PM
Calls from Jaybird into fbclient are made by Java threads, if a mutex is acquired but isn't released properly that might explain the fact that a Java thread is holding it. Note however that the above stacktrace seems to be from a Java synchronized block (on exit of that block if I am not mistaken). I am not exactly sure what you mean with "thread context switch on the fly", Java can and will reschedule threads, but Java threads themselves aren't multiplexed if that is what you mean.

Looking at QueCallback (acquiring mutex in constructor, releasing in setEvents), I wonder if there aren't ways the mutex might not be released, and looking at isc_que_events I find the difference between receiving a status with errors and catching an exception (whether events->release() is called or not) suspicious.

I will dust of my poor C or C++ skills to see if I can write a reproduction program that doesn't involve Java to further simplify this.

Alexander Peshkov added a comment - 29/Apr/15 10:37 AM
Mark, please don waste time with C - I will qucikly rewrite your sample myself.

Mark Rotteveel added a comment - 06/Jun/15 09:43 AM
No longer reproducible with Firebird-3.0.0.31855-0_x64