Segfault at startup of both Seq64rtmidi and Seq64qt5
jeroenrijckaert opened this issue · 19 comments
Cloned git version today (05-01-2019) and with some QT4 vs QT5 issues while building on Slackware I did manage to build both version. But when trying to run these, I immediately get a segmentation fault. I'm running Slackware 14.2 with Linux 4.4.202 and Qt5-5.9.8.
I just found out that the executable files are actually not the binary executable files, but only a wrapper pointing to the real binary files in a hidden directory. Seems a bit over complicated and results in the human readable error messages being hidden. Going into the hidden .lib directory for the Qt version and running the two version of the binary file gives different results:
lt-qseq64
Segmentation fault
qseq64
./qseq64: error while loading shared libraries: libseq_qt5.so.0: cannot open shared object file: No such file or directory
Following instruction from https://gcc.gnu.org/bugs/segfault.html I tried to use GDB for debugging:
(gdb) run
Starting program: /home/jeroen/downloads/sequencer64/Seq64qt5/.libs/lt-qseq64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4020cab in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) ()
from /usr/lib64/gcc/x86_64-slackware-linux/5.5.0/../../../../lib64/libstdc++.so.6
(gdb) where
#0 0x00007ffff4020cab in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) ()
from /usr/lib64/gcc/x86_64-slackware-linux/5.5.0/../../../../lib64/libstdc++.so.6
#1 0x00007ffff45a812b in seq64::rc_settings::rc_settings (this=0x7ffff48066c0 <seq64::g_rc_settings>) at rc_settings.cpp:129
#2 0x00007ffff4575f50 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at settings.cpp:49
#3 0x00007ffff45c5b66 in __do_global_ctors_aux () from /home/jeroen/downloads/sequencer64/libseq64/src/.libs/libseq64.so.0
#4 0x00007ffff7f91b40 in ?? ()
#5 0x00007ffff7ff1af8 in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x00007ffff4569937 in _init () from /home/jeroen/downloads/sequencer64/libseq64/src/.libs/libseq64.so.0
#8 0x00007fffffffdfe8 in ?? ()
#9 0x00007ffff7de761a in call_init.part () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff7de776b in _dl_init () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff7dd7c0a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#12 0x0000000000000001 in ?? ()
#13 0x00007fffffffe2dd in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) list
65 * \param argc
66 * The number of command-line parameters, including the name of the
67 * application as parameter 0.
68 *
69 * \param argv
70 * The array of pointers to the command-line parameters.
71 *
72 * \return
73 * Returns EXIT_SUCCESS (0) or EXIT_FAILURE, depending on the status of
74 * the run.
Is there more I can do to analyse this problem?
You can't really execute libtool (lt-) files directly. Run ./sequencer64/Seq64qt5/qseq64 directly. To avoid libtool, run "./bootstrap --full-clean" and then "./bootstrap -ed -qt", then make it, and see how it runs. What I am worried about is that Slackware has qt libraries that do not have the same function entry points as determined by libtool. Building in debug mode sort of bypasses libtool (--disable-shared). Anyway, a tough issue, and I am also burdened by issues at my day job.
Following your instructions I can now build the qt5 version. But I get a segfault when trying to run the executable.
Thanks for your support. I'm on holidays this week, so can't test further for now.
I tried another build with a fresh copy from git:
./bootstrap -rm
make
While the following warning repeated very often, the build did complete:
"../../libtool: line 85: ryzen5: command not found"
When running the executable in ../Seq64rtmidi I still get a Segmentation fault directly at startup. Is there anything I can do to further analyse this issue? I have libtool-2.4.6 installed.
Using Linux Slackware 14.2 with uname output:
Linux ryzen5 4.4.202 #1 SMP Sat Nov 16 14:15:34 CST 2019 x86_64 AMD Ryzen 5 1500X Quad-Core Processor AuthenticAMD GNU/Linux
Both methods seem to give a segfault. Output for backtrace for option 1 with CFLAGS addition:
0x00007fffeed39cab in std::basic_string<char, std::char_traits, std::allocator >::basic_string(std::string const&) () from /usr/lib64/../lib64/libstdc++.so.6
(gdb) bt
#0 0x00007fffeed39cab in std::basic_string<char, std::char_traits, std::allocator >::basic_string(std::string const&) () at /usr/lib64/../lib64/libstdc++.so.6
#1 0x00000000004e3b84 in seq64::rc_settings::rc_settings() (this=0x8a69e0 seq64::g_rc_settings)
at rc_settings.cpp:129
#2 0x00000000004f6f29 in __static_initialization_and_destruction_0(int, int) (__initialize_p=1, __priority=65535) at settings.cpp:49
#3 0x00000000004f6f71 in _GLOBAL__sub_I__ZN5seq642rcEv() () at settings.cpp:157
#4 0x0000000000523436 in __do_global_ctors_aux ()
#5 0x0000000000000000 in ()
Okay, getting somewhere. Now can you run the app from the console adding the --verbose option, and then post the output. I want to make sure that the crash is happening at startup.
Right now, it looks like an issue in initializing a static instance of a class. I've had to do workarounds for something like that before lately.
Actually no need to post output unless you really want to. Later today I will try a workaround and then check it in for you to check out.
Found a small fix!
Replace "uname -a" with "uname" in the configure files, and the build completes without these errors.
Though still a segfault at startup, also with the --verbose option. Output of gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffeed39cab in std::basic_string<char, std::char_traits, std::allocator >::basic_string(std::string const&) () from /usr/lib64/../lib64/libstdc++.so.6
(gdb) bt
#0 0x00007fffeed39cab in std::basic_string<char, std::char_traits, std::allocator >::basic_string(std::string const&) () at /usr/lib64/../lib64/libstdc++.so.6
#1 0x00000000004e3b84 in seq64::rc_settings::rc_settings() (this=0x8a69e0 seq64::g_rc_settings) at rc_settings.cpp:129
#2 0x00000000004f6f29 in __static_initialization_and_destruction_0(int, int) (__initialize_p=1, __priority=65535) at settings.cpp:49
#3 0x00000000004f6f71 in _GLOBAL__sub_I__ZN5seq642rcEv() () at settings.cpp:157
#4 0x0000000000523436 in __do_global_ctors_aux ()
#5 0x0000000000000000 in ()
If you don't think it a privacy issue, can you post the output of uname -a (in quotes) so I can figure out which character might be killing the build.
Also, I haven't yet checked in my hopeful fix for the segfault. Will try to do that later today. Been kind of distracted :-D
No worries. Output of uname -a:
Linux ryzen5 4.4.202 #1 SMP Sat Nov 16 14:15:34 CST 2019 x86_64 AMD Ryzen 5 1500X Quad-Core Processor AuthenticAMD GNU/Linux
Following some steps from https://discover.cs.ucsb.edu/commonerrors/tutorial/gdbtutorial.html I tried the get some more feedback from gbd:
(gdb) up
#1 0x00000000004e3b84 in seq64::rc_settings::rc_settings (this=0x8a69e0 <seq64::g_rc_settings>) at rc_settings.cpp:129
129 m_recent_files ()
(gdb) print this
$1 = (seq64::rc_settings * const) 0x8a69e0 <seq64::g_rc_settings>
(gdb) print *this
$2 = {m_comments_block = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x8cb268 "(Comments added to this section are preserved. Lines starting with\n a '#' or '[', or that are blank, are ignored. Start lines that must\n be blank with a space.)\n"}},
m_verbose_option = false, m_auto_option_save = true, m_legacy_format = false, m_lash_support = false, m_allow_mod4_mode = false, m_allow_snap_split = false, m_allow_click_edit = true,
m_show_midi = false, m_priority = false, m_stats = false, m_pass_sysex = false, m_with_jack_transport = false, m_with_jack_master = false, m_with_jack_master_cond = false,
m_with_jack_midi = true, m_filter_by_channel = false, m_manual_alsa_ports = false, m_reveal_alsa_ports = false, m_print_keys = false, m_device_ignore = false, m_device_ignore_num = 0,
m_interaction_method = seq64::e_seq24_interaction, m_mute_group_saving = seq64::e_mute_group_preserve, m_filename = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}},
m_jack_session_uuid = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}}, m_last_used_dir = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}},
m_config_directory = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}}, m_config_filename = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}},
m_user_filename = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}}, m_config_filename_alt = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}},
m_user_filename_alt = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}}, m_use_midi_control_file = false, m_midi_control_filename = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}},
m_playlist_active = false, m_playlist_filename = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffeefe8138 <std::string::_Rep::_S_empty_rep_storage+24> ""}},
m_application_name = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
m_app_client_name = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
m_tempo_track_number = 0, m_recent_files = {
m_recent_list = {<std::_Deque_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> = {
_M_impl = {<std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >> = {<__gnu_cxx::new_allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >> = {<No data fields>}, <No data fields>}, _M_map = 0x0, _M_map_size = 0, _M_start = {_M_cur = 0x0, _M_first = 0x0, _M_last = 0x0, _M_node = 0x0}, _M_finish = {_M_cur = 0x0,
_M_first = 0x0, _M_last = 0x0, _M_node = 0x0}}}, <No data fields>}, m_maximum_size = 0}}
Not sure if this is helpful?
Finally I got it working without a SEGFAULT!
Using the midi-control branch, but with the following options:
export CFLAGS="-O2 -pipe -march=native"
./bootstrap -ed -rm
While I do not understand why, the program now does compile and run!
But now it gives a new issue: cannot enter note on first grid place. Not a fatal error, but for me it makes the program very cumbersome/impossible to use. Since the moment I couldn't get Sequencer64 to run, I am using the midi piano roll in Ardour. I'll stick with this until Sequencer64 becomes functional for me again. Hope you find some time to make the program usable enough.
Output of uname -srm is Linux 4.4.202 x86_64 and the building runs without these errors, using the same midi-control branch checkout as before.
I found the bug for editing notes; overzealous parameter checking! A bunch of other minor things in place now in the midi_control branch. Check it out! (Fingers crossed).
Using the midi-control branch of today, with the same CFLAGS options as before:
export CFLAGS="-O2 -pipe -march=native"
./bootstrap -ed -rm
Program starts ok.
Adding notes seems to work correctly.
Now I notice a new strange thing. When moving a selection down, it jumps up 1 note after the mouse is released. This problem does not occur when moving selections up.