Recurrent segmentation fault
The program keeps crashing due to a segmentation fault. It was previously crashing due to the rendered issue described in #1061, however I began to set GSK_RENDERER=gl whenever I opened the app and it solved this problem. However, I am now getting a recurrent segmentation fault, as can be seen in the screenshot below.
To Reproduce
Steps to reproduce the behavior:
- Run the program via terminal with
GSK_RENDERER=gl rnote - Use it for a while
- Expect for the apparently random, but almost certain crash.
Expected behavior
Run without issues (and preferably without having to set GSK_RENDERER manually, like Doublonmousse/rnote@215a68e).
Screenshots
Desktop (please complete the following information):
- OS: Arch Linux x86_64
- App Version: Rnote 0.10.2-1
- Installation Source: Archlinux Community Repo
- Desktop Environment: GNOME 46.2
- Display Server: Wayland
- Input Source: Laptop Touchscreen (Galaxy Book 2 pro 360)
Does it segfault as soon as the Broken accounting message appear ?
Can you give me the version of gtk4 installed ?
Given that gnome 46.2 is pretty new it may be a new gtk-related bug. There's another broken accounting issue (#1093) but it did not create segfaults.
Can you long press on the canvas with your finger to check if the right click menu appears (or broken accounting messages appear) ?
I'll test on my side if I can reproduce things on the latest gtk version (I think it'd be 4.14.4-2)
Hi, I haven't had much time to keep up with this issue as I was in the end of my College's semester and had all my finals in one week :sweat_smile: . I'll try to investigate as much as I can here, but I've honestly not used the app for a while, since I was mostly reading my notes in the PDFs I exported.
As of right now, my GTK is in version 4.14.4, as can be seen in the image attached:
I don't have time to give bug reports. I don't have a keyboard for my tablet, so it would be extremely tedious. But I think I might be having this issue. When I am using the latest Fedora Workstation with GNOME DE on wayland, the app crashes after several seconds of drawing. I didn't see anything about segfault in the debug log. When I switch to Phosh, it does not crash. I am using a first-gen Surface Go without the surface kernel.
@LSeelig Are you launching it with GSK_RENDERER=gl rnote ? If not it's probably #1061
@LSeelig Are you launching it with
GSK_RENDERER=gl rnote? If not it's probably #1061
I'll check on that. But I am not using any env vars
Can you check again on 0.11 ? Might be a gtk issue that's fixed in 4.14
I have the same problem with my Wacom tablet on Hyprland with rnote v0.11 and gtk4 v4.14.4 (with OpenTabletDriver v0.6.4.0). GSK_RENDERER=gl doesn't seem to have any effect.
For me, the problem only occurs in the "Artist Mode" of the OpenTabletDriver (which provides pressure-detection; without it -- the linewidths do not depend on how strongly you press the stylus). Picking the "Absolute Mode" (without any pressure-detection) seem to work ok -- I was able to use rnote for quite a long time without crashes.
Can you check again on 0.11 ? Might be a gtk issue that's fixed in 4.14
I haven't really used the app all that much recently as I'm on vacation now, but I did try it a couple times and I haven't found this issue again.
I can confirm it properly once my classes come back next month, but as of right now it seems fixed.
Well, my classes are back now and I've been using the app again for a little over 2 weeks now. What I can say for sure: the app is still crashing and giving the same segmentation fault.
I haven't had the time to investigate the issue properly, but from my usage I noticed some things:
1. It seems to be somehow related to the palm rejection.
I noticed in some of the crashes that the following sequence of events is very common:
- I write with my hand touching the screen as little as possible.
- I get tired from writing and start to rest my hand on the screen a little while still writing.
- The screen "freezes" and stops responding to my inputs, both with pen and finger.
2. Saving the file manually before it fully crashes can prevent it
Well, this is where it gets weird to me.
After a couple of these crashes, I started to notice the freezing before it fully crashed and closed the window. So, during one of my classes the following happened:
- I saved the file before I even wrote anything on it so that it would at least have the automatic saving enabled and I wouldn't lose the entire lesson when it crashed (notice that it isn't a matter of if it crashes anymore, but when).
- I wrote my notes for a while.
- The app "froze".
- I tried desperately to click the save button.
- It actually worked! The app recovered and didn't crash.
- A message "the opened file was modified on the disk" showed up.
- The app continued to work normally.
After that, every time I noticed the app stopped responding, I clicked the save button manically and it somehow saved it every single time!
So, from this I learned that it wasn't the entire window that was freezing (hence my use of "" on the times I mentioned it before). Instead, only the canvas stopped responding, the rest of the window was still fine.
I don know if any of this information helps at all and I could even be mistaken (specially on the palm rejection thing, that's honestly more of a feeling I have), but I hope it helps. I will try to investigate it a little more if I have he time, but for now that's all I have.
I have the same problem with my Wacom tablet on Hyprland with
rnotev0.11 andgtk4v4.14.4 (withOpenTabletDriverv0.6.4.0).GSK_RENDERER=gldoesn't seem to have any effect.For me, the problem only occurs in the "Artist Mode" of the
OpenTabletDriver(which provides pressure-detection; without it -- the linewidths do not depend on how strongly you press the stylus). Picking the "Absolute Mode" (without any pressure-detection) seem to work ok -- I was able to usernotefor quite a long time without crashes.
Does it immediately fail when using the pressure level ? It may be an issue somewhere in the chain that triggers a segfault at that line : https://github.com/flxzt/rnote/blob/fbd056cde41a24c1d0b25dbeebc06893611661f5/crates/rnote-ui/src/canvas/input.rs#L393 If it's the case this means that gtk4 never populates the field (probably a null pointer ...)
Does libinput debug-events show the pressure level ?
@LSeelig Are you launching it with
GSK_RENDERER=gl rnote? If not it's probably #1061I'll check on that. But I am not using any env vars
Can you check whether this happens on 0.11 (and with the same symptom and workaround as https://github.com/flxzt/rnote/issues/1131#issuecomment-2342434366) ?
@lucas-yotsui From what you're describing, my guess is that it does not matter which button you click that isn't the canvas itself. Probably has to do with some gesture handlers somewhere (in similar ways to https://github.com/flxzt/rnote/commit/4c33594f57c3c384302f514cc7b7a76715ebb115).
Now I'm not sure which one. At least that can be tested (disable some or all of them, test, and go from there)
I struggle with the same or a very similar issue. The app segfaults or freezes very often (about every 20 minutes). Manually saving the file, can in fact, sometimes prevent the crash, but that has not been very constant for me. I am open to running tests on my machine, if you need it.
OS: NixOS App Version: Rnote 0.11.0 Installation Source: Nixpkgs unstable Desktop Environment: Hyprland Display Server: Wayland Input Source: Laptop Touchscreen (Lenovo Thinkpad 2-in-1)
Well, it turns out, I was wrong. The segfaults no longer occur in the version 0.11 of rnote (it used to crash on 0.10.2). However, a very similar and potentially related problem is persistent. The app keeps permanently freezing in seemingly random moments. Should I file a separate issue?