Bug 250403 - devel/geany: Sometimes geany exited on signal 10 (SIGBUS)
Summary: devel/geany: Sometimes geany exited on signal 10 (SIGBUS)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Guido Falsi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-16 17:55 UTC by Hodong
Modified: 2020-10-24 12:07 UTC (History)
1 user (show)

See Also:
madpilot: maintainer-feedback+


Attachments
patch from openSUSE - https://build.opensuse.org/request/show/798371 (geany-avoid-segfault-on-quit.patch) (1.68 KB, patch)
2020-10-20 19:02 UTC, Barbara Guida
no flags Details | Diff
Use g_signal_handlers_disconnect_by_func() (457 bytes, patch)
2020-10-23 02:25 UTC, Hodong
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hodong 2020-10-16 17:55:11 UTC
Hello.

I am using FreeBSD 13.0-CURRENT.
Sometimes geany exited on signal 10 (SIGBUS).

root@nimfsoft:/home/hodong # uname -a
FreeBSD nimfsoft 13.0-CURRENT FreeBSD 13.0-CURRENT #0 3d6668037a4-c253631(main): Thu Oct  8 07:13:18 UTC 2020     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

--------------------------------------------------------

root@nimfsoft:/home/hodong # grep geany /var/log/messages 
Oct 16 15:53:08 nimfsoft kernel: pid 1396 (geany), jid 0, uid 1001: exited on signal 10 (core dumped)
Oct 17 02:19:56 nimfsoft kernel: pid 10895 (geany), jid 0, uid 1001: exited on signal 10 (core dumped)

--------------------------------------------------------

hodong@nimfsoft:~ $ lldb -c geany.core /usr/local/bin/geany
(lldb) target create "/usr/local/bin/geany" --core "geany.core"
Core file '/home/hodong/geany.core' (x86_64) was loaded.

(lldb) bt
* thread #1, name = 'geany', stop reason = signal SIGBUS
  * frame #0: 0x00000008003726c6 libgeany.so.0`___lldb_unnamed_symbol1161$$libgeany.so.0 + 166
    frame #1: 0x000000080121bccf libgobject-2.0.so.0`g_cclosure_marshal_VOID__INTv + 111
    frame #2: 0x0000000801219466 libgobject-2.0.so.0`___lldb_unnamed_symbol61$$libgobject-2.0.so.0 + 198
    frame #3: 0x000000080122f401 libgobject-2.0.so.0`g_signal_emit_valist + 1185
    frame #4: 0x000000080122fe56 libgobject-2.0.so.0`g_signal_emit + 134
    frame #5: 0x0000000804592dc1 libvte-2.91.so`___lldb_unnamed_symbol985$$libvte-2.91.so + 49
    frame #6: 0x000000080458458a libvte-2.91.so`___lldb_unnamed_symbol538$$libvte-2.91.so + 90
    frame #7: 0x000000080121e20f libgobject-2.0.so.0`g_object_run_dispose + 47
    frame #8: 0x0000000800371b8f libgeany.so.0`___lldb_unnamed_symbol1149$$libgeany.so.0 + 31
    frame #9: 0x000000080033a965 libgeany.so.0`___lldb_unnamed_symbol556$$libgeany.so.0 + 757
    frame #10: 0x000000080033a64f libgeany.so.0`___lldb_unnamed_symbol555$$libgeany.so.0 + 143
    frame #11: 0x000000080030cc89 libgeany.so.0`___lldb_unnamed_symbol208$$libgeany.so.0 + 9
    frame #12: 0x0000000800d8c951 libgtk-3.so.0`___lldb_unnamed_symbol10394$$libgtk-3.so.0 + 177
    frame #13: 0x0000000801219466 libgobject-2.0.so.0`___lldb_unnamed_symbol61$$libgobject-2.0.so.0 + 198
    frame #14: 0x000000080122f401 libgobject-2.0.so.0`g_signal_emit_valist + 1185
    frame #15: 0x000000080122fe56 libgobject-2.0.so.0`g_signal_emit + 134
    frame #16: 0x0000000800d39ba9 libgtk-3.so.0`___lldb_unnamed_symbol9555$$libgtk-3.so.0 + 601
    frame #17: 0x0000000800bd58bd libgtk-3.so.0`gtk_main_do_event + 1853
    frame #18: 0x0000000800e3e5a1 libgdk-3.so.0`___lldb_unnamed_symbol146$$libgdk-3.so.0 + 49
    frame #19: 0x0000000800e73a67 libgdk-3.so.0`___lldb_unnamed_symbol642$$libgdk-3.so.0 + 39
    frame #20: 0x0000000801320c4e libglib-2.0.so.0`g_main_context_dispatch + 366
    frame #21: 0x0000000801320ff4 libglib-2.0.so.0`___lldb_unnamed_symbol120$$libglib-2.0.so.0 + 548
    frame #22: 0x000000080132133a libglib-2.0.so.0`g_main_loop_run + 234
    frame #23: 0x0000000800bd500b libgtk-3.so.0`gtk_main + 75
    frame #24: 0x000000080033a337 libgeany.so.0`main_lib + 4791
    frame #25: 0x00000000002017e0 geany`___lldb_unnamed_symbol2$$geany + 256
