Segmentation Fault when Creating a MIDI Region in 8.12 on CachyOS

Installation & Configuration Linux
#1

This is my first post in this community, but there’s a reason for this:

In 8.12-2.1 (I’m using the CachyOS Extra V3 repo for Ardour), I get a segmentation fault whenever I put in a MIDI instrument and then following up by creating down a MIDI region using the Draw tool.

By the way, I already notified the CachyOS community about it, and it’s this thread in particular.

Using GDB, I was able to backtrace it to a null pointer causing the crash, like so:

(gdb) bt
#0  ARDOUR::DiskWriter::steal_write_source_name[abi:cxx11]() (this=0x5555718ad430) at ../libs/ardour/disk_writer.cc:1418
#1  0x00007ffff78b77b7 in ARDOUR::Track::steal_write_source_name[abi:cxx11]() (this=0x5555718ad430) at ../libs/ardour/track.cc:588
#2  0x00007ffff77cf8fd in ARDOUR::Session::create_midi_source_by_stealing_name (this=0x5555718ad430, track=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x0
#3  0x0000555555f778ee in MidiTimeAxisView::add_region
    (this=0x5555718ad430, f=..., length=..., commit=96) at ../gtk2_ardour/midi_time_axis.cc:1783
#4  0x0000555555c543e5 in Drag::add_midi_region (this=0x5555718ad430, view=0x0, commit=false) at ../gtk2_ardour/editor_drag.cc:620
#5  0x0000555555c58074 in RegionCreateDrag::motion (this=0x55556a097f80, event=0x5555718ad430, first_move=false) at ../gtk2_ardour/editor_drag.cc:2306
#6  0x0000555555c50a9e in Drag::motion_handler () at ../gtk2_ardour/editor_drag.cc:553
#7  DragManager::motion_handler (this=0x555559a57a58, e=0x5555718ad430, from_autoscroll=false) at ../gtk2_ardour/editor_drag.cc:250
#8  0x00007ffff6f7f060 in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator() () at /usr/include/sigc++-2.0/sigc++/signal.h:856
#9  sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>::operator* () at /usr/include/sigc++-2.0/sigc++/signal.h:315
#10 ArdourCanvas::Item::EventAccumulator<bool>::operator()<sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool> > ()
    at ../libs/canvas/canvas/item.h:257
#11 sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit () at /usr/include/sigc++-2.0/sigc++/signal.h:875
#12 sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit () at /usr/include/sigc++-2.0/sigc++/signal.h:2961
#13 sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator() () at /usr/include/sigc++-2.0/sigc++/signal.h:2977
#14 ArdourCanvas::GtkCanvas::deliver_event (this=0x7fffffffceb0, event=0x7fffffffd5a0) at ../libs/canvas/canvas.cc:879
#15 0x00007ffff6f858dc in ArdourCanvas::GtkCanvas::on_motion_notify_event (this=0x7fffffffceb0, ev=0x5555718ad430) at ../libs/canvas/canvas.cc:1279
#16 0x00007ffff6c38038 in Gtk::Widget_Class::motion_notify_event_callback (self=0x7fffffffceb0, p0=0x5555718ad430) at ../libs/tk/ytkmm/widget.cc:4403
#17 0x00007ffff6581ffd in _gtk_marshal_BOOLEAN__BOXED
    (closure=0x7fffffffceb0, return_value=0x5555718ad430, n_param_values=0, param_values=0x0, invocation_hint=0x555571866b60, marshal_data=0x7ffff6c37f40 <Gtk::Widget_Class::motion_notify_event_callback(_GtkWidget*, _GdkEventMotion*)>) at ../libs/tk/ytk/gtkmarshalers.c:84
