Segfault
nouwaarom opened this issue · comments
At random moments I get a segfault.
To Reproduce
- I don't know, it seems completely random
System:
- OS: Ubuntu 19.10
- Gummi version: 0.8.0
Other
I used gdb to capture a stracktrace.
[Debug] motion_do_compile ()
[Thread][Debug] Compile thread awoke.
(gummi:28751): Gtk-WARNING **: 11:58:44.918: Invalid text buffer iterator: either the iterator is uninitialized, or the characters/pixbufs/widgets in the buffer have been modified since the iterator was created.
You must use marks, character numbers, or line numbers to preserve a position across buffer modifications.
You can apply tags and insert marks without invalidating your iterators,
but any mutation that affects 'indexable' buffer contents (contents that can be referred to by character offset)
will invalidate all outstanding iterators
Thread 6 "motion" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe3fff700 (LWP 28763)]
0x00007ffff7a7900c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
(gdb) backtrace
#0 0x00007ffff7a7900c in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1 0x00007ffff7a7c8d9 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#2 0x00007ffff7a607fb in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#3 0x0000555555569aa7 in editor_grab_buffer (ec=ec@entry=0x5555563ade40)
at editor.c:383
#4 0x000055555557c296 in latex_update_workfile
(lc=lc@entry=0x555555baaec0, ec=ec@entry=0x5555563ade40) at latex.c:75
#5 0x000055555557cc58 in motion_compile_thread (data=0x555555897720) at motion.c:184
#6 0x00007ffff7eec111 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007ffff7198669 in start_thread (arg=<optimized out>) at pthread_create.c:479
#8 0x00007ffff70c0323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thanks for reporting. How long would you say it takes on average for a segfault to occur from the moment you start the program and load your document? I have not encountered this problem while developing this release, but given the severity of the problem, I will replicate your platform and investigate further.
Did you compile 0.8.0 yourself? If so, did you use the tarball/zip that is available on the 0.8.0 release as source? Does the GTK warning from your gdb log always show up when it crashes for you?
It really varies, sometimes I can work for ten hours at an end without this crash and sometimes it happens within half an hour. I think it occurs more often when I haven't saved the document for some time.
I compiled it myself, I built it from master.
Do you want me to test on the 0.8.0 tag?
Yes this gtk warning always shows up. If I do not run gummi in gdb it gets logged to the systemd journal and I see the error in journalctl.
No need - I reproduced and identified the issue. Little busy this weekend, but fix incoming asap.
During the migration to GTK3 I removed the initialization for a deprecated method of safely running gtk+ calls within a gdk thread without actually replacing all the instances of said method. My bad. Patch 48e4e59 re-adds the initialization code to Gummi.
I ran a program that simulates user input into Gummi on a number of virtual machines and can reliably crash 0.8.0 within an hour of input. I can also reliably not have Gummi crash after several hours of constant input when this patch is applied.
Thanks very much for reporting this issue, 0.8.1 incoming now.