(lldb) 

--------------------------------------------------------

root@nimfsoft:/home/hodong # pkg info geany
geany-1.36
Name           : geany
Version        : 1.36
Installed on   : Wed Oct 14 22:17:30 2020 KST
Origin         : devel/geany
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : devel editors
Licenses       : GPLv2+
Maintainer     : madpilot@FreeBSD.org
WWW            : https://www.geany.org/
Comment        : Fast and lightweight GTK+ IDE
Options        :
	DOCS           : on
	NLS            : on
	THEMES         : off
	VTE            : on
Shared Libs required:
	libglib-2.0.so.0
	libgobject-2.0.so.0
	libpango-1.0.so.0
	libcairo.so.2
	libgtk-3.so.0
	libintl.so.8
	libcairo-gobject.so.2
	libatk-1.0.so.0
	libgmodule-2.0.so.0
	libgthread-2.0.so.0
	libgdk_pixbuf-2.0.so.0
	libgio-2.0.so.0
	libgdk-3.so.0
	libpangocairo-1.0.so.0
Shared Libs provided:
	libgeany.so.0
Annotations    :
	FreeBSD_version: 1300119
	flavor         : gtk3
	repo_type      : binary
	repository     : FreeBSD
Flat size      : 12.7MiB
Description    :
Geany is a small and lightweight integrated development environment. It was
developed to provide a small and fast IDE, which has only a few dependencies
on other packages. Another goal was to be as independent as possible from a
special Desktop Environment like KDE or GNOME.

WWW: https://www.geany.org/
Comment 1 Guido Falsi freebsd_committer 2020-10-16 18:34:33 UTC
Hi,

This one is quote difficult to diagnose.

Please keep in mind I'm only maintaining a port, and not developing geany, I have no deep knowledge of geany internals.

It would be helpful if you could rebuild geany and maybe glib with debug symbols. In this way we could get a better backtrace. The unnamed symbols are not helpful.


A few questions to try to narrow down the problem:

Are you building ports with poudriere or directly on the live system?

In both cases could you try rebuilding and reinstalling  gtk3, glib, geany and it's plugins? Sometimes this kind of issues happens due to some library being updated from below a package and causing the breakage.

In this case glib got a big update and could really be causing this.
Comment 2 Barbara Guida freebsd_committer 2020-10-18 07:18:23 UTC
For me geany always exits with SIBGUS on CURRENT while it's ok on 12.2-STABLE.
It should not depends on installed plugins.
Below the backtrace after rebuilding devel/geany devel/glib20 x11-toolkits/vte3(*) x11-toolkits/gtk30.
(*) that' because even if the ports depends on x11-toolkis/vte files from x11-toolkits/vte3 are listed in the backtrace.
Feel free to ask if you need any other test.

$ lldb `which geany` --core geany.core 
(lldb) target create "/usr/local/bin/geany" --core "geany.core"
Core file '/home/bar/geany.core' (x86_64) was loaded.

