After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794740 - >=2.54.3 SIGSEGV libgobject-2.0.so.0 g_type_check_instance_is_fundamentally_a in Ardour (<2.54.2 fine)
>=2.54.3 SIGSEGV libgobject-2.0.so.0 g_type_check_instance_is_fundamentally_a...
Status: RESOLVED INCOMPLETE
Product: glib
Classification: Platform
Component: gobject
2.54.x
Other Linux
: High critical
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2018-03-27 19:55 UTC by Cameron
Modified: 2018-04-03 18:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Ardour GDB Backtrace of SIGSEGV (14.12 KB, application/octet-stream)
2018-03-27 19:55 UTC, Cameron
Details
backtrace with glib 2.56 (symbols stripped) (19.57 KB, text/plain)
2018-03-28 05:41 UTC, Nathan
Details
terminal output with glib 2.56 (symbols not stripped; program did not crash) (8.77 KB, text/plain)
2018-03-28 05:43 UTC, Nathan
Details
backtrace: --enable-debug=yes; w/ debug symbols (22.97 KB, text/plain)
2018-03-28 21:16 UTC, Nathan
Details
backtrace: --enable-debug=minimum; w/ debug symbols; G_DEBUG=fatal-criticals (23.52 KB, text/plain)
2018-03-28 21:17 UTC, Nathan
Details

Description Cameron 2018-03-27 19:55:33 UTC
Created attachment 370217 [details]
Ardour GDB Backtrace of SIGSEGV

I wanted to log this here in case the issue stems from recent glib changes instead of improper handling by Ardour. Related bug-report for Ardour: http://tracker.ardour.org/view.php?id=7543

glib versions 2.54.2 and below work with Ardour 5.12 and 6.0-pre0, however any later version starting at 2.54.3 cause a SIGSEGV core dump when using "Automation." Myself and other affected users are all running Arch Linux, but I'm assuming the only correlation there is that Arch keeps glib and other libraries up-to-date much more freqently than other systems running Ardour.

I've attached a backtrace from the coredump, and I'm pasting portions of it here that I think are relevant:

Program terminated with signal SIGSEGV, Segmentation fault.

Thread 1 (Thread 0x7fcba2cf5940 (LWP 1468))

  • #0 g_type_check_instance_is_fundamentally_a
  • #1 g_object_ref
  • #2 0x00007fcb9f2d8125 in
  • #3 0x00007fcb9f2d47cc in
  • #4 g_closure_invoke
  • #5 0x00007fcb9fd25bb0 in
  • #6 g_signal_emit_valist
  • #7 g_signal_emit
  • #8 0x00007fcb9f3ef153 in
  • #9 gtk_main_do_event
  • #10 0x00007fcb9ef4bd5e in
  • #11 g_main_context_dispatch
  • #12 0x00007fcb9fa366a1 in
  • #13 g_main_loop_run
  • #14 gtk_main
  • #15 Gtkmm2ext::UI::run(Receiver&)
  • #16 0x000055580e950afd in
  • #17 __libc_start_main
  • #18 0x000055580e95571a in

