View Issue Details

IDProjectCategoryView StatusLast Update
0009841ardourbugspublic2024-11-06 15:12
Reporterfordfrog Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformgentooOSlinuxOS Version(any)
Product Version8.10 
Summary0009841: ardour 8.10 crashes on startup when compiled with clang
Descriptionin fact this issue with clang is there already for some time. if i compile ardour with clang, it always crashes on startup (session selection/creation window occurs, i chose a new session, the gui loads the main window and then the crash occurs). if i compile it with gcc, no crash occurs.

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
0x00007ffff4ca536c in ?? () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff4ca536c in ??? () at /lib64/libc.so.6
0000001 0x00007ffff4c4f646 in raise () at /lib64/libc.so.6
#2 0x00007ffff4c378fa in abort () at /lib64/libc.so.6
#3 0x00007ffff4c38956 in ??? () at /lib64/libc.so.6
0000004 0x00007ffff4d3106b in __fortify_fail () at /lib64/libc.so.6
0000005 0x00007ffff4d309f6 in __chk_fail () at /lib64/libc.so.6
#6 0x00007ffff4d32839 in __vsnprintf_chk () at /lib64/libc.so.6
#7 0x00007ffff714bd1a in snprintf(char*, unsigned long pass_dynamic_object_size1, char const*, ...) (__s=0x6d3 <error: Cannot access memory at address 0x6d3>, __s@entry=0x55555c913680 "", __n=1747, __n@entry=514, __fmt=0x8 <error: Cannot access memory at address 0x8>) at /usr/include/bits/stdio2.h:80
0000008 0x00007ffff714be76 in ARDOUR::IO::find_port_hole (this=<optimized out>, ports=std::shared_ptr<const ARDOUR::PortSet> (empty) = {...}, base=0x55555eaea6e0 "Click/audio_out") at ../libs/ardour/io.cc:1410
0000009 0x00007ffff7140524 in ARDOUR::IO::build_legal_port_name[abi:cxx11](std::shared_ptr<ARDOUR::PortSet const>, ARDOUR::DataType) (this=0x55555ae91320, ports=std::shared_ptr<const ARDOUR::PortSet> (empty) = {...}, type=...) at ../libs/ardour/io.cc:1386
0000010 0x00007ffff713f321 in ARDOUR::IO::add_port (this=0x55555ae91320, destination="", src=0x55555eabb300, type=...) at ../libs/ardour/io.cc:315
0000011 0x00007ffff73eb08c in ARDOUR::Session::setup_click_state (this=0x55555eabb300, node=<optimized out>) at ../libs/ardour/session.cc:1024
0000012 0x00007ffff73e9e56 in ARDOUR::Session::setup_click (this=0x55555eabb300) at ../libs/pbd/pbd/xml++.h:81
0000013 0x00007ffff73e1909 in ARDOUR::Session::immediately_post_engine (this=0x55555eabb300) at ../libs/ardour/session.cc:627
0000014 0x00007ffff73e5038 in ARDOUR::Session::Session (this=0x55555eabb300, eng=<optimized out>, fullpath="/home/fordfrog/Hudba/Untitled-2024-10-29-16-01-42", snapshot_name=<optimized out>, bus_profile=0x7fffffffb95c, mix_template="", unnamed=<optimized out>, sr=0) at ../libs/ardour/session.cc:398
#15 0x0000555555a86b5c in ARDOUR_UI::build_session_stage_two (this=<optimized out>, path="/home/fordfrog/Hudba/Untitled-2024-10-29-16-01-42", snap_name=<optimized out>, session_template=<optimized out>, bus_profile=<optimized out>, unnamed=<optimized out>, domain=<optimized out>, samplerate=<optimized out>) at ../gtk2_ardour/ardour_ui_session.cc:716
0000016 0x0000555555a818b4 in ARDOUR_UI::build_session (this=0x5555573ee080, path="/home/fordfrog/Hudba/Untitled-2024-10-29-16-01-42", snap_name="Untitled-2024-10-29-16-01-42", session_template="", bus_profile=..., from_startup_fsm=true, unnamed=<optimized out>, domain=<optimized out>) at ../gtk2_ardour/ardour_ui_session.cc:663
#17 0x0000555555a979eb in ARDOUR_UI::load_session_from_startup_fsm (this=0x5555573ee080) at ../gtk2_ardour/ardour_ui_startup.cc:696
0000018 0x0000555555a96e8c in ARDOUR_UI::sfsm_response (this=0x5555573ee080, r=1747) at ../gtk2_ardour/ardour_ui_startup.cc:555
0000019 0x00005555564b4de6 in sigc::internal::signal_emit1<void, StartupFSM::Result, sigc::nil>::emit (impl=<optimized out>, _A_a1=@0x7fffffffbd28: StartupFSM::LoadSession) at /usr/include/sigc++-2.0/sigc++/signal.h:1041
0000020 0x00005555564af5db in sigc::signal1<void, StartupFSM::Result, sigc::nil>::emit (this=<optimized out>, _A_a1=<optimized out>) at /usr/include/sigc++-2.0/sigc++/signal.h:2951
0000021 sigc::signal1<void, StartupFSM::Result, sigc::nil>::operator() (this=<optimized out>, _A_a1=<optimized out>) at /usr/include/sigc++-2.0/sigc++/signal.h:2967
0000022 0x00005555564af5db in StartupFSM::dialog_response_handler ()
0000023 0x00007ffff5a92a2b in ??? () at /usr/lib64/libgtkmm-2.4.so.1
#24 0x00007ffff621b857 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
0000025 0x00007ffff6234d78 in ??? () at /usr/lib64/libgobject-2.0.so.0
0000026 0x00007ffff6233635 in ??? () at /usr/lib64/libgobject-2.0.so.0
0000027 0x00007ffff6233d50 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
0000028 0x00005555564aeea8 in StartupFSM::engine_running (this=<optimized out>) at ../gtk2_ardour/startup_fsm.cc:567
0000029 0x00005555564aeea8 in StartupFSM::start_audio_midi_setup ()
0000030 0x00007ffff5a92a2b in ??? () at /usr/lib64/libgtkmm-2.4.so.1
0000031 0x00007ffff621b857 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
0000032 0x00007ffff6234d78 in ??? () at /usr/lib64/libgobject-2.0.so.0
0000033 0x00007ffff6233635 in ??? () at /usr/lib64/libgobject-2.0.so.0
0000034 0x00007ffff6233d50 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
0000035 0x00005555563eed9b in SessionDialog::open_button_pressed (this=0x5555582d5d40, ev=<optimized out>) at ../gtk2_ardour/session_dialog.cc:560
0000036 0x00007ffff5b2301e in ??? () at /usr/lib64/libgtkmm-2.4.so.1
0000037 0x00007ffff533787a in ??? () at /usr/lib64/libgtk-x11-2.0.so.0
0000038 0x00007ffff621b857 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
0000039 0x00007ffff6234a59 in ??? () at /usr/lib64/libgobject-2.0.so.0
0000040 0x00007ffff623369e in ??? () at /usr/lib64/libgobject-2.0.so.0
0000041 0x00007ffff6233d50 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
0000042 0x00007ffff545a58c in ??? () at /usr/lib64/libgtk-x11-2.0.so.0
0000043 0x00007ffff5335f6c in gtk_propagate_event () at /usr/lib64/libgtk-x11-2.0.so.0
0000044 0x00007ffff53362db in gtk_main_do_event () at /usr/lib64/libgtk-x11-2.0.so.0
0000045 0x00007ffff56f6340 in ??? () at /usr/lib64/libgdk-x11-2.0.so.0
0000046 0x00007ffff656fe9d in ??? () at /usr/lib64/libglib-2.0.so.0
0000047 0x00007ffff657024e in ??? () at /usr/lib64/libglib-2.0.so.0
0000048 0x00007ffff6570569 in g_main_loop_run () at /usr/lib64/libglib-2.0.so.0
0000049 0x00007ffff533518f in gtk_main () at /usr/lib64/libgtk-x11-2.0.so.0
0000050 0x00007ffff680a313 in Gtkmm2ext::UI::run (this=0x5555573ee080, old_receiver=<optimized out>) at ../libs/gtkmm2ext/gtk_ui.cc:305
0000051 0x0000555555f503e1 in main (argc=1, argv=0x7fffffffd098) at ../gtk2_ardour/main.cc:471

