I am experiencing reproducible segmentation faults (Signal 11) when using the ‘cursor-bin’ AUR package on CachyOS. The crash consistently happens when triggering the GitHub authentication workflow.
System Info:
- OS: CachyOS x86_64
- Kernel: 7.0.9-1-cachyos
- DE: KDE Plasma 6.6.5 (Wayland)
- GPU: NVIDIA RTX 2060
- Package: cursor-bin (3.5.17-1)
Symptoms:
- Running ‘coredumpctl gdb cursor’ shows: “warning: core file may not match specified executable file.”
- The crash occurs during IPC/sub-process spawning when clicking “Sign in to GitHub”.
- Troubleshooting ( --no-sandbox, --disable-gpu, --password-store=basic) failed to resolve the issue.
Request:
It appears to be an ABI mismatch between the AUR package’s dependency on ‘electron42’ and the system libraries on CachyOS. Has this been reported before, or is there a way to force a compatible electron version/environment for Cursor?
cscs 2
Hello and welcome,
Current repo electron is 42 (and electron provides electron42) ?
If you do not have it then you may need to update;
sudo pacman -Syu
And/or we could look at your current packages;
pacman -Qs electron
Thanks for the follow-up! Regarding your question: Yes, my system is fully updated, and electron 42 (providing electron42) is installed.
I have also received clarification from the Cursor team: The crash is caused by an ABI mismatch because the cursor-bin AUR package tries to link against the system-wide electron42, while the Cursor application itself expects electron39.
The issue is solved: Instead of trying to force/pin the system Electron version, I switched to the official Cursor AppImage distribution. Since the AppImage bundles its own compatible Electron runtime, the SIGSEGV crash during OAuth/GitHub authentication is completely gone, and everything is working perfectly now.
Thanks again for your support in investigating the packaging side!
cscs 4
As this was about cursor-bin AUR package then it really outside of the purview of Cachy and any issues would be better aimed there .. where there is already discussion of this issue*;
Then the package should depend on electron39.
electron39 is in the repositories.
I guess that works too.
If you are happy with the AppImage then that is of course a fine resolution.
* - It is deeper than just he existence of electron39.
Considering it uses some official Cursor .deb that results in libs/configs hardcoded for electron when they mean electron39 is an upstream problem.