Comment 1 Michael Catanzaro 2018-03-27 21:23:08 UTC
Thanks for taking the time to report this.
Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to do so and reopen this bug report. Thanks in advance!
Comment 2 Michael Catanzaro 2018-03-27 21:25:43 UTC
(In reply to Cameron from comment #0)
> glib versions 2.54.2 and below work with Ardour 5.12 and 6.0-pre0, however
> any later version starting at 2.54.3 cause a SIGSEGV core dump when using
> "Automation."

Are you sure 2.56.0 is broken too? 2.54.3 is a known-bad release and I'm surprised to see there was never a 2.54.4, that's not good.
Comment 3 Cameron 2018-03-27 23:01:34 UTC
First, thank you for your time.

Unfortunately, yes I seemed to have the same issue as reported with 2.56.0 installed. I just noticed this issue and found that bug report from January; it explains my exact symptoms and the stack traces are very similar at a glance. I don't have a cached version of 2.54.4, but it's possible that I delayed updating this machine and 2.56.0 was released during that time. At the moment I'm on a fully updated Arch system with this glib2: local/glib2 2.56.0+7+g66948ae23-1

I've setup a debugging-enabled glib2 package based on the Arch wiki link found through your link. Basically, I used the normal PKGBUILD for this package but added "debug !strip" into the options.

Fortunately... it worked! I know I was using 2.56.0 before because I ran ldd on the binary during my research. Something about building glib2 on my machine instead of using the distribution package seems to have resolved this. Now I wonder if the issue was with the packaging. In any case, this is not meaningfully reproducible. You somehow led me to a solution, so thanks again!
Comment 4 Cameron 2018-03-28 03:29:42 UTC
Actually, this is reproducible. Building the same package without debugging support causes the issue still. If you have any idea how we can debug this build where enabling debugging fixes the issue, please advise lol

The only changes in the build process should be:
Add: -g -fvar-tracking-assignments
Remove: --strip-debug --strip-unneeded

More specifically, building and installing the following PKGBUILD with and without the following patch are enough to cause the issue:

https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/glib2


index 1d18bca..a689920 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -14,7 +14,7 @@ makedepends=(gettext gtk-doc shared-mime-info python libelf git util-linux dbus)
 checkdepends=(desktop-file-utils)
 optdepends=('python: gdbus-codegen, glib-genmarshal, glib-mkenums, gtester-report'
             'libelf: gresource inspection tool')
-options=(!emptydirs)
+options=(debug !strip !emptydirs)
 _commit=66948ae231f75a548c8a2eb7b3a9d64cfd728b8e  # glib-2-56
 source=("git+https://gitlab.gnome.org/GNOME/glib.git#commit=$_commit"
         noisy-glib-compile-schemas.diff
Comment 5 Nathan 2018-03-28 05:40:15 UTC
As someone else with this issue, I thought I might chime in with some testing I've done.

I reproduced the issue on Arch (as documented in the Ardour bug tracker link) with Ardour 6.0-pre0 (compiled with debug symbols) and glib 2.56 (compiled w/o debug symbols). Ardour crashed. Backtrace from gdb is attached (mocha_ardour_backtrace).

I then compiled glib 2.56 with debug symbols, as described by Cameron with the `debug !strip` options in the PKGBUILD. Using glib 2.56 w/ debug symbols, the issue did not occur. Output from that test is attached (mocha_ardour_nocrash_output).

However, I also tested this issue in a VM running Ubuntu 18.04 (with libglib2.0-0 ver. 2.56.0-2ubuntu1), and the issue could not be reproduced, even though glib libraries had no debug symbols.

Given that the issue IS present in Arch with glib having debug symbols stripped, and the issue is NOT present in Ubuntu with glib also having no debug symbols, my tentative conclusion is that this is an issue on Arch's end, perhaps with makepkg's stripping procedure, and not an issue with glib.
Comment 6 Nathan 2018-03-28 05:41:55 UTC
Created attachment 370229 [details]
backtrace with glib 2.56 (symbols stripped)
Comment 7 Nathan 2018-03-28 05:43:00 UTC
Created attachment 370230 [details]
terminal output with glib 2.56 (symbols not stripped; program did not crash)
Comment 8 Nathan 2018-03-28 07:39:15 UTC
After some further testing, it turns out the crash in Ardour has nothing to do with whether or not glib had its debug symbols stripped.

Ardour crashes (on glib >=2.54.3, at least) when glib is compiled with `./configuration --enable-debug=yes`, probably regardless of distro. (Arch was just setting this option to "yes" in the PKGBUILD when makepkg's debug option was disabled, for whatever reason.)

The question remains of why Ardour is crashing when glib has runtime debugging enabled, but otherwise, this is an issue with Arch's PKGBUILD file, because --enable-debug should probably be set to "minimum" on stable releases of glib2 anyway.
Comment 9 Michael Catanzaro 2018-03-28 15:50:31 UTC
Nice investigation!

(In reply to Nathan from comment #8)
> Ardour crashes (on glib >=2.54.3, at least) when glib is compiled with
> `./configuration --enable-debug=yes`, probably regardless of distro. (Arch
> was just setting this option to "yes" in the PKGBUILD when makepkg's debug
> option was disabled, for whatever reason.)

So then you should be able to post a backtrace with debug symbols after all, right? :) Moving back to NEEDINFO....

I suspect the crash with --enable-debug=yes is going to be the same as the crash that would occur if you ran with --enable-debug=minimal and G_DEBUG=fatal-criticals.

(In reply to Nathan from comment #8)
> this is an issue with Arch's PKGBUILD
> file, because --enable-debug should probably be set to "minimum" on stable
> releases of glib2 anyway.

Definitely, that's worth a bug report to Arch.
Comment 10 Nathan 2018-03-28 21:14:22 UTC
I've attached two backtraces:

* one with glib 2.56 compiled with --enable-debug=yes, without debug symbols stripped (i.e. what you asked for)
* another with glib 2.56 compiled with --enable-debug=minimum, without symbols stripped, and Ardour run with the env var G_DEBUG=fatal-criticals

Looks like your guess was pretty accurate, if I'm reading those backtraces right.
Comment 11 Nathan 2018-03-28 21:16:26 UTC
Created attachment 370263 [details]
backtrace: --enable-debug=yes; w/ debug symbols
Comment 12 Nathan 2018-03-28 21:17:49 UTC
Created attachment 370265 [details]
backtrace: --enable-debug=minimum; w/ debug symbols; G_DEBUG=fatal-criticals
Comment 13 Michael Catanzaro 2018-03-29 00:45:13 UTC
So now you don't need to recompile GLib, at least!

It's missing the key frames, though, inside libgtk-x11-2.0.so.0. Please install debuginfo for that as well.
Comment 14 abandoned account 2018-04-02 23:23:00 UTC
Regarding Comment 8 aka https://bugzilla.gnome.org/show_bug.cgi?id=794740#c8

I'm on ArchLinux too and I've encountered the following issue https://bugzilla.xfce.org/show_bug.cgi?id=14320#c7
which makes me believe this is related: xfce4-taskmanager crashed upon exit because glib2 was compiled with --enable-debug=yes instead of --enable-debug=minimum ; in the latter case it doesn't crash.

(In reply to Michael Catanzaro from comment #9)
> I suspect the crash with --enable-debug=yes is going to be the same as the
> crash that would occur if you ran with --enable-debug=minimal and
> G_DEBUG=fatal-criticals.
> 
not for me:
With --enable-debug=minimum glib2 and then:
$ export G_DEBUG=fatal-criticals; gdb xfce4-taskmanager
no crash upon xfce4-taskmanager exit; (or I don't know how to use that G_DEBUG=fatal-criticals properly?)
Comment 15 Michael Catanzaro 2018-04-03 18:14:17 UTC
Try:

$ G_DEBUG=fatal-criticals gdb xfce4-taskmanager

Anyway, this is still missing a complete stacktrace.

Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!