i can provide more info if needed. currently i compiled only ardour with debug enabled.
Additional Informationthis is a gentoo linux amd64 system with pipewire-1.2.6. current workaround is not to use clang for compilation.
TagsNo tags attached.

Activities

x42

2024-11-04 18:07

administrator   ~0029101

This is odd, maybe a bug in clang, or maybe some C++20 constexpr related issue.

Does it help if you configure Ardour with ./waf configure --cxx17 .... ?

If that does not help, current/git 9.0-pre0-350 may fix this.

It would however be good to know if earlier git revisions work with --cxx17, since we use a similar concept of directly accessing std::vector data in other places,
and those will also need to be updated otherwise.

fordfrog

2024-11-04 19:26

reporter   ~0029102

i can confirm that ardour from the master git doesn't crash on startup anymore.

i tried --cxx17 with ardour-8.10 but that didn't help in my case. not sure how it's affected by our ebuild (package script). for the purpose of gentoo users i just grabbed the patch (https://github.com/Ardour/ardour/commit/f17a6562174ccf658eb35ba7a425d3ac340c1607) which also resolves the issue for 8.10.

i'll report back if i get more crashes with ardour 8.10 compiled with clang after applying the patch.

x42

2024-11-04 20:28

administrator   ~0029103

We do use clang for macOS since at least 4 years without seeing this issue. Currently clang --version

Apple clang version 16.0.0 (clang-1600.0.26.3)

My current guess is that gentoo has a bleeding edge version of clang, which causes this.

fordfrog

2024-11-04 20:52

reporter   ~0029104

well yes, we're at clang version 19.1.3

fordfrog

2024-11-04 21:11

reporter   ~0029105

so i hit another one, when opening a project:

Thread 37 "AudioEngine 1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdb4006c0 (LWP 30503)]
0x00007ffff7322688 in ARDOUR::PortManager::cycle_start (this=0x5555573b0740, nframes=1024, s=0x55555adf9970) at ../libs/ardour/port_manager.cc:1306
1306 p.second->cycle_start (nframes);
(gdb) bt
#0 0x00007ffff7322688 in ARDOUR::PortManager::cycle_start (this=0x5555573b0740, nframes=1024, s=0x55555adf9970) at ../libs/ardour/port_manager.cc:1306
0000001 0x00007ffff6f8a95b in ARDOUR::AudioEngine::process_callback (this=0x5555573b0740, nframes=1024) at ../libs/ardour/audioengine.cc:356
#2 0x00007fffec1d5e72 in ARDOUR::JACKAudioBackend::process_thread (this=0x55555821db60) at ../libs/backends/jack/jack_audiobackend.cc:929
#3 0x00007fffec1d53ba in ARDOUR::JACKAudioBackend::_process_thread (arg=0x5555792c6e20) at ../libs/backends/jack/jack_audiobackend.cc:904
0000004 0x00007fffed009b46 in ??? () at /usr/lib64/spa-0.2/support/libspa-support.so
0000005 0x00007fffe7e5d398 in ??? () at /usr/lib64/libpipewire-0.3.so.0
#6 0x00007ffff4ca3632 in ??? () at /lib64/libc.so.6
#7 0x00007ffff4d24f3c in ??? () at /lib64/libc.so.6

x42

2024-11-04 21:23

administrator   ~0029106

I cannot find anything wrong in the code there.

Can you try an actually released version of clang. Their latest version is 18.1.8.

If that does not crash then we may have to report this to the clang dev team.

fordfrog

2024-11-04 21:46

reporter   ~0029107

you're right, no crash with 18.1.8

x42

2024-11-06 02:59

administrator   ~0029108

Thanks for checking.

There are over 170 recent open bug reports for "std::vector operator[]" on the LLVM bug tracker.
So for the time being I won't bother to forward this issue upstream.

It's not unheard of that unreleased dev-versions of compilers have bugs and produce code that crashes.

Since the code is valid C++ and works with stable compiles I think we can close this bug.

fordfrog

2024-11-06 07:41

reporter   ~0029110

i just tried both ardour-8.10 (with applied patch) and ardour from the git repo compiled with clang-18.1.8 and none of those crash on startup and everything loads cleanly, so i think this bug can be closed. thank you for the crash fix.

Issue History

Date Modified Username Field Change
2024-10-29 15:17 fordfrog New Issue
2024-11-04 18:07 x42 Note Added: 0029101
2024-11-04 19:26 fordfrog Note Added: 0029102
2024-11-04 20:28 x42 Note Added: 0029103
2024-11-04 20:52 fordfrog Note Added: 0029104
2024-11-04 21:11 fordfrog Note Added: 0029105
2024-11-04 21:23 x42 Note Added: 0029106
2024-11-04 21:46 fordfrog Note Added: 0029107
2024-11-06 02:59 x42 Note Added: 0029108
2024-11-06 07:41 fordfrog Note Added: 0029110
2024-11-06 15:12 fordfrog Status new => closed
2024-11-06 15:12 fordfrog Resolution open => fixed