Bug 289714 - audio/ardour: does not start on Rel. 14.3
Summary: audio/ardour: does not start on Rel. 14.3
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-20 14:22 UTC by Peter Much
Modified: 2026-06-09 23:07 UTC (History)
6 users (show)

See Also:
dev: maintainer-feedback+


Attachments
jack graph (108.67 KB, image/png)
2025-09-20 23:15 UTC, Peter Much
no flags Details
backtrace at crash (7.41 KB, text/plain)
2025-09-22 00:48 UTC, Peter Much
no flags Details
A working config file (15.09 KB, application/xml)
2026-01-07 14:20 UTC, Stellan Alm
no flags Details
Bad config after start/close (15.09 KB, application/xml)
2026-01-07 14:22 UTC, Stellan Alm
no flags Details
correction for Makefile: options and mathflags (1.12 KB, patch)
2026-02-03 00:31 UTC, Peter Much
no flags Details | Diff
patch for comment 12, item 3 (439 bytes, patch)
2026-02-03 00:34 UTC, Peter Much
no flags Details | Diff
patch for comment 12, item 4 (417 bytes, patch)
2026-02-03 00:35 UTC, Peter Much
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Much 2025-09-20 14:22:14 UTC
After upgrading Rel. 13.5 -> 14.3 (and recompiling all ports). ardour-8.12 does not start and instead does coredump at seemingly arbitrary places.

The first start (on a previous project) did work, but there was an artifact in the display graphics (one of the VU meters was apparently broken and locked to the end of scale). I then removed all configurations (and destroyed the old project which sadly is not in the backup, so we cannot test this anymore). From then on it was no longer possible to start: the program would query the basic information, would ask for a previous project to select, and would then crash while building the GUI.

I tried my locally built package and also the one from public pkg-repo.
I also tried to install ardour8 on a different machine for comparison, but on that machine jackd does also no longer start since upgrade to Rel.14, so I didn't get that far.

This is how the crashes look:

Loading ui configuration file /usr/local/etc/ardour8/clearlooks.rc
Found nothing along /home/pmc/.config/ardour8/templates:/usr/local/share/ardour8/templates
Process 55728 stopped
* thread #1, name = 'ardour-8.12.0', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0)
    frame #0: 0x00000008293e5f35 libardour.so.3`ARDOUR::Session::state(bool, ARDOUR::Session::snapshot_t, bool, bool) const + 4133
libardour.so.3`ARDOUR::Session::state:
->  0x8293e5f35 <+4133>: cmpq   %r12, (%rax)
    0x8293e5f38 <+4136>: movq   %rax, %r12
    0x8293e5f3b <+4139>: jne    0x8293e5f30    ; <+4128>
    0x8293e5f3d <+4141>: jmp    0x8293e5c60    ; <+3408>

Loading ui configuration file /usr/local/etc/ardour8/clearlooks.rc
Found nothing along /home/pmc/.config/ardour8/templates:/usr/local/share/ardour8/templates
Process 55966 stopped
* thread #1, name = 'ardour-8.12.0', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0)
    frame #0: 0x0000000826397204 libardour.so.3`ARDOUR::Automatable::get_automation_xml_state() const + 580
libardour.so.3`ARDOUR::Automatable::get_automation_xml_state:
->  0x826397204 <+580>: cmpq   %r13, (%rax)
    0x826397207 <+583>: movq   %rax, %r13
    0x82639720a <+586>: jne    0x826397200    ; <+576>
    0x82639720c <+588>: jmp    0x826397050    ; <+144>

Loading ui configuration file /usr/local/etc/ardour8/clearlooks.rc
Found nothing along /home/pmc/.config/ardour8/templates:/usr/local/share/ardour8/templates
Process 55790 stopped
* thread #1, name = 'ardour-8.12.0', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0)
    frame #0: 0x000000082ac2ca73 libpbd.so.4`___lldb_unnamed_symbol2415 + 35
