Segfault at startup of both Seq64rtmidi and Seq64qt5

[jeroenrijckaert]

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?

[ahlstromcj]

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.

[jeroenrijckaert]

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.

[jeroenrijckaert]

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.

[ahlstromcj]

Odd. The "ryzen5" refers to an older AMD Ryzen CPU, I think. It looks like there have been some compiler and stability issues with Ryzen over the year.

You might try adding something like this to CFLAGS in configure.ac:

CFLAGS="-O2 -march=haswell"

See if it builds and run better. If not...

... make sure you do this (depending when you last pulled the latest):

$ ./bootstrap --full-clean
$ git checkout midi_control
$ git pull
$ ./bootstrap -ed
$ make &> make.log

(I had fixed some errors based on other GitHub issue reports.)

If it crashes, run it from gdb:

$ gdb ./Seq64rtmidi/seq64
(gdb) r
[crash!!!]
(gdb) bt

Then copy the backtrace text (especially the frames close to frame 0) to a file and post it. If it doesn't crash, ....

BTW, what version of Linux are you using?

-------- Jeroen Rijckaert 03:58 Sat 21 Mar --------

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.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/191#issuecomment-602027025

-- I myself have dreamed up a structure intermediate between Dyson spheres and planets. Build a ring 93 million miles in radius -- one Earth orbit -- around the sun. If we have the mass of Jupiter to work with, and if we make it a thousand miles wide, we get a thickness of about a thousand feet for the base.

And it has advantages. The Ringworld will be much sturdier than a Dyson sphere. We can spin it on its axis for gravity. A rotation speed of 770 m/s will give us a gravity of one Earth normal. We wouldn't even need to roof it over. Place walls one thousand miles high at each edge, facing the sun. Very little air will leak over the edges.

Lord knows the thing is roomy enough. With three million times the surface area of the Earth, it will be some time before anyone complains of the crowding. -- Larry Niven, "Ringworld"

[jeroenrijckaert]

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 )

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 ()

[ahlstromcj]

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.

[ahlstromcj]

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.

[jeroenrijckaert]

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 ) 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 ()

[ahlstromcj]

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

[jeroenrijckaert]

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

[ahlstromcj]

I have changed configure.ac to set up "uname -srm" which is much simpler and hopefully doesn't contain nasty characters to screw up libtool and automake.

-------- Jeroen Rijckaert 17:32 Thu 09 Apr --------

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

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/191#issuecomment-611652110

-- drug, n: A substance that, injected into a rat, produces a scientific paper.

[jeroenrijckaert]

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?

[jeroenrijckaert]

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.

[ahlstromcj]

Can you double-check on your system if "uname -srm" works? It's a lot less verbose than "uname -a". Thanks!

-------- Jeroen Rijckaert 17:32 Thu 09 Apr --------

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

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/191#issuecomment-611652110

-- Time to be aggressive. Go after a tattooed Virgo.

[ahlstromcj]

I just rebuilt; the issue is even worse than that! Somehow a bad bug slipped in. Some time after Feb 24!

-------- Jeroen Rijckaert 03:32 Wed 15 Apr --------

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.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/191#issuecomment-613958127

-- FORCE YOURSELF TO RELAX!

[jeroenrijckaert]

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.

[ahlstromcj]

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).

[jeroenrijckaert]

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.

[ahlstromcj]

Hmmm, sound like a round-off or scrolling issue. Will check it out.

-------- Jeroen Rijckaert 10:55 Sun 19 Apr --------

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.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/sequencer64/issues/191#issuecomment-616195640

-- Celebrity Schadenfreude: Lurid thrills derived from talking about celebrity deaths. -- Douglas Coupland, "Generation X: Tales for an Accelerated Culture"