MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007543ardourbugspublic2018-01-20 01:042018-03-28 14:41
Reportermocha_bean 
Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
StatusnewResolutionopen 
PlatformLinux x86_64OSArch LinuxOS Version4.14.13-1-ARCH
Product Version5.X git (version in description) 
Target VersionFixed in Version 
Summary0007543: Segfault when loading automation curves for plugins
DescriptionVersion: reproducible on 5.12 and 6.0-pre; backtrace is for 6.0-pre
Reproducible in JACK, ALSA, and Dummy modes; backtrace is for ALSA.

Whenever I load an automation curve for any plugin (e.g. a-Reverb), the curve is not displayed, and Ardour immediately segfaults.

If a session is loaded that already has plugin automation curves visible, Ardour will load the session successfully, and the curves function as expected.
Steps To Reproduce1. Launch Ardour, and open a session in any audio mode.
2. Create an audio track or bus, and insert a plugin on that track, if one is not already present.
3. In the editor window, right click on the far left side of the track to open the drop-down menu that contains "Automation."
4. Automation > Processor automation > [any plugin (e.g. "a-Reverb")] > [any parameter (e.g. "Enable")]
5. Immediately upon clicking any parameter (e.g. "Enable"), Ardour segfaults.
Additional Informationgtk2 version installed: 2.24.32

I was able to reproduce this issue on two different up-to-date Arch Linux systems.
TagsNo tags attached.
Attached Files? file icon backtrace [^] (25,605 bytes) 2018-01-20 01:04 [Show Content]
? file icon enabledebug-minimum_fatal-criticals_with-symbols_backtrace [^] (24,084 bytes) 2018-03-28 14:41 [Show Content]

- Relationships

-  Notes
(0020121)
mocha_bean (reporter)
2018-01-20 01:29

Issue is no longer present after downgrading from glib 2.54.3 to 2.54.2. Given also that the segfault points to libgobject-2.0.so.0, this might narrow down the issue.
(0020130)
x42 (administrator)
2018-01-23 03:10

Did you re-compile Ardour and gtk, gtkmm after up/downgrade of libgobject?
(0020132)
mocha_bean (reporter)
2018-01-23 06:07
edited on: 2018-01-23 06:15

No, I did not recompile anything after downgrading glib. I compiled Ardour 6.0-pre while glib 2.54.3 was installed. gtk and gtkmm were installed as binaries, and both are on versions 2.24.32 and 2.24.5, respectively, from the Arch repos.

(0020205)
tuxem (reporter)
2018-03-08 10:27

I confirm what mocha_bean reported.

I'm also on archlinux on 2 PCs. With the glib2 upgrade to 2.54.3 automation on plugins make Ardour (5 and 6) crash. Downgrading glib to 2.53.2 without re-install/compile Ardour, it solves the issue.

Thanks mocha_bean for the workaround ;)
(0020206)
timbyr (developer)
2018-03-08 16:55

It sounds like this issue is specific to the version of glib2 in Arch.

It may not be an Arch specific bug but it would be worth at least reporting it to the Arch bug tracker if it hasn't been already.
(0020223)
somethingtohide (reporter)
2018-03-27 13:04

Although I'm also on Arch Linux and affected by this, I don't believe the Arch bug tracker is the appropriate solution. AFAIK nothing is done to glib except to package the upstream releases. I've started another bugreport for glib on the GNOME bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=794740 [^]

I'm experiencing the same issue and it's show-stopping working without automation. At this point, glib2 in Arch has moved to 2.56.0 and the bug is still present. I cannot confirm that downgrading to 2.54.2 will work (I still have the package just in case) because other system libraries have been updated that rely on symbols from the new versions and I don't want to chase all of those down.

I totally understand Ardour's developers' situation and that unofficial builds and environments are unsupported. I'm sure everything works well when you're carefully controlling the libraries and environments. I may be wrong, but I think that Ardour's codebase is a possibility for fault here, even though it's revealed by a glib2 update.

That said, if there's a possibility that Ardour could be patched such that it works with the previous and current glib2, I'm willing to help out. I'm a developer, but I don't have experience with GTK fundamentals or Ardour's codebase.
(0020224)
somethingtohide (reporter)
2018-03-27 16:06

I must take back some of what I said. I was definitely having this issue with 2.56.0, but I am in a working state now. GTK developers confirmed that 2.53.3 was a bad release. I assumed the issue was still present in 2.56.0 because I had the same symptoms.

However, in rebuilding 2.56.0 with debugging symbols for bug-fixing, the issue is resolved. This leads me to believe that there could have been an issue with the distribution packaging. 2.56.0 from the repository was causing this crash, but my debugging re-build with the same packaging script is working fine.