libpbd.so.4`___lldb_unnamed_symbol2415:
->  0x82ac2ca73 <+35>: testb  $0x1, (%rsi)
    0x82ac2ca76 <+38>: je     0x82ac2ca9f    ; <+79>
    0x82ac2ca78 <+40>: movq   0x10(%r14), %rax
    0x82ac2ca7c <+44>: testl  %ecx, %ecx
Comment 1 Peter Much 2025-09-20 23:15:05 UTC
Created attachment 263956 [details]
jack graph

This is how far we get, in jackd
Comment 2 Florian Walpen 2025-09-21 22:01:41 UTC
Hi Peter, thanks for all the info. I can replicate this currently on 14.3-RELEASE. Not sure how long this problem exists, but I didn't notice anything like that back in July. Unfortunately I'm very busy at the moment, it'll take some time for me to investigate.
Comment 3 Peter Much 2025-09-22 00:48:57 UTC
Created attachment 263973 [details]
backtrace at crash
Comment 4 Peter Much 2025-09-22 01:12:01 UTC
Hi Florian, 

 in the meantime I could obtain a backtrace that seems to be a bit more interesting (attached).
Also I got jackd running on the other machine - but then things also crash there.

Finally, I built ardour-8.10.0, and that did also crash. And those even older didn't want to compile so easily.
Comment 5 Stellan Alm 2026-01-07 14:18:09 UTC
Hi,

I run latest packages on:
FreeBSD freesbie 15.0-RELEASE FreeBSD 15.0-RELEASE releng/15.0-n280995-7aedc8de6446 GENERIC amd64

directly on HW: Lenovo Thinkpad P15v gen2. 


Before the update to from FreeBSD version 14.3 and to Ardour8.12, I could use Ardour.

So debugging using the method described in
https://ardour.org/debugging_ardour.html, isn't not helpful.


What I discovered is that a lot of values in both config and session files gets a default value="inf. 

So I can't start Ardour without a "good" config.

Booted into a Linux distro, downloaded ardour 8.12, started it.
Took that config into to my freebsd, adjusted it and voila, Ardour started.
But by starting and closing Ardour without saving the session, config gets corrupted and can't start Ardour again:
---------------------8<---------------------------------
WARNING: Your system has a limit for maximum amount of locked memory!
         This might cause Ardour to run out of memory before your system runs
         out of memory. You can view the memory limit with 'ulimit -l', and it
         is normally controlled by /etc/security/limits.conf

Ardour8.12.0 (built using 8.12 and GCC version FreeBSD Clang 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2))
Ardour: [INFO]: Your system is configured to limit Ardour to 1877607 open files
Ardour: [INFO]: Loading system configuration file /usr/local/etc/ardour8/system_config
Ardour: [INFO]: Loading user configuration file /home/stellan/.config/ardour8/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: AVX512F capable processor
Ardour: [INFO]: CPU brand: 11th Gen Intel(R) Core(TM) i9-11950H @ 2.60GHz
Ardour: [INFO]: Using AVX512F optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/local/share/ardour8/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/stellan/.config/ardour8/plugin_metadata/plugin_stats
Ardour: [INFO]: add_lrdf_data '/home/stellan/.config/ardour8/rdf:/usr/local/share/ardour8/rdf:/usr/local/share/ladspa/rdf:/usr/share/ladspa/rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/local/share/ladspa/rdf/ladspa-rubberband.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/local/share/ladspa/rdf/ladspa.rdfs'
Cannot xinstall SIGPIPE error handler
Ardour: [INFO]: Loading default ui configuration file /usr/local/etc/ardour8/default_ui_config
Ardour: [INFO]: Loading 461 MIDI patches from /usr/local/share/ardour8/patchfiles
Ardour: [INFO]: Loading user ui configuration file /home/stellan/.config/ardour8/ui_config
Ardour: [INFO]: Loading color file /usr/local/share/ardour8/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /usr/local/etc/ardour8/clearlooks.rc
Ardour: [INFO]: Loading bindings from /usr/local/etc/ardour8/ardour.keys
Loading ui configuration file /usr/local/etc/ardour8/clearlooks.rc
Found nothing along /home/stellan/.config/ardour8/templates:/usr/local/share/ardour8/templates
[1]    12554 segmentation fault (core dumped)  ardour8

---------------------8<---------------------------------

But by restoring the "good config" it starts.
 $ cp ~/.config/ardour8/config_good/config ~/.config/ardour8/

Sensing that xml tag containg value="inf" is a default value not set, both in config and session *.ardour, that it is this that is the culprit.



So in order to go deeper into this, I will try to find a way to build ardour 8.12 locally with debug enabled. But here I need som pointers, since I'm using latest packages.
Comment 6 Stellan Alm 2026-01-07 14:20:17 UTC
Created attachment 266894 [details]
A working config file
Comment 7 Stellan Alm 2026-01-07 14:22:44 UTC
Created attachment 266895 [details]
Bad config after start/close

After starting ardour and closing the session, config gets bad values.
Comment 8 Peter Much 2026-01-17 22:03:50 UTC
(In reply to Stellan Alm from comment #6)
Thanks for the config! :)

At some point I tried to do traditional source code debugging, and that ended in the system libraries for the C++; there is an algorithm called "red-black-tree", and that is apparently how Ardour keeps track of their internal objects. And that is what crashes.
Now why there is bogus data created and inserted into there the first place, that might still be a different reason.

But this needs somebody accustomed to C++ debugging, and sadly I'm not.
Comment 9 Stellan Alm 2026-01-26 16:35:39 UTC
Finally got into the mood:

Cloned the src from  https://github.com/Ardour/ardour switched 
to tag  'releases/8.12'

Look into https://ardour.org/development.html

Patched files:

Mode	Name	Size	
-rw-r--r--	patch-libs_aaf_utils.c	330	logplainblame
-rw-r--r--	patch-libs_vst3_pluginterfaces_base_fplatform.h	474	logplainblame

Used the the options in Makefile
--optimize --ptformat --freedesktop --no-phone-home \
	--with-backends=jack,dummy --internal-shared-libs --no-ytk 

$ ./waf configure --cxx17 --boost-include=/usr/local/include -optimize --ptformat --freedesktop --no-phone-home --with-backends=jack,dummy --internal-shared-libs --no-ytk --prefix=/home/stellan/Programs/ardour

Builds just fine, and now works ... 

In the Makefile there is a --cxx14 argument, but not in the configure part.

So the question is, what is the difference from this build and the packaging?
Comment 10 Peter Much 2026-01-27 19:10:00 UTC
(In reply to Stellan Alm from comment #9)

I tried Your approach, but wasn't so lucky. Compiling did work, but the result would hang in an endless loop even before reaching the crash point, looping over _umtx_op(2).

I then searched for the difference, and it is because I did cut+paste Your invocation of waf configure. There the -optimize is written with a single dash, instead of two dashes as in the port Makefile.

waf seems to interpret this as single-letter options, which are apparently all meaningless (and it doesn't bother to report invocation errors :( ). 

So this is practically like --optimize not being set, which removes various compiler optimization features and changes some -Defines. 
And also -O3 is changed to -O0, and that is what introduces my umtx loop.
Even with -O1 I would get further (and then always crash), so this is most likely a timing issue with the unoptimized code.

With no way further I then tried to build with gcc, and fulminantly failed, learning something about incompatible linker symbols in c++ :/

So, sadly no clue received - probably not a compile time option (as I tried many of them in the process), but there might still be whatever prereq difference 
responsible for the crashes.
Comment 11 Peter Much 2026-01-28 08:36:04 UTC
(In reply to Stellan Alm from comment #5)
You wrote: "a lot of values in both config and session files gets a default value="inf. 

I started debugging my endless loop on startup. It became clear that the _umtx_op(2) are not the problem. They are just part of normal talk to the jack server.

The loop is in another thread that is building the GUI. That thread sets an initial value, but the debugger shows that value then as NaN (which is the same as "inf"). 

There is a problem with float variables.
Comment 12 Peter Much 2026-02-03 00:26:12 UTC
I solved a couple of issues now:

1. When building with -O0 (and maybe also -O1), there are no 
   crashes and apparently no problem.
   However, compiling with -O0 is not working straightforward.
   The port Mk environment will stop configuring -02 when WITH_DEBUG
   is choosen, and the waf configurator will stop configuring -O3
   when --optimize is not selected. But without --optimize waf
   will also remove all CFLAGS and the --arch switches, and then
   compilation does fail because it doesn't find SSE functions.
   Setting waf to --keepflags preserves the CFLAGS, but not the
   --arch switches.
   Therefore the SSE switches need to go into CFLAGS, and WITH_DEBUG
   should switch from --optimize to --keepflags.

2. The actual cause for the crashes is related to math optimization.
   The waf configurator will automatically set -ffast-math when
   --optimize is choosen, and that causes the 'inf' values to get
   into the user configuration file. Then at the next program start
   crashes or hangs or other strange things will result.
   The compile already emits warnings that the settings concerning
   infinity  lead to "undefined behaviour".
   The issue can be fixed by adding -fno-finite-math-only. This one
   must go into the --arch settings, because it is only needed with
   --optimize, and it must be placed after -fmath-only (CFLAGS are
   before).

3. There is more than one crash reason on startup. The known crash
   that happens in the red-black-tree within the c++ library comes
   from 'inf' Values in the user configuration. 
   But another crash happens even before, and only when there is
   no user configuration file present yet (and only when compiler
   optimization is in effect). This crash happens at the time when
   the first connection is requested from jack, for unknown reasons.
   The user configuration is then already half written, and
   subsequently starting the program again is then successful.
   I didn't investigate what causes this, but after surrounding
   the problematic function code with #pragma optimize off, the
   problem didn't reappear.

4. There is another bug when terminating the programm: it will not
   terminate and has to be killed.
   This happens independent from optimization and is because some
   USB hotplug thread does not return and is waited for indefinitely.
   It can be avoided by adding a missing invocation of
   libusb_interrupt_event_handler(3) at the proper place.

5. Then there is another crash happening in the Routing Grid, when
   moving the mouse around, somehow appears a bogus channel number
   -1 for the highlighting.
   This one is also related to optimization and -ffast-math, and
   goes away when additionally setting -fsigned-zeros.
Comment 13 Peter Much 2026-02-03 00:31:10 UTC
Created attachment 267715 [details]
correction for Makefile: options and mathflags
Comment 14 Peter Much 2026-02-03 00:34:35 UTC
Created attachment 267716 [details]
patch for comment 12, item 3
Comment 15 Peter Much 2026-02-03 00:35:06 UTC
Created attachment 267717 [details]
patch for comment 12, item 4
Comment 16 Stellan Alm 2026-02-03 20:37:35 UTC
(In reply to Peter Much from comment #12)
Very well done! 

I discover almost the same aspect that you're pointing out here,
but didn't get this far as you have. So I have working copy now, that accidentally had the erroneous flag '-optimize', which lead me to believe that optimization is somewhat that culprit.

C++ well it is challenging, depending examples that gives warning during build related to floating-points:
---------------8<----------------------------------
In file included from ../libs/ardour/export_profile_manager.cc:45:
In file included from ../libs/ardour/ardour/export_handler.h:36:
In file included from ../libs/ardour/ardour/session.h:86:
In file included from ../libs/ardour/ardour/monitor_processor.h:38:
../libs/ardour/ardour/dB.h:40:30: warning: use of infinity is undefined behavior due to the currently enabled floating-point options [-Wnan-infinity-disabled]
   40 |         if (coeff < 1e-15) return  -std::numeric_limits<float>::infinity();
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../libs/ardour/export_profile_manager.cc:303:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
  303 |         return set_global_state (root) & set_local_state (root);
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                        &&
../libs/ardour/export_profile_manager.cc:303:9: note: cast one or both operands to int to silence this warning
../libs/ardour/export_profile_manager.cc:309:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
  309 |         return init_filenames (root.children ("ExportFilename")) &
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                  &&
  310 |                init_formats (root.children ("ExportFormat"));
      |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../libs/ardour/export_profile_manager.cc:309:9: note: cast one or both operands to int to silence this warning
../libs/ardour/export_profile_manager.cc:316:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
  316 |         return init_timespans (root.children ("ExportTimespan")) &
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                  &&
  317 |                init_channel_configs (root.children ("ExportChannelConfiguration"));
      |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../libs/ardour/export_profile_manager.cc:316:9: note: cast one or both operands to int to silence this warning
5 warnings generated.

In file included from ../libs/ardour/audioengine.cc:41:
In file included from ../libs/pbd/pbd/pthread_utils.h:49:
In file included from ../libs/pbd/pbd/signals.h:38:
In file included from /usr/local/include/boost/noncopyable.hpp:15:
In file included from /usr/local/include/boost/core/noncopyable.hpp:12:
In file included from /usr/local/include/boost/config.hpp:48:
/usr/local/include/boost/config/stdlib/libcpp.hpp:98:11: warning: 'BOOST_NO_AUTO_PTR' macro redefined [-Wmacro-redefined]
   98 | #  define BOOST_NO_AUTO_PTR
      |           ^
<command line>:14:9: note: previous definition is here
   14 | #define BOOST_NO_AUTO_PTR 1
      |         ^
In file included from ../libs/ardour/audioengine.cc:66:
In file included from ../libs/ardour/ardour/rc_configuration.h:31:
In file included from ../libs/ardour/ardour/utils.h:41:
../libs/ardour/ardour/dB.h:40:30: warning: use of infinity is undefined behavior due to the currently enabled floating-point options [-Wnan-infinity-disabled]
   40 |         if (coeff < 1e-15) return  -std::numeric_limits<float>::infinity();
---------------------------------------8<------------------------------

Another aspect that I encountered is if a value is "inf", that division by zero my occur, but that is only happening if if it is not set or 0 :-) :
---------------------------------------8<----------------------
Integer divide by zero.
0x0000000001009ac6 in Editor::set_timecode_ruler_scale (this=0x822624040, lower=0, upper=3710976)
    at ../gtk2_ardour/editor_rulers.cc:854
854			const samplecnt_t hours_in_range = range / (60 * 60 * fr);
Comment 17 Stellan Alm 2026-02-04 06:15:29 UTC
(In reply to Peter Much from comment #12)
On my latest updated RELEASE-15, using latest packages.
Running wayland, labwc with Xfce.

By using your suggestions, 
I successfully built, tested some of my old projects,
Made a couple of new, added both analogue, midi tracks.
Added plugins...

And it works.

Due to Wayland.some plugins crashes, but using generic 
Controls it still works.
Comment 18 Roger Olofsson 2026-04-13 19:41:30 UTC
- RELEASE-15 with xorg and mate
- using latest packages and no previous install of Ardour - ie no old configs

pkg ardour-8.12.0_3 core dumps when connecting to engine pkg jackit-1.9.22_3

jackit is run as user jackd -R -doss -r48000 -p1024 -C /dev/dsp1 -P /dev/dsp1 and says 

Cannot read socket fd = 8 err = No such file or directory
JackGraphManager::Connect already connected port_src = 11 port_dst = 3
JackGraphManager::Connect already connected port_src = 12 port_dst = 4
JackGraphManager::Connect already connected port_src = 25 port_dst = 3
JackGraphManager::Connect already connected port_src = 26 port_dst = 4
JackGraphManager::Connect already connected port_src = 1 port_dst = 5
JackGraphManager::Connect already connected port_src = 2 port_dst = 5
JackEngine::XRun: client = ardour was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error

above 2 lines line repeated until below repeats

Cannot write socket fd = 9 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = ardour notification = 12 val1 = 1 val2 = 5
Cannot write socket fd = 9 err = Broken pipe

Where notification is 12 or 10 and val 1 spans 1-25 and val 2 spans 5-0.
Comment 19 Roger Olofsson 2026-04-21 13:13:06 UTC
(In reply to Roger Olofsson from comment #18)

Ok, so I grabbed the patches from #13, #14 and #15 and the config from #6, built ardour, edited the paths in the config and it runs now.

Ignore my previous comment #18 please.

/Roger
Comment 20 Benjamin Bradshaw 2026-06-09 23:07:56 UTC
Hello,
I'm pretty new to this, but hoping I can help out in a small way. I applied the patches but still ran into some troubles with inf values. I found some more files that specify -ffast-math that I think were giving me problems (turned out I had ui_config inf values for a while that may have blocked the effectiveness of my other attempts). Here they are:

wscript
libs/zita-convolver/wscript
libs/zita-resampler/wscript

I'm not sure if those also need to be patched to remove ffast-math, but so far I think it's working better.

Thanks to those who started all of this, it helped me a lot.