#18 0x00007ffff5df19b0 in g_closure_invoke (closure=0x555556efea60, return_value=0x7fffffffd7f0, n_param_values=2, param_values=0x7fffffffd880, invocation_hint=0x7fffffffd7d0) at ../glib/gobject/gclosure.c:835
#19 0x00007ffff5e1a930 in signal_emit_unlocked_R.isra.0
    (node=node@entry=0x7fffffffd9a0, detail=detail@entry=0, instance=instance@entry=0x555557d44a40, emission_return=emission_return@entry=0x7fffffffda20, instance_and_params=instance_and_params@entry=0x7fffffffd880) at ../glib/gobject/gsignal.c:3942
#20 0x00007ffff5e1c5aa in signal_emit_valist_unlocked (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at ../glib/gobject/gsignal.c:3547
#21 0x00007ffff5e0b5e9 in g_signal_emit_valist (instance=0x555557d44a40, signal_id=36, detail=0, var_args=0x7fffffffdaf0) at ../glib/gobject/gsignal.c:3277
#22 0x00007ffff5e193dc in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../glib/gobject/gsignal.c:3597
#23 0x00007ffff673af7f in gtk_widget_event_internal (widget=0x7fffffffceb0, event=0x5555718ad430) at ../libs/tk/ytk/gtkwidget.c:5010
#24 0x00007ffff6586c5f in IA__gtk_propagate_event () at ../libs/tk/ytk/gtkmain.c:2446
#25 IA__gtk_propagate_event (widget=0x555557d44a40, event=0x5555718ad430) at ../libs/tk/ytk/gtkmain.c:2383
#26 0x00007ffff658b41b in IA__gtk_main_do_event () at ../libs/tk/ytk/gtkmain.c:1641
#27 0x00007ffff639de52 in gdk_event_dispatch (source=0x7fffffffceb0, callback=0x5555718ad430, user_data=0x0) at ../libs/tk/ydk/x11/gdkevents-x11.c:2425
#28 0x00007ffff6192060 in g_main_dispatch (context=0x5555571abe40) at ../glib/glib/gmain.c:3398
#29 0x00007ffff6193488 in g_main_context_dispatch_unlocked (context=0x5555571abe40) at ../glib/glib/gmain.c:4249
#30 g_main_context_iterate_unlocked (context=0x5555571abe40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4314
#31 0x00007ffff6193acf in g_main_loop_run (loop=0x555557611e00) at ../glib/glib/gmain.c:4516
#32 0x00007ffff658a823 in IA__gtk_main () at ../libs/tk/ytk/gtkmain.c:1213
#33 0x00007ffff6e2101f in Gtkmm2ext::UI::run (this=0x7fffffffceb0, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:305
#34 0x0000555555a19f0f in main (argc=1, argv=0x7fffffffe448) at ../gtk2_ardour/main.cc:471

I’d be happy to attempt building it in the AUR and then seeing if I can recreate this with that package.

Otherwise, I’d be happy to try any recommendation to fix it.

#2

Although this problem doesn’t sound like a video issue, I have had severe random issues when using Wayland/xWayland. I would suggest switching to X11 if possible. Also, Pipewire lead to several issues for me as well. ALSA is stable.

The recommendation is to use Ardour downloaded from Ardour.org as well, as there are also random issues with distribution packaged Ardour installs.

Hope that helps.

#3

Posting LLM-generated text in these forums is a violation of the terms of service. Please delete that part of your post.

This bug is not reproduceable here. Please download the free/demo version from Download Ardour | Ardour Community (you can parallel install it alongside the repo version) and see if that shows the same behavior.

#4

Schmitty, I’m already using X11 (i3) for Ardour. Maybe another WM I have installed could potentially have done something weird.

Paul, I’ve already gone ahead and removed the LLM-generated text per your request. It wasn’t a clear violation as I think the term “machine- or randomly-generated” was too broad. Could you potentially add in “AI-generated” in clear language to the TOS so people don’t make the same mistake I had made?

Update: I had just tested it, and it does happen in the demo version of Ardour as well. It’s the same null pointer that completely destroys any chance of me drawing the MIDI information in said regions.

