This is a brief report on "audio/ardour6" package/port. On a FreeBSD 12.2-RELEASE amd64 system which is set up to use the "latest" package set, audio/ardour6 (6.5.0) began to crash on startup after a recent "pkg upgrade". Running ardour6 with --lldb flag seemed to indicate there's something wrong with calls to the functions in devel/serd, which had just been upgraded from 0.30.6 to 0.30.8. (I'm not sure where the root cause is) So I tried downgrading devel/serd to 0.30.6 using a cached pkg in /var/cache/pkg. After that, ardour6 started working again. ENVIRONMENT - FreeBSD 12.2-RELEASE-p2 amd64 GENERIC using the latest packages "usr/local/etc/pkg/repos/FreeBSD.conf" has the following config. FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest" } - xfce4 desktop (4.16) HOW TO REPRODUCE 1. Install ardour6 from the latest package set. I confirmed the issue with the following version combination. audio/ardour6-6.5.0 devel/serd-0.30.8 I also built those versions from the ports r561761 and confirmed they had the same issue. 2. Launch ardour6. When trying to open a session (new or existing), the application crashes and dumps core. ADDITIONAL INFORMATION - I also noticed audio/muse-sequencer had the same issue/workaround. - lldb backtraces of ardour6 and muse3 (muse-sequencer). Ardour6 * thread #1, name = 'ardour-6.5.0', stop reason = signal SIGSEGV: invalid address (fault address: 0x7229000) * frame #0: 0x00000008041c2025 libc.so.7`memset + 213 frame #1: 0x0000000803bf15c6 libserd-0.so.0`___lldb_unnamed_symbol4$$libserd-0.so.0 + 102 frame #2: 0x0000000803bfb403 libserd-0.so.0`serd_reader_read_file_handle + 51 frame #3: 0x0000000803bfb394 libserd-0.so.0`serd_reader_read_file + 68 frame #4: 0x0000000803bca467 liblilv-0.so.0`___lldb_unnamed_symbol91$$liblilv-0.so.0 + 231 frame #5: 0x0000000803bca66a liblilv-0.so.0`lilv_world_load_bundle + 218 frame #6: 0x0000000801e05320 libardour.so.3`LV2World::load_bundled_plugins(bool) + 624 frame #7: 0x0000000801e0635d libardour.so.3`ARDOUR::LV2PluginInfo::discover() + 61 frame #8: 0x0000000801c07fac libardour.so.3`ARDOUR::PluginManager::lv2_refresh() + 172 frame #9: 0x0000000801c066ea libardour.so.3`ARDOUR::PluginManager::refresh(bool) + 730 frame #10: 0x0000000000f065a4 ardour-6.5.0`___lldb_unnamed_symbol16512$$ardour-6.5.0 + 276 frame #11: 0x0000000000f03f95 ardour-6.5.0`___lldb_unnamed_symbol16503$$ardour-6.5.0 + 437 frame #12: 0x0000000803352e0b libgtkmm-2.4.so.1`___lldb_unnamed_symbol39$$libgtkmm-2.4.so.1 + 123 frame #13: 0x0000000802460ced libgobject-2.0.so.0`g_closure_invoke + 189 frame #14: 0x0000000802476856 libgobject-2.0.so.0`___lldb_unnamed_symbol241$$libgobject-2.0.so.0 + 2438 frame #15: 0x000000080247745b libgobject-2.0.so.0`g_signal_emit_valist + 2219 frame #16: 0x0000000802477b16 libgobject-2.0.so.0`g_signal_emit + 134 frame #17: 0x0000000000e8a5f4 ardour-6.5.0`___lldb_unnamed_symbol15676$$ardour-6.5.0 + 52 frame #18: 0x000000080340107f libgtkmm-2.4.so.1`___lldb_unnamed_symbol222$$libgtkmm-2.4.so.1 + 111 frame #19: 0x0000000802871268 libgtk-x11-2.0.so.0`___lldb_unnamed_symbol2164$$libgtk-x11-2.0.so.0 + 104 frame #20: 0x0000000802460ced libgobject-2.0.so.0`g_closure_invoke + 189 frame #21: 0x0000000802476602 libgobject-2.0.so.0`___lldb_unnamed_symbol241$$libgobject-2.0.so.0 + 1842 frame #22: 0x00000008024774b7 libgobject-2.0.so.0`g_signal_emit_valist + 2311 frame #23: 0x0000000802477b16 libgobject-2.0.so.0`g_signal_emit + 134 frame #24: 0x00000008029aa364 libgtk-x11-2.0.so.0`___lldb_unnamed_symbol4581$$libgtk-x11-2.0.so.0 + 676 frame #25: 0x000000080286f3c2 libgtk-x11-2.0.so.0`gtk_propagate_event + 322 frame #26: 0x000000080286f083 libgtk-x11-2.0.so.0`gtk_main_do_event + 1171 frame #27: 0x0000000802adbe71 libgdk-x11-2.0.so.0`___lldb_unnamed_symbol499$$libgdk-x11-2.0.so.0 + 81 frame #28: 0x0000000802569487 libglib-2.0.so.0`g_main_context_dispatch + 327 frame #29: 0x000000080256984a libglib-2.0.so.0`___lldb_unnamed_symbol122$$libglib-2.0.so.0 + 538 frame #30: 0x0000000802569b8f libglib-2.0.so.0`g_main_loop_run + 239 frame #31: 0x000000080286e91f libgtk-x11-2.0.so.0`gtk_main + 191 frame #32: 0x00000008021887e4 libgtkmm2ext.so.0`Gtkmm2ext::UI::run(Receiver&) + 244 frame #33: 0x0000000000b317fd ardour-6.5.0`___lldb_unnamed_symbol9265$$ardour-6.5.0 + 2077 frame #34: 0x00000000006e410f ardour-6.5.0`___lldb_unnamed_symbol1$$ardour-6.5.0 + 271 Muse3 (muse-sequencer) * thread #1, name = 'muse3', stop reason = signal SIGSEGV: invalid address (fault address: 0x1030c000) * frame #0: 0x0000000803e7c025 libc.so.7`memset + 213 frame #1: 0x00000008021e35c6 libserd-0.so.0`___lldb_unnamed_symbol4$$libserd-0.so.0 + 102 frame #2: 0x00000008021ed403 libserd-0.so.0`serd_reader_read_file_handle + 51 frame #3: 0x00000008021ed394 libserd-0.so.0`serd_reader_read_file + 68 frame #4: 0x00000008013d6467 liblilv-0.so.0`___lldb_unnamed_symbol91$$liblilv-0.so.0 + 231 frame #5: 0x00000008013d666a liblilv-0.so.0`lilv_world_load_bundle + 218 frame #6: 0x00000008013d7ed0 liblilv-0.so.0`___lldb_unnamed_symbol96$$liblilv-0.so.0 + 112 frame #7: 0x00000008013ccef2 liblilv-0.so.0`___lldb_unnamed_symbol28$$liblilv-0.so.0 + 114 frame #8: 0x00000008013d79ec liblilv-0.so.0`lilv_world_load_all + 188 frame #9: 0x000000080094ba6f libmuse_plugin_cache_writer_module.so`MusEPlugin::scanLv2Plugins(MusEPlugin::PluginScanList*, bool, bool) + 1151 frame #10: 0x000000080094da1b libmuse_plugin_cache_writer_module.so`MusEPlugin::checkPluginCacheFiles(QString const&, MusEPlugin::PluginScanList*, bool, bool, bool, QString const&, int, bool) + 2539 frame #11: 0x0000000000285eab muse3`___lldb_unnamed_symbol6$$muse3 + 17387 frame #12: 0x000000000027c10f muse3`___lldb_unnamed_symbol1$$muse3 + 271
I'm sorry to hear that! I'm maintainer of devel/serd and I would revert the version of it to 0.30.6, but I'm relatively new to ports, so I'm not sure about the procedure of downgrading. I'll ask around. Thank you for your report.
(In reply to Goran Mekić from comment #1) Thank you for responding so quickly. I'm not sure if it's the serd package's fault. But wondering what's changed since 0.30.6, I looked at its GitHub repository and found the folowing latest commit interesting. Remove aligned_alloc support https://github.com/drobilla/serd/commit/c4c4ec510dbeff61982e4aee7d1b379539319cd9 I even built the library from that commit and it looks like the issue doesn't occur with the version. This aligned_alloc thing seems to have been added after 0.30.6. Can this cause the trouble like this? It's just a quick thought of a non-developer though. Thank you again for your time and efforts in maintaining the port!
I'm building muse-sequencer and all it's libs with debug symbols to be able to get more info about the problem, but as I don't have beefy machine, it will take some time.
Created attachment 221696 [details] ardour-debug.txt Although it was somewhat obvious it's lilv from original report, I wanted to build everything from scratch with debug symbols and then run it through lldb to get nicer output. As it seams, lilv is broken by new serd. I'll try to come up with the smallest code that breaks in the same way and then report it upstream (drobilla is author of serd and lilv).
The issue is reported upstream: https://gitlab.com/lv2/lilv/-/issues/4
As the fix for this bug is in ports now, should we close this one, wait for build of package to verify it or something else? I guess at least reporter should verify?
(In reply to Goran Mekić from comment #6) I've just reinstalled serd-0.30.8 from the latest ports tree and confirmed lv2ls (from lilv), ardour6 and muse3 (muse-sequencer) ran flawlessly with the patched version of the library! Thank you so much for your really quick and kind support.
Thank you for keeping an eye on ports :o) I don't have premission to close the issue. Can you do it?
(In reply to Goran Mekić from comment #8) Done. Thanks!