Since this is working now, I see log messages that I was not able to get to before, but they seem to happen as I'm working with automations. Considering we know somewhat about where this stems from, this seems relevant:

(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:1002): GLib-GObject-CRITICAL **: 16:55:18.694: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(0020225)
mocha_bean (reporter)
2018-03-27 16:33
edited on: 2018-03-27 16:34

Nice work on that, somethingtohide.

I actually just got through doing some tests on a VM running Ubuntu 18.04 beta (with glib 2.56 installed). This could help shed some light on the issue.

I attempted to reproduce the bug in Ardour 5.12 (binary, from the repos) as well as in a locally-compiled copy of Ardour 6.0-pre0 with debugging. Neither crashed upon attempting to reproduce the issue. I also got a similar error output in the terminal both times when I tried to load the automation curves.

6.0-pre0:

(ardour-6.0.pre0.652:5143): GLib-GObject-CRITICAL **: 17:58:24.373: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-6.0.pre0.652:5143): GLib-GObject-CRITICAL **: 17:58:24.374: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-6.0.pre0.652:5143): GLib-GObject-CRITICAL **: 17:58:24.374: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-6.0.pre0.652:5143): GLib-GObject-CRITICAL **: 17:58:24.374: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-6.0.pre0.652:5143): GLib-GObject-CRITICAL **: 17:58:24.374: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-6.0.pre0.652:5143): GLib-GObject-CRITICAL **: 17:58:24.374: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

5.12:

(ardour-5.12.0:6569): Gdk-CRITICAL **: 18:18:32.570: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed
(ardour-5.12.0:6569): Gdk-CRITICAL **: 18:18:32.570: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed
(ardour-5.12.0:6569): GLib-GObject-CRITICAL **: 18:18:37.459: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:6569): GLib-GObject-CRITICAL **: 18:18:37.459: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:6569): GLib-GObject-CRITICAL **: 18:18:37.459: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:6569): GLib-GObject-CRITICAL **: 18:18:37.459: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:6569): GLib-GObject-CRITICAL **: 18:18:37.459: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(ardour-5.12.0:6569): GLib-GObject-CRITICAL **: 18:18:37.459: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

Given that the issue can't be reproduced in Ubuntu, and given your tests with your build of 2.56, it's probably a pretty safe bet that this is an issue on Arch's side.

(0020226)
mocha_bean (reporter)
2018-03-27 16:49

Also, somethingtohide, what are the configuration options you used when building glib?

Was it just `--enable-debug`?
(0020227)
somethingtohide (reporter)
2018-03-27 16:57

Using info from:
https://wiki.archlinux.org/index.php/Arch_Build_System [^]
https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces [^]

I ran:
asp checkout glib2

Went into trunk and modified the PKGBUILD. I simply added "debug !strip" to options, such that line 17 looked like:
options=(debug !strip !emptydirs)

Simple "makepkg -sri" from there. It's possible that tweak alone made the difference, but I doubt it. I'm beginning to suspect that the package in the repos for 2.56.0 was not built correctly in some way, or that doing it on my machine without a clean chroot created a working version.

I can possibly help more, but since it's working I'm a little preoccupied now :P
(0020228)
mocha_bean (reporter)
2018-03-27 20:04

Just tried it myself, and my results were consistent with yours. With the debug options (debug !strip !emptydirs), the issue was not present.

I also tried building the package with default settings (just !emptydirs) and the issue WAS present.

Looks like your tweak did make the difference. Apparently glib2 only works without the debug symbols stripped? Beats me.
(0020229)
mocha_bean (reporter)
2018-03-27 21:37

Also, interestingly, glib 2.56 is NOT compiled with debugging symbols on Ubuntu.

So, in Arch, it does not work with debug symbols stripped, but in Ubuntu, it works fine with the debug symbols stripped.

Looks like an issue on Arch's end, but this makes it pretty difficult to pin down.
(0020230)
mocha_bean (reporter)
2018-03-27 22:37

Perhaps it's specifically an issue with makepkg? i.e. it's screwing something up with the glib2 package when the strip option is enabled.
(0020231)
mocha_bean (reporter)
2018-03-28 00:28

Alright, I've figured out something important here. The problem's in the PKGBUILD.

The reason Ardour doesn't crash when glib2 2.56 is compiled with `options=(debug !strip !emptydirs)` is because there's a line in build() that checks whether or not the debug option is enabled.

These first two lines in build() create a variable 'debug' equal to "minimum", and then run a check_option to see whether the debug option is disabled. If so, the check_option returns 0 and the condition of the && is satisfied, so the 'debug' variable is then set to "yes". Otherwise, it stays at "minimum":

  local debug=minimum
  check_option debug n && debug=yes

By default, the debug option in makepkg is disabled, so the condition of the && will be satisfied and the 'debug' variable will equal "yes".

Farther down the line, the ./configure options are set, and this line is present:

  --enable-debug=$debug

So, by default, ./configure will run with `--enable-debug=yes`. But if you set `debug` in the options, then `check_option debug n` will not return 0, the 'debug' variable will stay at minimum, and ./configure will run with `--enable-debug=minimum`. As per glib documentation (https://developer.gnome.org/glib/stable/glib-building.html [^]), setting it to "minimum" just disables cast checks, and setting it to "yes" enables runtime debugging. These settings have nothing to do with whether or not debug symbols are retained.

I built the package again with default options, i.e. options=(!emptydirs), so debug symbols are stripped as is default. I commented out the first two lines of build() (i.e. `local debug=minimum` and `check_option debug n && debug=yes` and set `--enable-debug=minimum`, taking the 'debug' variable out of the equation.

This resolved the issue, without debug symbols present.

Conclusions to be drawn from this:

* Ardour does not crash with any version of glib compiled with --enable-debug=minimum
* Ardour crashes with glib >=2.54.3 compiled with --enable-debug=yes, presumably regardless of distro (assuming that Ubuntu's glib2 is compiled with --enable-debug=minimum, which is, according to GNOME, the default for stable releases) (this conclusion is worth testing on Ubuntu, but it's probably a pretty safe conclusion)
* Arch's PKGBUILD compiles glib2 with --enable-debug=yes when makepkg's debug option is false (which it is by default), for no discernible reason whatsoever.
(0020233)
somethingtohide (reporter)
2018-03-28 06:48

Good looking out. Actually, it may not even be about glib2 >= 2.54.3 compared to <= 2.54.2... This is looking more like an entirely Arch-related issue.

The PKGBUILD for 2.54.3 introduced a new way of building glib2, including the --enable-debug line. Check out the changes here: https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/glib2&id=2af117ea91369101715a5f39ee6063bbf07d8820 [^]
(0020234)
mocha_bean (reporter)
2018-03-28 14:41

Nice find. That does still leave the question of why Ardour is crashing when real-time debugging is enabled for glib. My guess is that the option probably causes that 'GLib-GObject-CRITICAL' error to crash the program instead of just throwing an error like it would if --enable-debug was set to minimum like it should be. I provided more detail on the debug options - and how they effect Ardour crashing - in the GNOME bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=794740 [^]

I'd imagine the only concern here for Ardour would be fixing that critical glib error, if that's worth anything, given it doesn't crash the program unless some debug options are set.

Here's the relevant bug report for Arch; someone's apparently already started it and I'd rather not make a duplicate:

https://bugs.archlinux.org/index.php?do=details&task_id=57785 [^]

I'll also attach another backtrace here (performed with glib compiled w/debug symbols, --enable-debug=minimum, and env var G_DEBUG=fatal-criticals) to provide devs with more info on that glib error.

- Issue History
Date Modified Username Field Change
2018-01-20 01:04 mocha_bean New Issue
2018-01-20 01:04 mocha_bean File Added: backtrace
2018-01-20 01:29 mocha_bean Note Added: 0020121
2018-01-23 03:10 x42 Note Added: 0020130
2018-01-23 06:07 mocha_bean Note Added: 0020132
2018-01-23 06:15 mocha_bean Note Edited: 0020132 View Revisions
2018-03-08 10:27 tuxem Note Added: 0020205
2018-03-08 16:55 timbyr Note Added: 0020206
2018-03-27 13:04 somethingtohide Note Added: 0020223
2018-03-27 16:06 somethingtohide Note Added: 0020224
2018-03-27 16:33 mocha_bean Note Added: 0020225
2018-03-27 16:34 mocha_bean Note Edited: 0020225 View Revisions
2018-03-27 16:49 mocha_bean Note Added: 0020226
2018-03-27 16:57 somethingtohide Note Added: 0020227
2018-03-27 20:04 mocha_bean Note Added: 0020228
2018-03-27 21:37 mocha_bean Note Added: 0020229
2018-03-27 22:37 mocha_bean Note Added: 0020230
2018-03-28 00:28 mocha_bean Note Added: 0020231
2018-03-28 06:48 somethingtohide Note Added: 0020233
2018-03-28 14:41 mocha_bean Note Added: 0020234
2018-03-28 14:41 mocha_bean File Added: enabledebug-minimum_fatal-criticals_with-symbols_backtrace


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker