GoogleCodeExporter
commented
8 years ago Are you comping your self or using the binary provided?Original comment by a...@1stleg.com on 23 Sep 2012 at 9:05
- Changed state: Accepted
Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago Are you comping your self or using the binary provided?Original comment by a...@1stleg.com on 23 Sep 2012 at 9:05
GoogleCodeExporter
commented
8 years ago Sorry, I forgot to mention that: I am using the binary, version 1.1.0Original comment by simon....@gmail.com on 24 Sep 2012 at 12:14
GoogleCodeExporter
commented
8 years ago And if it helps, I have used 1.0.2288 before that and it worked pretty well (no
errors or crashes).Original comment by simon....@gmail.com on 24 Sep 2012 at 12:15
GoogleCodeExporter
commented
8 years ago I took a look though the code and found a few problems, but I doubt that any of
them caused this problem.
I have attached jar with debugging enabled. It should output a lot of
information to the console and support gdb. If you can please run the jar from
the terminal and keep track of the output by keeping an eye on it or by
redirecting stderr to a file (Ex java -jar JNativeHook.jar 2>./error.log)
If you have gdb installed it would really help to monitor the jni process id.
You can accomplish that by running the following commands in a terminal
ps aux | grep java
gdb -p <PID>
Where <PID> is the first number from the left, right after your account name.
Wait for a while. Type continue at the (gdb) prompt. After it crashes type
backtrace to get some useful information.
Original comment by a...@1stleg.com on 28 Sep 2012 at 3:58
Attachments:
GoogleCodeExporter
commented
8 years ago Have you been able to reproduce the problem? I have run a battery of tests for
the past 3 days without any stability issues.Original comment by a...@1stleg.com on 4 Oct 2012 at 3:38
GoogleCodeExporter
commented
8 years ago Sorry, I haven't been able to test the debugging jar yet. I am kind of busy
with other stuff at the moment, so it might take a few more days until I can
give it a try. I will post a comment when I tested it.Original comment by simon....@gmail.com on 4 Oct 2012 at 12:43
GoogleCodeExporter
commented
8 years ago No problem, take your time. I just cant seem to produce any instability on my
test systems which leads me to believe the problem maybe caused by the
interaction with something on your system. Let me know when you have a chance
to test. Thanks again.Original comment by a...@1stleg.com on 6 Oct 2012 at 6:13
GoogleCodeExporter
commented
8 years ago I have this issue too nowOriginal comment by silverar...@kingsleys.org on 26 Oct 2012 at 12:56
GoogleCodeExporter
commented
8 years ago [deleted comment]I really need a fix by tomorrow, cus i need to finish this for a deadline, my
log is attached, plz reply soon.Original comment by silverar...@kingsleys.org on 26 Oct 2012 at 2:01
Attachments:
GoogleCodeExporter
commented
8 years ago I have been unable to duplicate this problem after extensive testing. What
versions have you tried? Is this occurring with 1.1.1?
Do you have steps to consistently produce the crash?
Can you provide more detailed crash information?
What happens before and after "IsNativeThreadRunning(): Failed to acquire
control mutex lock!"?
Does it crash the JVM? If so, did you find a crash report?
Can you attach gdb to the process for additional information? Original comment by a...@1stleg.com on 26 Oct 2012 at 4:36
GoogleCodeExporter
commented
8 years ago I will be on google talk at my email address and #JNativeHook@chat.freenode.net
all day. It will probably be faster to discuss the problem live.
Original comment by a...@1stleg.com on 26 Oct 2012 at 4:54
GoogleCodeExporter
commented
8 years ago Ok, I finally got to test with the debugging jar and also with the latest
release (1.1.1). I could reproduce the issue with both versions. I have
attached a gdb backtrace as well as the debugging output of the provided jar
(it has about 3000 messages, however, most of it is just me pressing keys and
moving the mouse until the problem occurs; I have not removed anything, so this
is all I got). There are a few things I have noticed:
- As soon as the "Exception detected while handling key input." and "TSMProcessRawKeyCode failed (-192)" messages start to occur, no keyboard input is possible in my application anymore, even though I am not using JNativeHook for that, just plain Swing components. Strangely, the backspace key still works!
- The crash (due to a null pointer) only happens when I finally try to close my swing application. The program/JVM does not crash on its own (at least I did not see this during my tests).
- The backtrace is pretty much the same I get from the Mac OS X crash report (see the crashed thread's stacktrace in my original report).
I am currently using version 1.0.2288 as a fallback and it works perfectly
without any issues (so, silverarrow2301, you might use this version instead;
the API has changed slightly, but really simple to replace).Original comment by simon....@gmail.com on 26 Oct 2012 at 7:27
Attachments:
GoogleCodeExporter
commented
8 years ago Does this error occur if eclipse is not running? Based what you have provided
it looks like something outside of JNativeHook is crashing. It maybe caused by
JNativeHook but the crash occurs elsewhere.Original comment by a...@1stleg.com on 26 Oct 2012 at 7:47
GoogleCodeExporter
commented
8 years ago I have done extensive testing with eclipse and other applications and I still
cannot trigger this error. I am fairly confident that this error is not
occurring in JNativeHook, and if the library is even involved, it is causing
another application to crash (JVM?). The only good news in this whole thing is
that IF the library is involved I believe it has something to do with the key
typed events. I have attached a build with extensive output around the key
type native code so I can try and get a better idea of where and possibly why
the code is causing a crash. I did plug a small memory leak but I doubt it
would cause the error you are seeing. I am not sure what else to do as the
stack trace and error logs are not really giving me much to go on.
The only thing reason I can think of as to why I cant reproduce this error is a
setting or something corrupt in /Library/Caches or ~/Library. Some people
reported /Library/Caches/com.apple.IntlData* being corrupt as the cause of this
type of error. If you have some extra type take a look for
/Library/Caches/com.apple.IntlData*. If you don't have anything suspicious in
/Library/Caches try creating a new user account and testing with that user.
That should give you a fresh ~/Library location. If you cannot duplicate the
error with the new user start copying over the folder from your original user
to the ~/Library location until the crash occurs. I am guessing its probably
something with the preferences keyboard layout or input methods, so start there.Original comment by a...@1stleg.com on 26 Oct 2012 at 10:51
Attachments:
GoogleCodeExporter
commented
8 years ago Sorry to cause you so much trouble, but the problem still occurs, no matter if
I start my application
- from within Eclipse
- from the command line
- from the command line using a fresh user account
I created a new user account as you suggested and the only thing I did was
copying my java application to its home directory, so I could do some testing
there. I checked the /Library/Caches as well as ~/Library for the mentioned
com.apple.IntlData*, but there is no file of that pattern.
Using the latest debug jar, I could reproduce the error using the new user
account and got this for every key I pressed when it still worked fine:
LowLevelProc(): Calling KeyCodeToString(38, 0x0)
KeyCodeToString(): Calling TISCopyCurrentKeyboardLayoutInputSource()
KeyCodeToString(): Return TISCopyCurrentKeyboardLayoutInputSource()
KeyCodeToString(): TISCopyCurrentKeyboardLayoutInputSource() is OK!
KeyCodeToString(): Calling TISGetInputSourceProperty(...)
KeyCodeToString(): Return TISGetInputSourceProperty(...)
KeyCodeToString(): TISGetInputSourceProperty(...) is OK!
KeyCodeToString(): Calling UCKeyTranslate(...)
KeyCodeToString(): Return UCKeyTranslate(...)
KeyCodeToString(): UCKeyTranslate(...) is OK!
KeyCodeToString(): Calling CFStringCreateWithCharacters(...)
KeyCodeToString(): Return CFStringCreateWithCharacters(...)
KeyCodeToString(): Calling CFRelease(keyboard_ref)
KeyCodeToString(): Return CFRelease(keyboard_ref)
LowLevelProc(): Return KeyCodeToString()
LowLevelProc(): Calling CFStringGetLength(...)
LowLevelProc(): Return CFStringGetLength(...)
LowLevelProc(): Calling CFRelease(keytxt)
LowLevelProc(): Return CFRelease(keytxt)
LowLevelProc():
When it started to fail, it produces the following messages for every key
pressed:
LowLevelProc(): Calling KeyCodeToString(38, 0x0)
KeyCodeToString(): Calling TISCopyCurrentKeyboardLayoutInputSource()
KeyCodeToString(): Return TISCopyCurrentKeyboardLayoutInputSource()
KeyCodeToString(): TISCopyCurrentKeyboardLayoutInputSource() is OK!
KeyCodeToString(): Calling TISGetInputSourceProperty(...)
KeyCodeToString(): Return TISGetInputSourceProperty(...)
KeyCodeToString(): Calling CFRelease(keyboard_ref)
KeyCodeToString(): Return CFRelease(keyboard_ref)
LowLevelProc(): Return KeyCodeToString()
LowLevelProc(): Calling CFStringGetLength(...)
LowLevelProc():
2012-10-27 13:59:32.513 java[12199:1707] Exception detected while handling key
input.
2012-10-27 13:59:32.514 java[12199:1707] TSMProcessRawKeyCode failed (-192)
2012-10-27 13:59:32.553 java[12199:1707] TSMProcessRawKeyCode failed (-192)
So, it seems to have something to do with CFStringGetLength or maybe
KeyCodeToString? It might also explain why any non-visible key (backspace,
arrow keys) still work.
Again, it does not crash the application/JVM immediately, only when I try to
close it by clicking the red button on my app's window. I also had one test
run, where it did not crash at all after key input stopped working, but I could
not reproduce it. So I think the crash is not the main issue here, as it only
occurs when Swing or the native toolkit behind it tries to free its resources
(I guess).
Also, note that when the errors start, JNativeHook still delivers key events
just fine, only Swing does not get any input. Other applications also still get
key input and JNativeHook processes those inputs fine. Seems to be something in
combination with Swing/AWT.Original comment by simon....@gmail.com on 27 Oct 2012 at 12:34
GoogleCodeExporter
commented
8 years ago Oh, and to make sure its nothing to do with my application or some other jars
used by it, I also could reproduce the issue with just starting the
JNativeHookDemo from the jar itself (java -jar JNativeHook.jar).Original comment by simon....@gmail.com on 27 Oct 2012 at 12:36
GoogleCodeExporter
commented
8 years ago Thanks Simon! That output was really helpful. I am going to dig though it
today probably have a fix by this afternoon.Original comment by a...@1stleg.com on 27 Oct 2012 at 3:37
GoogleCodeExporter
commented
8 years ago So I have gone thought the code in question and in theory the problem you are
having shouldn't be possible. Its almost like the pointer to the string
returned by KeyCodeToString() is getting eaten somewhere along the way. I have
fix the default value returned by the function and added some paranoid checking
as a stop gap for now. This should prevent crashes, however you will stop
receiving key typed events for an unknown length of time. More on that in a
minute.
Please test the attached jar and see if it continues to crash. The jar will
print 3 to 4 lines per key press. If you see a line that reads
"LowLevelProc(): keytxt is NULL, THIS SHOULD NOT BE POSSIBLE!" please let me
know.
For some reason, your system stops being able to acquire the input source
property for the unicode key layout. Ex:
TISGetInputSourceProperty(TISCopyCurrentKeyboardLayoutInputSource(),
kTISPropertyUnicodeKeyLayoutData) == NULL; I don't know why this would happen,
nor do I know how TISGetInputSourceProperty is implemented. The developer
documentation allude to the idea that I can retain the value returned by
TISGetInputSourceProperty instead of looking it up each time but typical of
Apples API docs, they make no reference as to how one should retain said
reference.Original comment by a...@1stleg.com on 27 Oct 2012 at 6:08
Attachments:
GoogleCodeExporter
commented
8 years ago It looks like the property kTISPropertyUnicodeKeyLayoutData only returns NULL
if there is no layout data, or if the layout data is KCHR. So either something
is disabling your keyboard layout or you have a legacy layout that is getting
set on the fly.
I will need to know if the latest jar stops the crash before I implement a more
permanent workaround.
Thanks for all of your help with the problem.Original comment by a...@1stleg.com on 28 Oct 2012 at 4:31
GoogleCodeExporter
commented
8 years ago I tested the latest jar and could reproduce the error, but did not get the
"keytxt is NULL..." message! This is what I have got by pressing the 'A' key
several times:
LowLevelProc(): Return CFStringGetLength(...) == 0x0x7fff7040b550
LowLevelProc(): Return CFStringGetLength(...) == 1
[... two such lines per key press ...]
LowLevelProc(): Return CFStringGetLength(...) == 0x0x7fff7040b550
LowLevelProc(): Return CFStringGetLength(...) == 1
LowLevelProc(): Return CFStringGetLength(...) == 0x0x11dbf8380
2012-10-28 20:14:38.054 java[13303:1707] TSMProcessRawKeyCode failed (-192)
LowLevelProc(): Return CFStringGetLength(...) == 0x0x11dbf8380
2012-10-28 20:14:38.157 java[13303:1707] Exception detected while handling key
input.
2012-10-28 20:14:38.158 java[13303:1707] TSMProcessRawKeyCode failed (-192)
2012-10-28 20:14:38.229 java[13303:1707] TSMProcessRawKeyCode failed (-192)
I really don't know what is going on there. The address (e.g. 0x7fff7040b550)
is unique for every distinct key, however, as soon as the error occurs, the
same address is shown for every key. If it helps, I am using the German
keyboard layout. I also tried switching to another layout (US), but that does
not seem to make a difference.Original comment by simon....@gmail.com on 28 Oct 2012 at 7:27
GoogleCodeExporter
commented
8 years ago I also tested it on a different Mac (MacBook Pro 13", mid 2010; mine is a
MacBook Pro 15", mid 2009) and got the same errors. However, both are running
Mac OS X 10.6.8, so it only means that it does not has anything to do with my
particular hardware or software configuration. Maybe Apple changed or fixed
something in later OS releases.Original comment by simon....@gmail.com on 28 Oct 2012 at 7:45
GoogleCodeExporter
commented
8 years ago Ok, I was finally able to reproduce a similar problem and I believe I know what
is causing the problem. The related documentation isn't particularly good so
I'm not sure how long it will take.Original comment by a...@1stleg.com on 29 Oct 2012 at 8:00
GoogleCodeExporter
commented
8 years ago Original comment by a...@1stleg.com on 29 Oct 2012 at 9:33
GoogleCodeExporter
commented
8 years ago I believe I have a workaround for this problem committed at revision 647.
Although the root cause of this error remains a mystery, I believe I have a
workaround to prevent the problem from occurring. I will attach a new jar
shortly. Please test and let me know so I can tag 1.1.2 and close the bug.
For anyone curious about this bug; best I can tell calling
TISGetInputSourceProperty(currentKeyboardLayout,
kTISPropertyUnicodeKeyLayoutData) repeatedly in short succession is causing a
null pointer exception somewhere in the JVM. There is no logical reason that
this would occur, yet the problem persists immediately after the
TISGetInputSourceProperty function returns a NULL value. It is possible that
this problem maybe resolved in Java 1.7 as previous version are known to
contain several bugs, however no testing was done to verify that assertion. If
anyone has any idea why this problem occurs or stumbles upon a definitive
solution, please let me know.Original comment by a...@1stleg.com on 30 Oct 2012 at 11:37
GoogleCodeExporter
commented
8 years ago Jar To Test, Thanks.Original comment by a...@1stleg.com on 31 Oct 2012 at 12:25
Attachments:
GoogleCodeExporter
commented
8 years ago I did my best to reproduce the bug with the latest jar, but it seems you have
done your job very well, as I could not get any error to occur.Original comment by simon....@gmail.com on 1 Nov 2012 at 8:37
GoogleCodeExporter
commented
8 years ago It turns out that this was also partially caused by what I believe was a thread
safety issue on platforms using POSIX threads, which current covers everything
except windows. The problems been resolved in the 1.1 branch and 1.1.2 should
be ready tonight. Thanks for all of the help testing.Original comment by a...@1stleg.com on 5 Nov 2012 at 9:52
GoogleCodeExporter
commented
8 years ago Original comment by a...@1stleg.com on 5 Nov 2012 at 9:53
Original issue reported on code.google.com by
simon....@gmail.comon 23 Sep 2012 at 7:00Attachments: