From https://bugzilla.opensuse.org/show_bug.cgi?id=1166820, user reported when quitting geany, a segmentation fault happened, and got such backtrace:
``` $ gdb /usr/bin/geany core /usr/share/gdb/python/gdb/command/prompt.py:48: SyntaxWarning: "is not" with a literal. Did you mean "!="? if self.value is not '': /usr/share/gdb/python/gdb/command/prompt.py:60: SyntaxWarning: "is not" with a literal. Did you mean "!="? if self.value is not '': GNU gdb (GDB; openSUSE Tumbleweed) 8.3.1 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://bugs.opensuse.org/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/geany... Reading symbols from /usr/lib/debug/usr/bin/geany-1.36-2.1.x86_64.debug... [New LWP 5507] [New LWP 5514] [New LWP 5513] [New LWP 5523] [New LWP 5522] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `geany debugsource'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f6f9d4d9722 in vte_start (widget=0x56253b412180) at vte.c:497 497 if (! vf->vte_terminal_spawn_sync(VTE_TERMINAL(widget), VTE_PTY_DEFAULT, [Current thread is 1 (Thread 0x7f6f9b533140 (LWP 5507))] (gdb) bt #0 0x00007f6f9d4d9722 in vte_start (widget=0x56253b412180) at vte.c:497 #1 0x00007f6f9c72531e in g_cclosure_marshal_VOID__BOOLEANv (closure=<optimized out>, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x56253b4085c0) at ../gobject/gmarshal.c:272 #2 0x00007f6f9c7230e6 in _g_closure_invoke_va (closure=0x56253b4833f0, return_value=0x0, instance=0x56253b412180, args=0x7ffef715f070, n_params=1, param_types=0x56253b4085c0) at ../gobject/gclosure.c:873 #3 0x00007f6f9c73f428 in g_signal_emit_valist (instance=0x56253b412180, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffef715f070) at ../gobject/gsignal.c:3306 #4 0x00007f6f9c73fbcf in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3453 #5 0x00007f6f98c98f07 in vte::platform::Widget::emit_child_exited (status=9, this=0x56253b412020) at ../src/widget.hh:47 #6 vte::platform::Widget::dispose (this=0x56253b412020) at ../src/widget.cc:135 #7 vte::platform::Widget::dispose (this=0x56253b412020) at ../src/widget.cc:131 #8 vte_terminal_dispose (object=0x56253b412180) at ../src/vtegtk.cc:412 #9 0x00007f6f9c729a4e in g_object_run_dispose (object=0x56253b412180) at ../gobject/gobject.c:1130 #10 0x00007f6f9ccfe729 in gtk_widget_destroy (widget=<optimized out>) at gtkwidget.c:4776 #11 0x00007f6f9d5016eb in vte_close () at vte.c:402 #12 do_main_quit () at libmain.c:1353 #13 do_main_quit () at libmain.c:1274 #14 0x00007f6f9d503558 in main_quit () at libmain.c:1415 #15 0x00007f6f9d537e69 in on_window_delete_event (widget=widget@entry=0x56253aed0510, event=event@entry=0x56253b099710, gdata=<optimized out>) at callbacks.c:85 #16 0x00007f6f9ccb6a5b in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x56253adaf8b0, return_value=0x7ffef715f380, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x56253aa5ec90) at gtkmarshalers.c:129 #17 0x00007f6f9c7230e6 in _g_closure_invoke_va (closure=0x56253adaf8b0, return_value=0x7ffef715f380, instance=0x56253aed0510, args=0x7ffef715f450, n_params=1, param_types=0x56253aa5ec90) at ../gobject/gclosure.c:873 #18 0x00007f6f9c73f06a in g_signal_emit_valist (instance=0x56253aed0510, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffef715f450) at ../gobject/gsignal.c:3306 #19 0x00007f6f9c73fbcf in g_signal_emit (instance=instance@entry=0x56253aed0510, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3453 #20 0x00007f6f9cd01c62 in gtk_widget_event_internal (event=0x56253b099710, widget=0x56253aed0510) at gtkwidget.c:7808 #21 gtk_widget_event_internal (widget=0x56253aed0510, event=0x56253b099710) at gtkwidget.c:7677 #22 0x00007f6f9ce42149 in gtk_main_do_event (event=0x56253b099710) at gtkmain.c:1818 #23 gtk_main_do_event (event=<optimized out>) at gtkmain.c:1687 #24 0x00007f6f9cbaf6e4 in _gdk_event_emit (event=0x56253b099710) at gdkevents.c:73 #25 _gdk_event_emit (event=0x56253b099710) at gdkevents.c:67 #26 0x00007f6f9cb7e1f2 in gdk_event_source_dispatch (source=source@entry=0x56253a99b1c0, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:367 #27 0x00007f6f9c633008 in g_main_dispatch (context=0x56253a99b2b0) at ../glib/gmain.c:3216 #28 g_main_context_dispatch (context=context@entry=0x56253a99b2b0) at ../glib/gmain.c:3881 #29 0x00007f6f9c633390 in g_main_context_iterate (context=0x56253a99b2b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3954 #30 0x00007f6f9c633663 in g_main_loop_run (loop=0x56253f429830) at ../glib/gmain.c:4148 #31 0x00007f6f9ce3bd75 in gtk_main () at gtkmain.c:1325 #32 0x00007f6f9d510104 in main_lib (argc=<optimized out>, argv=<optimized out>) at libmain.c:1259 #33 0x00007f6f9d5f7ceb in __libc_start_main (main=0x5625392e7050 <main>, argc=2, argv=0x7ffef715fa08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffef715f9f8) at ../csu/libc-start.c:308 #34 0x00005625392e708a in _start () at ../sysdeps/x86_64/start.S:120 ```
User said it can be reproduced with such steps:
- boot, - login to openbox window manager, - start a 'gnome-terminal', - run 'geany somefile' (or with '&' to set it into background, no matter), - wait until geany has come up, - close geany via the 'X' of the window manager, or via menu 'File -> Quit' (doesn't matter which). --> Segmentation fault (core dumped)
But I failed to reproduce it, while user can not reproduce it if he create another system account.
I've read it and some code, seems `vte_close()` called `g_free(vf);` and `gtk_widget_destroy(vc->vte);`, `gtk_widget_destroy(vc->vte);` will make vte emit `child-exited` event because it will kill child process while disposing, and there are `g_signal_connect(vte, "child-exited", G_CALLBACK(vte_start), NULL);` in `create_vte()`, and then go to `#0` of backtrace.
But if so, I should be able to reproduce it, another strange thing is that gdb shows that `vf`, `vc->vte` are all valid, I don't know why, if dispose is called, at least `vf` should be freed.
I'll try to update if I get some new idea.
This is a recorded message, please always provide the version of Geany, Glib and GTK (see lines near the top of Help->Debug Messages) and the operating system and version you are using.
This is a recorded message, please always provide the version of Geany, Glib and GTK (see lines near the top of Help->Debug Messages) and the operating system and version you are using.
``` 11:48:50: Geany INFO : Geany 1.36, C 11:48:50: Geany INFO : GTK 3.24.14, GLib 2.62.5 ```
Some last lines of `strace -v`:
``` mkdir("/home/berny/.config/geany/plugins/git-changebar", 0700) = -1 EEXIST (File exists) stat("/home/berny/.config/geany/plugins/git-changebar", {st_dev=makedev(0x8, 0x3), st_ino=5046407, st_mode=S_IFDIR|0700, st_nlink=2, st_uid=1000, st_gid=100, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=1568839490 /* 2019-09-18T22:44:50.294080482+0200 */, st_atime_nsec=294080482, st_mtime=1584615119 /* 2020-03-19T11:51:59.730143562+0100 */, st_mtime_nsec=730143562, st_ctime=1584615119 /* 2020-03-19T11:51:59.730143562+0100 */, st_ctime_nsec=730143562}) = 0 openat(AT_FDCWD, "/home/berny/.config/geany/plugins/git-changebar/git-changebar.conf.IW80H0", O_RDWR|O_CREAT|O_EXCL, 0666) = 10 fallocate(10, 0, 0, 105) = -1 EOPNOTSUPP (Operation not supported) write(10, "[general]\nmonitor-repository=tru"..., 105) = 105 fstatfs(10, {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=28350632, f_bfree=5107059, f_bavail=3692766, f_files=7208960, f_ffree=6905360, f_fsid={val=[1805602031, 1325029409]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOATIME}) = 0 lstat("/home/berny/.config/geany/plugins/git-changebar/git-changebar.conf", {st_dev=makedev(0x8, 0x3), st_ino=5046410, st_mode=S_IFREG|0644, st_nlink=1, st_uid=1000, st_gid=100, st_blksize=4096, st_blocks=8, st_size=105, st_atime=1584615119 /* 2020-03-19T11:51:59.718143404+0100 */, st_atime_nsec=718143404, st_mtime=1584615119 /* 2020-03-19T11:51:59.718143404+0100 */, st_mtime_nsec=718143404, st_ctime=1584615119 /* 2020-03-19T11:51:59.730143562+0100 */, st_ctime_nsec=730143562}) = 0 fsync(10) = 0 close(10) = 0 rename("/home/berny/.config/geany/plugins/git-changebar/git-changebar.conf.IW80H0", "/home/berny/.config/geany/plugins/git-changebar/git-changebar.conf") = 0 stat("/etc/localtime", {st_dev=makedev(0x8, 0x2), st_ino=656812, st_mode=S_IFREG|0644, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=2298, st_atime=1569244017 /* 2019-09-23T15:06:57+0200 */, st_atime_nsec=0, st_mtime=1569244017 /* 2019-09-23T15:06:57+0200 */, st_mtime_nsec=0, st_ctime=1583450481 /* 2020-03-06T00:21:21.877425942+0100 */, st_ctime_nsec=877425942}) = 0 munmap(0x7fbae129f000, 42136) = 0 munmap(0x7fbae0a86000, 1012080) = 0 munmap(0x7fbae1294000, 41032) = 0 munmap(0x7fbae06de000, 247736) = 0 getpgid(19619) = 19619 kill(-19619, SIGHUP) = 0 kill(19619, SIGHUP) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} --- +++ killed by SIGSEGV (core dumped) +++ ```
and the operating system and version you are using.
Please provide the information requested to see if anyone has the same setup to try to replicate.
Also please try with all plugins disabled. If it still crashes report here with a GDB backtrace, if not enable plugins singly, ie only one plugin running and see which one causes the crash and report on geany plugins with gdb backtrace.
The only active plugin was GitChangeBar. I disabled it, re-started Geany (with a crash fwiw), checked that the plugin is still disabled, but still the same crash at the next quit as in the backtrace above.
Please provide the information requested to see if anyone has the same setup to try to replicate.
What operating system and version? Clearly nobody else has reported it, so unless you provide information requested we can't help you because we can't replicate it.
GDB backtrace
Not an strace.
It's an openSUSE:Tumbleweed system. As it is a rolling release, the version numbers of the various packages change quite a lot, but I'm seeing this crash for a longer time now (at least half a year).
[GDB backtrace](https://github.com/geany/geany/files/4450269/core.txt)
Hmm, looking at your backtrace I suggest there may be a race between destroying the VTE widget and emitting the `child_exit` signal when the child shell dies.
Here the `child_exit` is emitted on a widget after dispose has been called on it, and that signal calls start as shown at `#0` (the widget at `#0` is the same as that passed to dispose at `#9`) and not unsurprisingly that does not work since it has been (or is at least partly) disposed.
If the dispose had finished then probably there would have been nothing to emit the `child_exit` signal on so no bogus attempt to run start would happen.
Possibly nobody else has seen the problem due to you having a bleeding edge VTE version that has changed something for the worse.
That conclusion sounds right and matches the last commands of the strace where the kill() signal is sent.
Re. "bleeding edge VTW": I'd guess that there are several thousand openSUSE:Tumbleweed users, and maybe 20% thereof (?) may use Geany, so someone should also have this problem. Maybe they don't see it anymore because systemd is usually hiding the coredumps, but I've changed my /proc/sys/kernel/core_pattern to get good'ol "core" files.
Can I provide anything else to narrow down something for your to reproduce?
@bernhard-voelker if you can build Geany from source maybe you can try disconnecting the `child-exit` signal from `vte_start` in `vte_close()` before disposing of the widget.
hmm, there's already a related comment in `src/vte.c:vte_close()` about crashes on FreeBSD. Okay, trying the hard way by blocking `vte_start` completely if `vte_close` is running: ```c --- geany-1.36.orig/src/vte.c +++ geany-1.36/src/vte.c @@ -393,9 +393,10 @@ static void create_vte(void) g_signal_connect_after(vte, "realize", G_CALLBACK(on_vte_realize), NULL); }
- +static int vte_closing; void vte_close(void) { + vte_closing = 1; g_free(vf); /* free the vte widget before unloading vte module * this prevents a segfault on X close window if the message window is hidden */ @@ -485,6 +486,8 @@ static void vte_commit_cb(VteTerminal *v
static void vte_start(GtkWidget *widget) { + if (0 < vte_closing) + return; /* split the shell command line, so arguments will work too */ gchar **argv = g_strsplit(vc->shell, " ", -1);
``` Building and publishing the RPM on [OBS](https://build.opensuse.org/package/show/home:berny:branches:GNOME:Apps/geany) takes a while ...
Results: - installing the patched version (see above) -> no crash on quit anymore, - re-installing the original version from openSUSE:Tumbleweed --> segfaults again, - re-installing the patched version -> no segfaults. - from a cursory look, I did not see any side effects with the patch (but I don't know the geany/QT source code at all to better judge).
Thanks for trying that, AFAIK no regular Geany contributors use Suse so we would never see the problem. VTE has always been a bit flakey, unavailable on Windows and other problems, but maybe its just not being used right, who knows, the documentation is sparse.
Hopefully you can keep using the patched version because in the current world I can't say how long it will be until someone with enough GTK expertise can solve it properly.
Possibly nobody else has seen the problem due to you having a bleeding edge VTE version that has changed something for the worse.
So far, openSUSE Tumbleweed was still on GNOME 3.34, hence vte 0.58.3; not very 'bleeding edge' for that component (3.36 merge was slow due to syncup with Leap 15.2);
@bernhard-voelker Snapshot 0423 will come with GNOME 3.36 / vte 0.60.1. Might be worthy to re-evaluate without the patch then
@DimStar77 VTE versions for GTK3 are 2.90 and 2.91, I think your 0.58 is a _package_ version, not the library version.
2.90 / 2.91 are the API/ABI versions of the library - 0.58 / 0.60 are the source versions as tagged by upstream (both are from the 2.91 ABI tree https://gitlab.gnome.org/GNOME/vte/-/tags)
Ok, Geany only cares about the API of course :)
of course; but if you refer to vte 2.91, you run into a void as the library does not exist :)
The so is `libvte-2.9[01].so`, which is how Geany finds it and knows its the right API.
The so is `libvte-2.9[01].so`, which is how Geany finds it and knows its the right API.
sure; yet if you were to reply a bug against libvte-2.91, upstream would have zero chance to know what you're running; just because API/ABI does not change in a backward incompatible way does not mean we can stop referring to versions of the code being used.
You are correct that its a diversion from the issue at hand.
All I did was propose a possible reason why nobody else has seen the problem (not knowing much about Suse, but assuming a rolling release is bleeding edge). That possibility may not be correct.
If its a version of VTE thats common (not for me on an LTS distro :) then that just makes it more unusual that nobody else has reported it, and makes it look a distro specific problem.
As I noted I am not aware of any regular contributors using Suse and none of them have reported the problem on other distros, so that would also tend to also suggest its specific to the distro.
Could you check if #2634 fixed the problem? It probably should have, but better be sure :)
Actually I'm going ahead and closing this one, because I really think #2634 fixed it. Feel free to reopen if not, though.
Closed #2457.
github-comments@lists.geany.org