pthread_spin_init used incorrectly
Brought to you by:
subes
The function pthread_spin_init is invoked inside JXGrabKey.cpp with its second argument spelled out as NULL -- a pointer. That is incorrect, the second argument must be an integer and clang, for example, issues a warning.
More importantly, the NULL translates into 0, which means PTHREAD_PROCESS_PRIVATE. Whether the constant is the original NULL, or 0, or PTHREAD_PROCESS_PRIVATE, the bundled self-tests hang in a tight loop -- with the testing java-process eating up one entire CPU.
Using PTHREAD_PROCESS_SHARED (the only other legal value for the flag) allows self-tests to run to completion properly. Please, evaluate the below patch -- I do not know the API well enough...
--- JXGrabKey/C++/src/JXGrabKey.cpp 2010-02-28 10:11:49.000000000 -0500
+++ JXGrabKey/C++/src/JXGrabKey.cpp 2016-06-30 03:15:41.718599000 -0400
@@ -319,5 +320,5 @@
XSetErrorHandler((XErrorHandler) xErrorHandler);
- pthread_spin_init(&x_lock, NULL); // init here bcoz of the returns
+ pthread_spin_init(&x_lock, PTHREAD_PROCESS_SHARED); // init here bcoz of the returns
doListen = true;
Thanks for the report. This might be due to some class sharing magic the newer JVMs include. Otherwise cannot explain why PTHREAD_PROCESS_PRIVATE should not work. Committed in Trunk, feel free to build a new release for yourself via the included ant build.xml in the misc folder.
Actually, trying to build (and test) it now on CentOS-6 (with OpenJDK-1.8) I observe the same hang in the test as I saw last night here. Changing the flag from
PTHREAD_PROCESS_SHAREDtoPTHREAD_PROCESS_PRIVATEand back does not seem to make a difference:It seems, there is a race somewhere... Once fixed, we may be able to go back to
PTHREAD_PROCESS_PRIVATEas before...Update: same problem on CentOS-7.2... Maybe, that's because I'm running test over ssh-forwarded
DISPLAY(across considerable distance)?Last edit: Mikhail T. 2016-06-30