(lldb) bt
* thread #1, name = 'geany', stop reason = signal SIGBUS
  * frame #0: 0x0000000800401793 libgeany.so.0`vte_start(widget=0x00000008054e5b50) at vte.c:497:38
    frame #1: 0x00000008015b9ea8 libgobject-2.0.so.0`g_cclosure_marshal_VOID__INTv(closure=0x00000008058eb950, return_value=0x0000000000000000, instance=0x00000008054e5b50, args=0x00007fffffffd520, marshal_data=0x0000000000000000, n_params=1, param_types=0x0000000805520748) at gmarshal.c:596:3
    frame #2: 0x00000008015b5827 libgobject-2.0.so.0`_g_closure_invoke_va(closure=0x00000008058eb950, return_value=0x0000000000000000, instance=0x00000008054e5b50, args=0x00007fffffffd520, n_params=1, param_types=0x0000000805520748) at gclosure.c:873:7
    frame #3: 0x00000008015d8bd3 libgobject-2.0.so.0`g_signal_emit_valist(instance=0x00000008054e5b50, signal_id=400, detail=0, var_args=0x00007fffffffd520) at gsignal.c:3403:8
    frame #4: 0x00000008015da2d7 libgobject-2.0.so.0`g_signal_emit(instance=0x00000008054e5b50, signal_id=400, detail=0) at gsignal.c:3550:3
    frame #5: 0x0000000805e3d832 libvte-2.91.so`vte::platform::Widget::emit_child_exited(this=0x00000008054e59e0, status=9) at widget.cc:247:9
    frame #6: 0x0000000805e3d7ad libvte-2.91.so`vte::platform::Widget::dispose(this=0x00000008054e59e0) at widget.cc:239:17
    frame #7: 0x0000000805e204b0 libvte-2.91.so`vte_terminal_dispose(object=0x00000008054e5b50) at vtegtk.cc:590:35
    frame #8: 0x00000008015beb08 libgobject-2.0.so.0`g_object_run_dispose(object=0x00000008054e5b50) at gobject.c:1226:3
    frame #9: 0x00000008010ab3fa libgtk-3.so.0`gtk_widget_destroy(widget=0x00000008054e5b50) at gtkwidget.c:4776:5
    frame #10: 0x00000008004001b2 libgeany.so.0`vte_close at vte.c:402:2
    frame #11: 0x00000008003ad9af libgeany.so.0`do_main_quit at libmain.c:1353:25
    frame #12: 0x00000008003ad43b libgeany.so.0`main_quit at libmain.c:1415:7
    frame #13: 0x00000008003a2641 libgeany.so.0`cb_func_file_action(key_id=140) at keybindings.c:1487:4
    frame #14: 0x00000008003a20a4 libgeany.so.0`run_kb(kb=0x00000008006344f0, group=0x0000000800634810) at keybindings.c:1335:13
    frame #15: 0x00000008003a0e5f libgeany.so.0`on_key_press_event(widget=0x00000008050a2540, ev=0x00000008053b0470, user_data=0x0000000000000000) at keybindings.c:1393:9
    frame #16: 0x000000080112e4d1 libgtk-3.so.0`_gtk_marshal_BOOLEAN__BOXED(closure=0x00000008057402e0, return_value=0x00007fffffffdb80, n_param_values=2, param_values=0x00007fffffffdbb0, invocation_hint=0x00007fffffffdb68, marshal_data=0x0000000000000000) at gtkmarshalers.c:83:14
    frame #17: 0x00000008015b53c5 libgobject-2.0.so.0`g_closure_invoke(closure=0x00000008057402e0, return_value=0x00007fffffffdb80, n_param_values=2, param_values=0x00007fffffffdbb0, invocation_hint=0x00007fffffffdb68) at gclosure.c:810:7
    frame #18: 0x00000008015d7e4d libgobject-2.0.so.0`signal_emit_unlocked_R(node=0x000000080342df20, detail=0, instance=0x00000008050a2540, emission_return=0x00007fffffffe028, instance_and_params=0x00007fffffffdbb0) at gsignal.c:3738:8
    frame #19: 0x00000008015d9ac7 libgobject-2.0.so.0`g_signal_emit_valist(instance=0x00000008050a2540, signal_id=68, detail=0, var_args=0x00007fffffffe280) at gsignal.c:3504:7
    frame #20: 0x00000008015da2d7 libgobject-2.0.so.0`g_signal_emit(instance=0x00000008050a2540, signal_id=68, detail=0) at gsignal.c:3550:3
    frame #21: 0x00000008010b21d8 libgtk-3.so.0`gtk_widget_event_internal(widget=0x00000008050a2540, event=0x00000008053b0470) at gtkwidget.c:7808:4
    frame #22: 0x00000008010b1ea4 libgtk-3.so.0`gtk_widget_event(widget=0x00000008050a2540, event=0x00000008053b0470) at gtkwidget.c:7378:10
    frame #23: 0x0000000800eab713 libgtk-3.so.0`propagate_event(widget=0x00000008050a2540, event=0x00000008053b0470, captured=0, topmost=0x0000000000000000) at gtkmain.c:2680:29
    frame #24: 0x0000000800eaac30 libgtk-3.so.0`gtk_propagate_event(widget=0x00000008050a2540, event=0x00000008053b0470) at gtkmain.c:2724:3
    frame #25: 0x0000000800eaa4b7 libgtk-3.so.0`gtk_main_do_event(event=0x00000008053b0470) at gtkmain.c:1920:9
    frame #26: 0x00000008006c3cf5 libgdk-3.so.0`_gdk_event_emit(event=0x00000008053b0470) at gdkevents.c:73:5
    frame #27: 0x0000000800717666 libgdk-3.so.0`gdk_event_source_dispatch(source=0x000000080343a680, callback=0x0000000000000000, user_data=0x0000000000000000) at gdkeventsource.c:367:7
    frame #28: 0x00000008016e92e9 libglib-2.0.so.0`g_main_dispatch(context=0x000000080343b300) at gmain.c:3325:27
    frame #29: 0x00000008016e9120 libglib-2.0.so.0`g_main_context_dispatch(context=0x000000080343b300) at gmain.c:4016:7
    frame #30: 0x00000008016e9682 libglib-2.0.so.0`g_main_context_iterate(context=0x000000080343b300, block=1, dispatch=1, self=0x000000080355d8f0) at gmain.c:4092:5
    frame #31: 0x00000008016e9bc8 libglib-2.0.so.0`g_main_loop_run(loop=0x000000080591bd00) at gmain.c:4290:5
    frame #32: 0x0000000800ea9bcc libgtk-3.so.0`gtk_main at gtkmain.c:1328:7
    frame #33: 0x00000008003ac453 libgeany.so.0`main_lib(argc=1, argv=0x00007fffffffe8a8) at libmain.c:1259:2
    frame #34: 0x00000000002019f2 geany`main(argc=2, argv=0x00007fffffffe8a8) at main.c:27:9
    frame #35: 0x00000000002017df geany`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7
