Geany segfaulting, maybe related to logging

[grahambartlett]

My apologies for the generic title - as a long-time software engineer, I wish I could be more specific about the chain of events! All I can say reliably is that Geany crashes regularly, sometimes when I'm using it, sometimes when it's just sat in the background whilst other things are happening.

My environment:

• XUbuntu 22.04 (with all latest updates), running as a VirtualBox VM.
• VM isn't resource constrained for cores/RAM/storage.
• I'm using the Geany "workbench" plugin as a convenient way to browse/edit files in working directory.

Using GDB to trace the segfault:-

Thread 1 "geany" received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
74	../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
geany/geany#1  0x00007ffff7b10d31 in __vfprintf_internal (s=s@entry=0x7fffffffd750, format=format@entry=0x7fffecbfe890 "%s: Prj: \"%s\" Dir: \"%s\" %s: \"%s\"", ap=ap@entry=0x7fffffffd9a0, mode_flags=mode_flags@entry=2) at ./stdio-common/vfprintf-internal.c:1517
geany/geany#2  0x00007ffff7b220da in __vasprintf_internal (result_ptr=0x7fffffffd8b0, format=0x7fffecbfe890 "%s: Prj: \"%s\" Dir: \"%s\" %s: \"%s\"", args=0x7fffffffd9a0, mode_flags=2) at ./libio/vasprintf.c:57
geany/geany#3  0x00007ffff6c96123 in g_vasprintf () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#4  0x00007ffff6c66e21 in g_strdup_vprintf () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#5  0x00007ffff6c4e276 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#6  0x00007ffff6c4e703 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#7  0x00007fffecbfcacf in ?? () from /usr/lib/x86_64-linux-gnu/geany/workbench.so
geany/geany#8  0x00007ffff6e0bbe7 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
geany/geany#9  0x00007ffff6d65700 in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
geany/geany#10 0x00007ffff6d65863 in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
geany/geany#11 0x00007ffff6ece246 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
geany/geany#12 0x00007ffff6c45d3b in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#13 0x00007ffff6c9b2b8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#14 0x00007ffff6c452b3 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
geany/geany#15 0x00007ffff74b9d2d in gtk_main () from /lib/x86_64-linux-gnu/libgtk-3.so.0
geany/geany#16 0x00007ffff7d52d1a in main_lib () from /lib/x86_64-linux-gnu/libgeany.so.0
geany/geany#17 0x00007ffff7ac3d90 in __libc_start_call_main (main=main@entry=0x555555555060, argc=argc@entry=2, argv=argv@entry=0x7fffffffe178) at ../sysdeps/nptl/libc_start_call_main.h:58
geany/geany#18 0x00007ffff7ac3e40 in __libc_start_main_impl (main=0x555555555060, argc=2, argv=0x7fffffffe178, init=<optimised out>, fini=<optimised out>, rtld_fini=<optimised out>, stack_end=0x7fffffffe168) at ../csu/libc-start.c:392
geany/geany#19 0x0000555555555095 in ?? ()

[grahambartlett]

In case it helps, this is the full GDB logs.
full_gdb_geany_crash.txt

[grahambartlett]

BTW, XUbuntu 22.04 installs Geany 1.38. I have the following plugins loaded at startup, and I haven't loaded any others:-

File Browser
Line Operations
Workbench

[b4n]

Could you by any chance try building latest Geany and plugins?

Otherwise, having debugging symbols for workbench and GLib would help. From the backtrace it looks like it's originating from the workbench plugin.

[b4n]

From the log, I'd blame it on the file monitoring code, and passing an invalid string to the logger.

[grahambartlett]

@b4n b4n Yeah, I guessed something like that, but I'm afraid investigating is a bit of a side-quest from the FPGA which my work really want me to get running. :/ Thanks for transferring the issue to a better place.

If someone from the workbench team really needs more info, let me know, and I'll line up a lunchbreak or something to look at it.

[grahambartlett]

Oh yes, more context on what might be relevant. The workbench top-level directory inevitably includes the working directory for my build, because it'd be hard to do anything else if I need to edit project files. So when things are compiling, intermediate files in the workbench path may be appearing, disappearing or changing.

This could well be thrashing the log, which would give interesting issue if it's not fully thread-safe.

Files could also appear and disappear again quickly. If anything schedules a "capture details of a new file" event, and assumes that the file will still be there when it gets round to handling the event, it could well be disappointed. Ditto if it thinks a file has been deleted and then finds that it's reappeared.

No idea whether those are the cause, but I've fallen into both traps myself :) and it might tie in with what I'm doing in my build environment, even when I'm not actively using Geany at the time.

[b4n]

All this could be relevant, I'd require investigating deeper.

I haven't seen recent changes in the plugin so updating might not fix anything, but better debugging symbols could be useful. Also if you can afford it, you could try running under valgrind.

[b4n]

I believe it was a simpler memory management bug in the plugin, see #1431. If you could give this a spin, that'd be grand!

[grahambartlett]

Brilliant, thank you! I'll try to get round to setting up a build for it next week if I can.