-
Notifications
You must be signed in to change notification settings - Fork 291
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
Pressing Caps Lock with electron-v76-darwin-x64 crashes Electron App with no errors #244
Comments
FWIW I can't reproduce, tested on latest Catalina 10.15.5 as well as High Sierra 10.13.6 in a packaged app using iohook 0.6.6, electron 8.4.0, node 12.13.0. Caps lock press causes no ill effect and keycodes seem to be detected the same whether caps lock on or off. |
Hey @marcelblum! Thanks for such a quick response! |
I've created a test case using one of Electron's "Simple Samples". To reproduce:
As noted in This app is identical to the one posted here, https://www.electronjs.org/blog/simple-samples, except:
Hope this helps-- |
Based on recent findings from #246, the issue only applies to when iohook is used in the main process. |
Thanks @marcelblum. I can confirm it doesn't crash when loaded in the renderer process. This seems to be a dup of #246. |
MY OS : Catalina (10.15.7) when focus on electron app and press caps lock then error occur. also I'm set webPreferences: {nodeIntegration: true}) but it can't work. so if you have any solution then please give me. |
Together with @gtluszcz we have been investigating these crashes, as they are a deal breaker for us. We have found, that the problem lays somewhere in this call specifically: iohook/libuiohook/src/darwin/input_hook.c Line 601 in 769daed
If you call this line, it doesn't crash immediately, though. The program continues normally. After some short period of time, the app crashes. I can only assume (with my limited macOS-APIs knowledge), that I've noticed there were some changes in this function in the original repo (https://github.com/kwhat/libuiohook/blob/1.2/src/darwin/input_hook.c#L588-L592), however these changes do not fix the issue. I've been able to reproduce this with:
I've used I can also reproduce using: const NodeHookAddon = require('../iohook/build/Debug/iohook.node')
NodeHookAddon.startHook((event) => {
if (event.type <= 5) {
console.log(event)
}
}, true) instead of requiring the |
@DCzajkowski If this is a use-after-free issue it is likely due to a thread safety problem which could explain why you are only seeing it on Electron. There is some questionable thread safety in the input_hook (see pthread_ methods) related to the main run loop context switching. Much of this process is completely undocumented by Apple and I honestly hate working with their platform so I doubt I will be putting in a whole lot of effort into tracking down this problem unless I can reliably reproduce it in a stand alone CLI program outside of Electron/Java or anything else. |
@kwhat this is absolutely understandable! I love macOS, but working with their "documentation" for these APIs was a terrible experience for me today. I smiled a few times reading your comments in the source though 😅
Unfortunately, I didn't manage to attach a debugger to the Electron process that would support native code debugging, if that's what you are after. To be honest I have no clue how to reproduce it in pure Node.
From what I've read, the source of all evil is the |
@DCzajkowski as I noted above a while back, the crash does not happen if you load iohook in the renderer process. I just tested it some more today after reading your post, left my packaged electron app open for several hours, hitting caps lock several times throughout, and no crash or misbehavior of any kind. |
@marcelblum Our use-case is to recognize key-presses in the system, not inside the Electron window. We even "disable" keyboard recognition when the Electron window is focused! This is because our app provides global, system-wide shortcut recognition (see https://github.com/quickwords/quickwords as an example of we are trying to achieve in our app). @kwhat something I forgot to mention. This happens only when the Chromium window of our Electron app is focused. In other cases, crashes do not happen. |
@DCzajkowski iohook can still detect global key presses even if you instantiate it in the renderer. And you could use |
@marcelblum I didn't know that. However, we are destroying all windows when they are closed. You know, we can fix this issue on our end by stopping/starting on focus/blur. We can also fork iohook and remove this "system" function entirely. However, this wouldn't be a fix for this #issue in general. :/ |
I agree that it is evil and really difficult to use. IIRC, I needed to use it because there was no C API for detecting CapsLock and some of the other NX_SYSDEFINED key information. I think it was this: https://developer.apple.com/documentation/appkit/nsevent/1528289-data1 It has been a very long time since I wrote it but there are some hacks like the following to try and work around using objc_msgSend. See: https://github.com/kwhat/libuiohook/blob/1.2/src/darwin/input_hook.c#L620-L625
I will try to duplicate it witch chrome running and see if I can get it to work. This code is in desperate need of a refactoring. You can always try building libuiohook without USE_OBJC. |
Well, I may have found a solution but I cant get it to compile locally because CMake suddenly cannot find Java despite my JAVA_HOME variable pointing right at it. This is what I waste most of my free time dealing with, not fixing bugs but fighting with sub-par tooling. |
I have indeed found a solution, it is going to take some time to fully implement but it stops the segfault for me in Java. |
Alright, I had some unexpected free time on Monday / Tuesday and was able to get a fix in PR #108. I still need to do some more work fixing up some of the per-processor defines and other minor things, but it seems pretty stable. I am not sure if this library will be migrating to my upstream or continue the fork. If you are going to fork, the lines of interest are R476-R560 and possibly a few more bits near the top of the file. The problem: Turns out this was related to the same random crashes the TIS keycode stuff was experiencing so I have it setup to run on the main runloop as long as you are on 10.6+. Fallback is kind of hacky for 10.5, but it works, doesn't require OBJC or the main runloop. Any code review would be appreciated. Let me know if there are any issues. |
@matthewshirley Do you have time to update libuiohook to version 1.2 ? thanks. |
Following 🙏 Same thing here and iohook can't be loaded renderer side on latest versions of Electron (non-context aware modules are not allowed on the renderer anymore). Thanks! |
Expected Behavior
Pressing of Caps Lock shouldn't crash an electron app
Current Behavior
Pressing Caps Lock with electron-v76-darwin-x64 crashes Electron App with no errors
Steps to Reproduce (for bugs)
Not so many steps TBH. The error reproduces right after I
import
orrequire
fromiohook
.Then start an electron app - click on it to put window on focus and just press Caps Lock. The app will crash with no issues and logs even in debug mode.
Your Environment
"iohook": "^0.6.5"
"electron": "^8.2.0"
,nodejs: 12.16.1
From my own debugging I found out that issue is definitely within native code somewhere:
this.load()
. Once I commented out code inload
method app wasn't crash anymore but hooks didn't work either.this._handler
method and place next code inside at the very beginning of the function to not perform any operation if it was Caps Lock.I saw the console printed
CAPS LOCK PRESSED
but app failed anyway so it's not because of handler logic.So that's why I decided it is somewhere in native code and just for MacOS as I wasn't able to reproduce the issue on Windows.
I'd be happy to hear from you guys and what I can do more in order to have further steps.
Thank you.
The text was updated successfully, but these errors were encountered: