Qtractor crashes when clicking on Load Instrument

[maxigaz]

Using Arch Linux and Qtractor 0.9.26.22git.0df4f6, when I open the GUI of Zyn-Fusion and click on File > Load Instrument, Qtractor crashes. This happens with both the LV2 and VST versions.

Sometimes it happens after clicking on it the second or third time (dismissing the file chooser dialogue in between).

(I've only been able to test the released version 3.0.6, installed through zynaddsubfx from the official Arch repositories. I've tried building Zyn-Fusion with the help of these scripts inside a systemd-nspawn container, but all I get is a black window, even though I have run install-linux.sh in the container.)

[maxigaz]

I've come across the same bug in Ardour 6.9, which happened also after clicking on Load Instrument. However, I haven't been able to reproduce it since then, only in Qtractor, where it is easy to trigger the crash.

[fundamental]

Generally either a crash is at the top level scripting level or at the C level. If it's the former the code ought to attempt to print a backtrace before exiting. Do you see any such backtrace being printed to stdout? You'd need to start either Qtractor or Ardour from the command line to see this output.

[maxigaz]

If I start Qtractor from the terminal, no output is printed. However, it has the option of saving messages to a log file. If I look at that, here are its contents:

11:01:31.937 Logging started --- Thu May 26 11:01:31 2022 ---
11:01:47.142 lo server running on 13933
11:01:47.144 Saving "/home/maxigaz/Documents/QTractor/Untitled1.auto-save.qts"...
11:01:47.148 Save session: "/home/maxigaz/Documents/QTractor/Untitled1.auto-save.qts".
11:01:47.318 Time for a fast load is 1.759ms load(0.006) class(0.001) spawn(1.752)...
11:01:47.318 making reverse graph[1103]<1.135 ms>
11:01:51.086 Unknown address<BACKEND:online> '/file_list_dirs:'
11:01:51.087 Unknown address<BACKEND:online> '/file_list_files:'
11:01:51.087 Unknown address<BACKEND:online> '/file_list_dirs:'
11:01:51.087 Unknown address<BACKEND:online> '/file_list_files:'

Edit: After numerous retries, I've been able to reproduce it in Ardour. (It doesn't crash, but everything inside Ardour and Zyn-Fusion's window becomes unresponsive.) Here's what I found at the end of the terminal output:

trace (most recent call last):
        [11] (unknown):0
        [10] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:522:in draw
        [9] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:485:in handle_pending_layout
        [8] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:119:in make_draw_sequence
        [7] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:100:in make_draw_sequence_recur
        [6] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/mruby/mrblib/array.rb:17:in each
        [5] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:103:in make_draw_sequence_recur
        [4] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:100:in make_draw_sequence_recur
        [3] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/mruby/mrblib/array.rb:17:in each
        [2] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:108:in make_draw_sequence_recur
        [1] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:232:in to_s
/build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:232:in +: Array cannot be converted to String (TypeError)
[FATAL ERROR] Mruby Is Unable To Continue
Leaked 1 instance(s) of class Synth
Assert failed at /build/sfizz/src/sfizz-1.2.0/src/sfizz/utility/LeakDetector.h:60

[fundamental]

Oh nice, there's the backtrace I was hoping for. The crash is actually in the error printing of a widget which the system failed to lay out.

    def make_draw_sequence_recur(item, xoff, yoff)
        xoff = xoff.to_i
        yoff = yoff.to_i
        if(item && xoff && yoff)
            add(item, xoff, yoff)
            item.children.each do |ch|
                #puts "        Box = <#{ch.class}, #{ch.x.inspect},#{ch.y.inspect},#{ch.w.inspect},#{ch.h.inspect}>"
                if(ch.y && ch.x)
                    make_draw_sequence_recur(ch, xoff+ch.x, yoff+ch.y)
                else
                    puts "[ERROR] X/Y Are Nil"
                    puts "        Relative bounding box = <#{ch.x.inspect},#{ch.y.inspect},#{ch.w.inspect},#{ch.h.inspect}>"
                    puts "        widget.class = <#{ch.class}>"
                    puts "        widget       = <#{ch}>"
                end
            end
        end
    end

which is calling into Qml::Widget's to_s method:

    def to_s(i=0)
        out = ""
        i.times do
            out += " |"
        end
        out += "- <"+widget.class_name()+"##{widget.ui_path}:" + widget.label
        out += ">\n"
        widget.children.each do |x|
            out += x.to_s(i+1)
        end
        out
    end

Which implies a crash at widget.class_name(), widget.ui_path, or widget.label being an array of values rather than a String. Right before the backtrace the system ought to have printed out what layout failure occurred. Specifically:

#This should output
puts "[ERROR] X/Y Are Nil"
#Still should work
puts "        Relative bounding box = <#{ch.x.inspect},#{ch.y.inspect},#{ch.w.inspect},#{ch.h.inspect}>"
#This works based on the backtrace and tells me which specific type to inspect
puts "        widget.class = <#{ch.class}>"
# This is the line where it crashes and it shouldn't output this line based on your backtrace
puts "        widget       = <#{ch}>"

Additionally, what view were you looking at when this crash is triggered? Knowing that along with the widget.class printout should help narrow down the search considerably.

[maxigaz]

It was the default view, the instrument preset browser.

By the way, it has just crashed again in Ardour. I launched it with ardour6 > /tmp/ardour.log because I wanted to redirect all the output to a single file. Now, some messages would still show up in the terminal, while other ones in the newly created file.

Here's what I found in the terminal:

trace (most recent call last):
        [11] (unknown):0
        [10] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:522:in draw
        [9] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:485:in handle_pending_layout
        [8] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:119:in make_draw_sequence
        [7] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:100:in make_draw_sequence_recur
        [6] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/mruby/mrblib/array.rb:17:in each
        [5] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:103:in make_draw_sequence_recur
        [4] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:100:in make_draw_sequence_recur
        [3] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/mruby/mrblib/array.rb:17:in each
        [2] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/draw-sequence.rb:108:in make_draw_sequence_recur
        [1] /build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:232:in to_s
/build/zynaddsubfx/src/zynaddsubfx-mruby-zest-build/src/mruby-widget-lib/mrblib/fcache.rb:232:in +: Array cannot be converted to String (TypeEr
ror)
[FATAL ERROR] Mruby Is Unable To Continue
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
JUCE Assertion failure in juce_Singleton.h:50
[1]    178999 segmentation fault (core dumped)  ardour6 > /tmp/ardour6.log

And here's the contents of the logfile: ardour6.log

[fundamental]

The ardour log indicates that at least 2 SelColumn objects and at least one TextField have not been placed in terms of x/y/w/h positioning. The TextField is unable to serialize to a string which causes the final crash. I do wonder if this is only an issue with ardour providing a layout that can't be satisfied momentarily which makes the crash inconsistent. In that case fixing the issue with TextField would result in the system still displaying an error, but recovering?

[maxigaz]

Speaking of the layout, I don't know if it helps at all, but there's one thing I immediately noticed when I loaded Zyn-Fusion in Qtractor: The UI rescales as I resize its window. This is in contrast with Ardour, where the UI of Zyn-Fusion always remains the same, even if I resize its window. (So, the area between the border window and the UI is filled with empty space.) In Carla, the window can't be resized at all, and I haven't experienced a crash in it yet either.

So I thought this might have something to do with Qtractor crashing a lot more frequently. Although this is just an idea; I'm not a (proficient) programmer and I may be wrong.

[fundamental]

https://github.com/mruby-zest/mruby-zest-build/commit/e263e8db15f97ceaa1c108937415c4f5a8e2bd93 should avoid the crash, which may resolve this issue if you're able to test that change in a newer build.

[maxigaz]

Thank you!

As I wrote in the original post, all the UI was black when I compiled it from source, even after following the build instructions, so I couldn't tell if the bug was present or not. I can give it another try though...

[maxigaz]

It looks like it's working in Ardour. I've been trying to make it crash for several minutes, and I couldn't reproduce it.

However, the UI is still black when I open it in Qtractor. (It only happens in the development build of Zyn-Fusion.) Shall I open a separate issue for that?

[fundamental]

You can, though I currently don't know of a resolution for that issue.

[maxigaz]

After some testing, I could make the VST version work inside Qtractor. (As far as I remember, it would also crash, just like the LV2 version.) I can confirm that it doesn't crash anymore. Thank you very much!