Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firebird 3 events broken [CORE4756] #5060

Closed
firebird-issue-importer opened this issue Apr 19, 2015 · 13 comments
Closed

Firebird 3 events broken [CORE4756] #5060

firebird-issue-importer opened this issue Apr 19, 2015 · 13 comments

Comments

@firebird-issue-importer

Submitted by: @mrotteveel

Relate to CORE4794

Attachments:
CORE-4756.7z

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.

Commits: 488101c FirebirdSQL/fbt-repository@7391af9

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 19, 2015

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 22, 2015

Commented by: @AlexPeshkoff

Please provide test case

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 22, 2015

Commented by: @mrotteveel

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.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 23, 2015

Commented by: @mrotteveel

It will have to wait until Sunday; sorry.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 27, 2015

Commented by: @mrotteveel

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).

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 27, 2015

Modified by: @mrotteveel

Attachment: CORE4756.7z [ 12740 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 28, 2015

Commented by: @AlexPeshkoff

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?

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 28, 2015

Commented by: @mrotteveel

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.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 29, 2015

Commented by: @AlexPeshkoff

Mark, please don waste time with C - I will qucikly rewrite your sample myself.

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented May 16, 2015

Modified by: @mrotteveel

Link: This issue relate to CORE4794 [ CORE4794 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 6, 2015

Commented by: @mrotteveel

No longer reproducible with Firebird-3.0.0.31855-0_x64

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 30, 2015

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Beta 2 [ 10586 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 23, 2015

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants