Closed Integral-Tech closed 1 year ago
Version: 0.5.18
Could you please run Rnote using RUST_LOG=rnote=debug RUST_BACKTRACE=1 rnote
, reproduce the crash and then post the console output here? Maybe that contains a bit more details.
Could you please run Rnote using
RUST_LOG=rnote=debug RUST_BACKTRACE=1 rnote
, reproduce the crash and then post the console output here? Maybe that contains a bit more details.(rnote:49091): Gtk-WARNING **: 02:04:24.165: Unknown key gtk-modules in /home/integral/.config/gtk-4.0/settings.ini
(rnote:49091): Adwaita-WARNING **: 02:04:24.286: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead. 2023-03-31T18:04:24.367Z DEBUG rnote::app::imp > ... env_logger initialized zsh: segmentation fault (core dumped) RUST_LOG=rnote=debug RUST_BACKTRACE=1 rnote
Could you please run Rnote using
RUST_LOG=rnote=debug RUST_BACKTRACE=1 rnote
, reproduce the crash and then post the console output here? Maybe that contains a bit more details.
PID: 33276 (rnote)
UID: 1000 (integral)
GID: 984 (users)
Signal: 11 (SEGV)
Timestamp: Sat 2023-04-01 11:39:49 CST (9s ago)
Command Line: /usr/bin/rnote
Executable: /usr/bin/rnote
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-com.github.flxzt.rnote-0a36a8459fa14d899fc36ad51387f34b.scope
Unit: user@1000.service
User Unit: app-com.github.flxzt.rnote-0a36a8459fa14d899fc36ad51387f34b.scope
Slice: user-1000.slice
Owner UID: 1000 (integral)
Boot ID: 949f8a8aa7d9462d98940e42d4a9e2c4
Machine ID: 59dc10722cb14131a46229239fb25ddf
Hostname: IntegralPC
Storage: /var/lib/systemd/coredump/core.rnote.1000.949f8a8aa7d9462d98940e42d4a9e2c4.33276.1680320389000000.zst (present)
Size on Disk: 17.6M
Message: Process 33276 (rnote) of user 1000 dumped core.
Stack trace of thread 33276:
#0 0x00007f74a4416d9e gdk_event_get_event_type (libgtk-4.so.1 + 0x416d9e)
#1 0x00007f74a425ab67 n/a (libgtk-4.so.1 + 0x25ab67)
#2 0x00007f74a4140ca7 gtk_gesture_set_sequence_state (libgtk-4.so.1 + 0x140ca7)
#3 0x00007f74a414183f gtk_gesture_set_state (libgtk-4.so.1 + 0x14183f)
#4 0x000055f9349d1269 n/a (rnote + 0x213269)
#5 0x00007f74a5335210 g_closure_invoke (libgobject-2.0.so.0 + 0x14210)
#6 0x00007f74a53632f8 n/a (libgobject-2.0.so.0 + 0x422f8)
#7 0x00007f74a5353095 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32095)
#8 0x00007f74a5353324 g_signal_emit (libgobject-2.0.so.0 + 0x32324)
#9 0x00007f74a4494d0c n/a (libgtk-4.so.1 + 0x494d0c)
#10 0x00007f74a41413c8 n/a (libgtk-4.so.1 + 0x1413c8)
#11 0x00007f74a425cfee n/a (libgtk-4.so.1 + 0x25cfee)
#12 0x00007f74a425d21c n/a (libgtk-4.so.1 + 0x25d21c)
#13 0x00007f74a4494816 n/a (libgtk-4.so.1 + 0x494816)
#14 0x00007f74a417bacf n/a (libgtk-4.so.1 + 0x17bacf)
#15 0x00007f74a4274e8c n/a (libgtk-4.so.1 + 0x274e8c)
#16 0x00007f74a43bf6e0 n/a (libgtk-4.so.1 + 0x3bf6e0)
#17 0x00007f74a442fddc n/a (libgtk-4.so.1 + 0x42fddc)
#18 0x00007f74a535323c g_signal_emit_valist (libgobject-2.0.so.0 + 0x3223c)
#19 0x00007f74a5353324 g_signal_emit (libgobject-2.0.so.0 + 0x32324)
#20 0x00007f74a448d6fd n/a (libgtk-4.so.1 + 0x48d6fd)
#21 0x00007f74a43d37ae n/a (libgtk-4.so.1 + 0x3d37ae)
#22 0x00007f74a523053b g_main_context_dispatch (libglib-2.0.so.0 + 0x5a53b)
#23 0x00007f74a528d219 n/a (libglib-2.0.so.0 + 0xb7219)
#24 0x00007f74a522f1a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
#25 0x00007f74a4f653de g_application_run (libgio-2.0.so.0 + 0xdc3de)
#26 0x000055f934a8a59e n/a (rnote + 0x2cc59e)
#27 0x000055f93492b493 n/a (rnote + 0x16d493)
#28 0x000055f934a8d7c7 n/a (rnote + 0x2cf7c7)
#29 0x00007f74a3d34790 n/a (libc.so.6 + 0x23790)
#30 0x00007f74a3d3484a __libc_start_main (libc.so.6 + 0x2384a)
#31 0x000055f9348cccf5 n/a (rnote + 0x10ecf5)
Stack trace of thread 33286:
#0 0x00007f74a3e0b9df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f74a528d17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f74a522f1a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
#3 0x00007f74a066cfde n/a (libdconfsettings.so + 0x5fde)
#4 0x00007f74a525d315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33283:
#0 0x00007f74a3e0b9df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f74a528d17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f74a522f1a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
#3 0x00007f74a522f1f2 n/a (libglib-2.0.so.0 + 0x591f2)
#4 0x00007f74a525d315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33327:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33282:
#0 0x00007f74a3e110dd syscall (libc.so.6 + 0x1000dd)
#1 0x00007f74a52867b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
#2 0x00007f74a51fafb4 n/a (libglib-2.0.so.0 + 0x24fb4)
#3 0x00007f74a5261f9e n/a (libglib-2.0.so.0 + 0x8bf9e)
#4 0x00007f74a525d315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33331:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33329:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33334:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33326:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33333:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33330:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33335:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33356:
#0 0x00007f74a3e110dd syscall (libc.so.6 + 0x1000dd)
#1 0x00007f74a5286d03 g_cond_wait_until (libglib-2.0.so.0 + 0xb0d03)
#2 0x00007f74a51faf83 n/a (libglib-2.0.so.0 + 0x24f83)
#3 0x00007f74a51fb127 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x25127)
#4 0x00007f74a5262846 n/a (libglib-2.0.so.0 + 0x8c846)
#5 0x00007f74a525d315 n/a (libglib-2.0.so.0 + 0x87315)
#6 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#7 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33332:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33336:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33328:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33343:
#0 0x00007f74a3d93766 n/a (libc.so.6 + 0x82766)
#1 0x00007f74a3d95f90 pthread_cond_wait (libc.so.6 + 0x84f90)
#2 0x00007f74520c284c n/a (iris_dri.so + 0xc284c)
#3 0x00007f745210bc6c n/a (iris_dri.so + 0x10bc6c)
#4 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#5 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 33284:
#0 0x00007f74a3e0b9df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f74a528d17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f74a522fc7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
#3 0x00007f74a4f97d5c n/a (libgio-2.0.so.0 + 0x10ed5c)
#4 0x00007f74a525d315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f74a3d96bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f74a3e18d90 n/a (libc.so.6 + 0x107d90)
ELF object binary architecture: AMD x86-64
I installed Plasma and was able to narrow down the issue: it's caused by the "two finger long press" touch gesture. This might be a GTK/gtk-rs bug, but I will try to find a workaround.
I installed Plasma and was able to narrow down the issue: it's caused by the "two finger long press" touch gesture. This might be a GTK/gtk-rs bug, but I will try to find a workaround.
OK, thanks
Setting the state of the gesture in these callbacks is what's causing the segmentation fault. From what I can tell, the three finger swipe starts both the long press and the zoom gesture, and both end/are cancelled at the same time.
I think we can and should remove those lines, because both gestures are grouped, and the zoom gesture already claims and denies event sequences. Or because the long touch gesture doesn't claim event sequences, so it shouldn't deny them. Either way, I haven't noticed any issues after removing these callbacks; both gestures still work fine (multiple times too, i.e. they're properly denied (?)) and most importantly, the segmentation fault does not occur.
@flxzt what is your opinion on this? I don't know if this is the correct solution, since the documentation about gesture groups is a bit lacking from what I could find. I also got it working using set_sequence_state
, but that's deprecated in GTK4.
Setting the state of the gesture in these callbacks is what's causing the segmentation fault. From what I can tell, the three finger swipe starts both the long press and the zoom gesture, and both end/are cancelled at the same time.
I think we can and should remove those lines, because both gestures are grouped, and the zoom gesture already claims and denies event sequences. Or because the long touch gesture doesn't claim event sequences, so it shouldn't deny them. Either way, I haven't noticed any issues after removing these callbacks; both gestures still work fine (multiple times too, i.e. they're properly denied (?)) and most importantly, the segmentation fault does not occur.
@flxzt what is your opinion on this? I don't know if this is the correct solution, since the documentation about gesture groups is a bit lacking from what I could find. I also got it working using
set_sequence_state
, but that's deprecated in GTK4.
I think that's OK.
since the documentation about gesture groups is a bit lacking from what I could find
I have experienced the same, so my guess is as good as yours. I'll remove and test it a bit and report if that causes any other issues ( I remember a lock-up as described in the other GH issue).
BTW, the crash is exclusive to native/non-flatpak installations and happens on GNOME too, but it's not as easily reproducible as on Plasma (it still happened to me 6 times today while using the latest release). The potential fix above also seems to have stopped the crashes so far.
BTW, the crash is exclusive to native/non-flatpak installations and happens on GNOME too, but it's not as easily reproducible as on Plasma (it still happened to me 6 times today while using the latest release). The potential fix above also seems to have stopped the crashes so far.
If the potential fix above proved effective, would you like to committed the fix to the main branch?
@Kneemund okay, removing them works fine on Wayland, but on X11 I am getting a lock up where dragging the canvas is not possible any more after activating the long-press gesture. Removing claiming the sequence in the zoom gesture fixes that, but that in turn causes another issue: a jumping view after a zoom gesture is finished. Probabyl because the same sequence is then also handled in the drag gesture
Hm, I didn't try X11 yet. Instead of removing the callbacks, what about checking if the sequence which is passed to the callback (2nd or 3rd parameter) is claimed, and then denying that one specifically using set_sequence_state
? That also fixed the crashes on Plasma, and maybe it prevents the lock ups on X11. If that works, then the remaining and major problem would be that set_sequence_state
is deprecated (without a replacement, because programs aren't supposed to handle individual sequences IIRC).
Yep, this doesn't cause any lock ups on X11 and also fixes this bug:
self.touch_two_finger_long_press_gesture.connect_end(
clone!(@weak obj as canvaswrapper => move |gesture, event_sequence| {
if let Some(event_sequence) = event_sequence {
gesture.set_sequence_state(&event_sequence, EventSequenceState::Denied);
}
}),
);
self.touch_two_finger_long_press_gesture.connect_cancel(
clone!(@weak obj as canvaswrapper => move |gesture, event_sequence| {
if let Some(event_sequence) = event_sequence {
gesture.set_sequence_state(&event_sequence, EventSequenceState::Denied);
}
}),
);
Although I haven't tested it very extensively. And like I said, set_sequence_state
is deprecated...
(Using set_state
in the if block causes the same segfault.)
It is only deprecated wrt gtk5, and I believe that will have gestures reworked anyway so using it would be okay with me.
And it does prevent lock-ups on X11, so it seems to be the solution here. I'll merge #606 and then push a commit with this fix
Describe the bug On KDE Plasma + Wayland, Rnote crashes while swiping with three fingers down on the touchscreen.
To Reproduce Steps to reproduce the behavior:
Expected behavior Rnote should not crash.
Console Output
Desktop (please complete the following information):