search

UmeshChoudhari / jnativehook

Automatically exported from code.google.com/p/jnativehook
0 stars 0 forks source link

Native hook does not resume after the PC sleeps. #38

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Run the included demo jar.  Everything works as expected.
2. Put the PC to sleep.  In KDE, I select "Sleep" from the kicker, but you can 
probably do it just as easily by closing your laptop lid.
3. Wake up the PC.  I hit any key to tell it to wake up.
4. Move the mouse and type something.  The demo window doesn't show any 
activity.
5. Uncheck the 4 checkboxes (listeners), then check the 4 checkboxes.  Still no 
activity.

What is the expected output? What do you see instead?
The native hook should continue reporting events, but it does not.  Please see 
the additional notes at the end.

What version of the product are you using? On what operating system?
Version 1.1.3, on Linux Mint 14

java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.4) (7u9-2.3.4-0ubuntu1.12.10.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

Please provide any additional information below.

In my application, I am able to detect a sleep event by comparing the 
timestamps generated by a periodic timer.  If the time difference is larger 
than expected, then I know the PC was sleeping.

Therefore I tried the following as a possible fix, when the program resumes:
1) GlobalScreen.unregisterNativeHook();
2) Wait for the timer to fire again (1 minute).
3) GlobalScreen.registerNativeHook();

The register call causes a fatal error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fadb7857f3a, pid=5417, tid=140383205574400
#
# JRE version: 7.0_09-b30
# Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 compressed 
oops)
# Problematic frame:
# V  [libjvm.so+0x548f3a]  
JNI_ArgumentPusherVaArg::JNI_ArgumentPusherVaArg(_jmethodID*, 
__va_list_tag*)+0xa

Thanks for your help!

Original issue reported on code.google.com by postmark...@gmail.com on 8 Feb 2013 at 3:43

GoogleCodeExporter commented 9 years ago 
I also tried re-registering without putting the PC to sleep.  It still causes a 
SIGSEGV fatal error.

Steps:

      GlobalScreen.registerNativeHook();

      GlobalScreen.getInstance().addNativeKeyListener(this);
      GlobalScreen.getInstance().addNativeMouseListener(this);
      GlobalScreen.getInstance().addNativeMouseMotionListener(this);

      ... do something else ...

      GlobalScreen.getInstance().removeNativeKeyListener(this);
      GlobalScreen.getInstance().removeNativeMouseListener(this);
      GlobalScreen.getInstance().removeNativeMouseMotionListener(this);

      GlobalScreen.unregisterNativeHook();

      try { Thread.sleep(1000); } catch (Exception e) { }

      System.err.println("reg hook...");
      GlobalScreen.registerNativeHook();
      System.err.println("Done rereg.");

I never see the "Done rereg" line.  It crashes after "reg hook...".

Original comment by postmark...@gmail.com on 8 Feb 2013 at 3:53

GoogleCodeExporter commented 9 years ago 
I can produce the segfault by simply starting and stopping the registration.  
When putting the computer to sleep, it looks like XRecord just stops for what 
ever reason.  The segfault will need to be addressed.  I am not sure if the 
stopping of XRecord can be fixed.  I will probably file another bug report 
upstream about the issue and see if it would be possible to implement a 
workaround.

0x00007f6864b8dbf0 in jni_CallStaticObjectMethod () from 
/opt/sun-jdk-1.6.0.39/jre/lib/amd64/server/libjvm.so                            

(gdb) bt                                                                        

#0  0x00007f6864b8dbf0 in jni_CallStaticObjectMethod () from 
/opt/sun-jdk-1.6.0.39/jre/lib/amd64/server/libjvm.so                            

#1  0x00007f6859768b5f in ThreadProc (arg=0x7f680401faa0) at 
/home/kwhat/NetBeansProjects/JNativeHook_1.1/src/native/unix/NativeThread.c:479 

#2  0x0000003059208ec6 in start_thread () from /lib64/libpthread.so.0           

#3  0x00000030586ea86d in clone () from /lib64/libc.so.6

Original comment by a...@1stleg.com on 11 Feb 2013 at 2:32

GoogleCodeExporter commented 9 years ago 
At least part of this bug is related to bug #37.  Can you test and see if it 
segfaults on any other platform besides linux?

Original comment by a...@1stleg.com on 11 Feb 2013 at 2:54

GoogleCodeExporter commented 9 years ago 
I run Windows at work, but I haven't been able to try it yet.  I haven't 
forgotten.

Original comment by postmark...@gmail.com on 13 Feb 2013 at 1:13

GoogleCodeExporter commented 9 years ago 
I am seeing the same behavior on Windows XP.  When I unregister and then 
register again, a dialog appears titled "Visual Studio Just-In-Time Debugger", 
and it says "An unhandled win32 exception occured in java.exe [5804].

Original comment by postmark...@gmail.com on 15 Feb 2013 at 6:38

GoogleCodeExporter commented 9 years ago 
hmm well I definitely broke something with the JNI.  I am pretty busy at the 
moment but I will try to get this fixed as soon as I can.

Original comment by a...@1stleg.com on 16 Feb 2013 at 3:32

GoogleCodeExporter commented 9 years ago 
I am 90% sure this is caused by the following line that is in the platforms 
thread proc:

// Destroy all created globals.
#ifdef DEBUG
if (DestroyJNIGlobals() == RETURN_FAILURE) {
    fprintf(stderr, "ThreadProc(): DestroyJNIGlobals() failed!\n");
}
#else
DestroyJNIGlobals();
#endif

If you want to patch and compile locally it should work.  I am doing a little 
restructuring to address part of bug #37 before I commit.

Original comment by a...@1stleg.com on 16 Feb 2013 at 4:43

GoogleCodeExporter commented 9 years ago 
Ok,I have tested on Linux x86_64 and restarting the hook seems to be working.  
I have attached a debug build for testing all platforms.  Please give it a try 
and let me know if it works for you with the sleeping/hibernating.

Thanks!

Original comment by a...@1stleg.com on 16 Feb 2013 at 5:56

Attachments:

GoogleCodeExporter commented 9 years ago 
Great job!  It doesn't crash any more (on my Linux box).

Sleep issue: re-registering immediately after waking up does not work.  It 
doesn't crash any more, but I don't receive events either.  Therefore I changed 
my code to wait approximately one minute, then re-register, and I start 
receiving events again!  Great! 

Thanks for looking into this. :-)

Original comment by postmark...@gmail.com on 17 Feb 2013 at 2:54

GoogleCodeExporter commented 9 years ago 
There is no reason that it shouldn't resume after sleeping.  I will leave the 
bug open with a lower priority until I can figure out why.

Original comment by a...@1stleg.com on 7 Mar 2013 at 12:52

GoogleCodeExporter commented 9 years ago

Original comment by a...@1stleg.com on 11 Mar 2013 at 11:15

GoogleCodeExporter commented 9 years ago 
Please re-test with 1.2.0-Beta1, thanks!

Original comment by a...@1stleg.com on 22 Jan 2014 at 7:26

GoogleCodeExporter commented 9 years ago 
Tested working as of Beta 2.

Original comment by a...@1stleg.com on 16 Apr 2014 at 11:48