(lldb) f 0
frame #0: 0x0000000800401793 libgeany.so.0`vte_start(widget=0x00000008054e5b50) at vte.c:497:38
   494 	
   495 			if (vf->vte_terminal_spawn_sync)
   496 			{
-> 497 				if (! vf->vte_terminal_spawn_sync(VTE_TERMINAL(widget), VTE_PTY_DEFAULT,
   498 												  vte_info.dir, argv, env, 0, NULL, NULL,
   499 												  &pid, NULL, NULL))
   500 				{
Comment 3 Hodong 2020-10-18 09:34:43 UTC
(In reply to Guido Falsi from comment #1)
> Are you building ports with poudriere or directly on the live system?
No, I installed it with the'pkg install' command.
Comment 4 Hodong 2020-10-18 11:16:49 UTC
(In reply to Barbara Guida from comment #2)

Your comments are very helpful.
I found a related issue.

Segmentation fault with vte while quitting
https://github.com/geany/geany/issues/2457

Thank you.
Comment 5 Guido Falsi freebsd_committer 2020-10-20 13:22:13 UTC
(In reply to Hodong from comment #4)

Thanks for pointing me to this issue, I need to study that issue and the source code a little more and I could send a patch for the port here for testing. Please give me some days to find time to properly do this and perform my own testing.

Will you be able to test it? It will require recompiling geany.
Comment 6 Barbara Guida freebsd_committer 2020-10-20 18:00:50 UTC
Guido, I can help you building and testing the port if needed.
In the meanwhile I can test the patch from openSUSE.
Comment 7 Barbara Guida freebsd_committer 2020-10-20 19:02:31 UTC
Created attachment 218929 [details]
patch from openSUSE - https://build.opensuse.org/request/show/798371 (geany-avoid-segfault-on-quit.patch)
Comment 8 Barbara Guida freebsd_committer 2020-10-20 19:03:12 UTC
I've tested the patch and it works; geany isn't crashing anymore on close.
I don't know if you want to find a more elegant solution, anyway I'm attaching the diff I've used.

I've also changed VTE_USE to GNOME=vte3 because, as I've reported on comment #2, file from x11-toolkits/vte3 are being loaded and geany is the last and only port I have installed depending on x11-toolkits/vte, so I've removed it before start building.

***Maybe*** the VTE_USE should be moved inside the test for FLAVOR (GNOME=vte for gtk2 and GNOME=vte3 for gtk) as it seems to me that x11-toolkits/vte is tied to x11-toolkits/gtk20 while x11-toolkits/vte3 to x11-toolkits/gtk30, isn't it?
Comment 9 Guido Falsi freebsd_committer 2020-10-20 21:43:47 UTC
(In reply to Barbara Guida from comment #8)

Thanks for the patch. I'm going to test it.

The VTE dependency definitely needs fixing. I'm going to do that too.
Comment 10 Hodong 2020-10-23 02:25:57 UTC
Created attachment 218994 [details]
Use g_signal_handlers_disconnect_by_func()

After gtk_widget_destroy(), "child-exited" signal was emitted.
So, use g_signal_handlers_disconnect_by_func(vc->vte, G_CALLBACK(vte_start), NULL); before gtk_widget_destroy().

--- a/src/vte.c
+++ b/src/vte.c
@@ -399,6 +399,7 @@ void vte_close(void)
        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 */
+       g_signal_handlers_disconnect_by_func(vc->vte, G_CALLBACK(vte_start), NULL);
        gtk_widget_destroy(vc->vte);
        gtk_widget_destroy(vc->menu);
        g_object_unref(vc->menu);
Comment 11 Hodong 2020-10-23 02:30:21 UTC
I don't have a GitHub account. If you wish, you can submit it to the Geany project.
Comment 12 Guido Falsi freebsd_committer 2020-10-23 07:29:59 UTC
(In reply to Hodong from comment #11)

This patch is interesting, yes.

I'm going to test it. I have a lot of things in testing so it takes me a little time.

I'll try to upstream it too if it works fine.
Comment 13 Guido Falsi freebsd_committer 2020-10-24 08:41:00 UTC
(In reply to Hodong from comment #11)

Created a pull request upstream:

https://github.com/geany/geany/pull/2634

I'm going to commit the patch to the ports tree shortly.
Comment 14 commit-hook freebsd_committer 2020-10-24 08:52:04 UTC
A commit references this bug:

Author: madpilot
Date: Sat Oct 24 08:52:00 UTC 2020
New revision: 553166
URL: https://svnweb.freebsd.org/changeset/ports/553166

Log:
  Fix crash on close due to a signal handler on VTE widget being fired
  after the widget is destroyed.

  PR:		250403
  Submitted by:	Hodong <hodong@nimfsoft.com>
  MFH:		2020Q4

Changes:
  head/devel/geany/Makefile
  head/devel/geany/files/
  head/devel/geany/files/patch-src_vte.c
Comment 15 commit-hook freebsd_committer 2020-10-24 10:42:29 UTC
A commit references this bug:

Author: madpilot
Date: Sat Oct 24 10:42:05 UTC 2020
New revision: 553178
URL: https://svnweb.freebsd.org/changeset/ports/553178

Log:
  MFH: r553166

  Fix crash on close due to a signal handler on VTE widget being fired
  after the widget is destroyed.

  PR:		250403
  Submitted by:	Hodong <hodong@nimfsoft.com>

  Approved by:	ports-secteam (joneum)

Changes:
_U  branches/2020Q4/
  branches/2020Q4/devel/geany/Makefile
  branches/2020Q4/devel/geany/files/
Comment 16 Guido Falsi freebsd_committer 2020-10-24 12:07:18 UTC
Patch committed and merged. Thanks!

BTW upstream has already acknowledged the patch and is evaluating it.