#5

Are you using ALSA, JACK, or Pipewire ?

#7

Let me try this again:

I’m currently using Pipewire (just bog standard Pipewire). The audio system I’m using is JACK/Pipewire set to 1024 samples by default.

#8

Please describe every step you take, including which plugin instrument you are using.

This does not happen here with 8.12 using the General MIDI synth bundled with Ardour.

#9

Including Paul’s suggestion , I suggest using ALSA and giving it a try. Pipewire caused me several issues, but other users seem to have none. I think the recommended pipewire is any version >= 1.20.

Also, reading about CachyOS (based on Arch) , it ships with some sort of custom optimized kernel, as well as custom optimized packages. There is likely not a lot of CachyOS users that are using Ardour, so this may be related to the optimizations in CachyOS causing these errors, but that is just my guess.

FYI, When I used ARCH linux in the past, Ardour worked well.

#10

I do not think there is any reason to suspect that the audio/MIDI backend is involved in this crash. Ditto for the kernel.

#11

The process goes like this:

  1. I open a project folder (either create it or open an existing one)
  2. I put a MIDI instrument into the instrument stack [that’s the best way I can describe that] (any ol’ MIDI instrument will do, but I was using ACE Fluid Synth and DSK SF2 [a Windows plugin connected using Yabridge], and Sfizz for testing purposes)
  3. I go into Draw mode
  4. I try to click (left click) and drag to make a MIDI region for said instrument
  5. I crash immediately when I start attempting 4

When doing 4, I get a 0x0 null pointer error (this happens even with the official demo) whenever I click and drag to create a new MIDI region.

#12

On my system, I experienced several MIDI and MIDI editing related crashes after switching to Xwayland and using Pipewire 1.05 (because of system update to Ubuntu 24.04 LTS from 22.04 LTS). Switching back to ALSA and XOrg, all of those problems disappeared and Ardour is stable. No crashes unless using plugins with issues. It was likley Pipewire, but I dont want to try Xwayland with ALSA because XOrg has been very very stable.

#13

No way it works with ALSA, and I just tested that.

Such a darn shame too.

I’m testing the AUR package ardour-git on Cachy to see what happens.

#14

Just to be clear, this does work with ALSA?

What version of Pipewire ?

#15

It does not work with also. I’m also using Pipewire 1.4.6.

Also, after testing the git version, that crash is still there. After getting rid of Carla (which I thought caused it) it still crashed.

I might have a backup that could potentially work.

#16

Can you do:

mv ~/.config/ardour8 ~/.config/ardour8-keep

and then retest? As I stated earlier, this does not happen here.

BTW, the “canonical” way of describing step 2 in Ardour would be more like:

“add a MIDI track, using the Foobar plugin as the instrument”

I assume that is what you were doing.

#17

Testing anything from actual ardour git (i.e. the current master branch) is not recommended right now.

#18

During the last presentation (jack autoune) at the Linux Audio Conference, I’ve seen two Ardour 8.12 crashes by pipewire users when doing JACK MIDI connections. I think it happens when conning a single MIDI port to multiple others. But we didn’t have time to debug (other JACK apps also crashed).

Later during conference dinner the Studio One Linux dev also mentioned seeing similar crashes in S1 (which uses wayland natively). So there is anecdotal evidence that is is recent pipewire regression related to MIDI.

–

The backtrace shows clearly why Ardour crashes (midi_write_source is NULL), but it does not explain how this can happen. By reading code, I also cannot [yet] find a reason how pipewire could influence this either.

Are you using JACK transport? Do you connect a given MIDI port to many other MIDI ports or vice versa?

#19

I’m using ALSA to do this, Robin. I never used JACK transport in my workflow.

#20

Step 2 is me adding in ACE Fluid Synth in that test I believe.

Also, testing it with a new config doesn’t help either.