search

ahlstromcj / sequencer64

A major reboot of Seq24. Current release 0.97.0 (2021-05-13), native JACK MIDI, Song recording, playlists, and a Windows/Qt version. For fresher code, see the Seq66 project. Note that trigger and mute-group-in-MIDI-file formats have evolved! Back up your work!
GNU Affero General Public License v3.0
237 stars 28 forks source link

Seq64 launching without GUI on ARM (Raspberry Pi) platform #160

Open TDeagan opened 6 years ago

TDeagan commented 6 years ago

I'm hoping for troubleshooting ideas from folk around a problem I'm having with launching seq64 on a Raspberry Pi 3 machine running the most recent release of Raspian (Debian Stretch kernel 4.4).

The problem is, when building seq64 with the advanced build model using either "./bootstrap" or "./bootstrap -er -rm", the app returns the normal set of command line responses (ports, jack stuff, etc.) but doesn't launch a GUI and just sits happily doing nothing until I send it a ctrl-c to kill it. If I build a debug version "./bootstrap -ed -rm" and run it under gdb, everything works fine (GUI appears and runs happily.)

Raspbian runs 'Pixel' (LXDE based) as its window manager. When I run Raspian Desktop, the version of Raspbian that will run in a VirtualBox x86 environment, but still runs Pixel, everything works fine with the release version. So I don't believe the window manager is part of the problem. The identical set of steps that work in x86 don't work in the ARM platform (unless, as noted, I'm running under gdb, where everything works fine everywhere.) Running the release version as a sudo process, or as su, makes no difference.

One possible clue (beyond my ability to assess,) is that, when I run the failing release version, ps -ef returns "/home/pi/sequencer64/Seq64rtmidi/.libs/lt-seq64" as the running process as opposed to the debug version wich reports "/home/pi/sequencer64/Seq64rtmidi/seq64" as the running process.

Thanks for any ideas, I'm continuing to troubleshoot and will try almost anything.

ahlstromcj commented 6 years ago

Looks like a libtool issue. The -ed bootstrap passes --disable-shared to ./configure. Maybe you can just run a plain bootstrap and then run configure to build release and with shared libraries disabled. And keep good notes as I would like to add a Troubleshooting section to the manual. Good luck!

On Thu, Sep 6, 2018, 11:56 Tim Deagan notifications@github.com wrote:

I'm hoping for troubleshooting ideas from folk around a problem I'm having with launching seq64 on a Raspberry Pi 3 machine running the most recent release of Raspian (Debian Stretch kernel 4.4).

The problem is, when building seq64 with the advanced build model using either "./bootstrap" or "./bootstrap -er -rm", the app returns the normal set of command line responses (ports, jack stuff, etc.) but doesn't launch a GUI and just sits happily doing nothing until I send it a ctrl-c to kill it. If I build a debug version "./bootstrap -ed -rm" and run it under gdb, everything works fine (GUI appears and runs happily.)

Raspbian runs 'Pixel' (LXDE based) as its window manager. When I run Raspian Desktop, the version of Raspbian that will run in a VirtualBox x86 environment, but still runs Pixel, everything works fine with the release version. So I don't believe the window manager is part of the problem. The identical set of steps that work in x86 don't work in the ARM platform (unless, as noted, I'm running under gdb, where everything works fine everywhere.) Running the release version as a sudo process, or as su, makes no difference.

One possible clue (beyond my ability to assess,) is that, when I run the failing release version, ps -ef returns "/home/pi/sequencer64/Seq64rtmidi/.libs/lt-seq64" as the running process as opposed to the debug version wich reports "/home/pi/sequencer64/Seq64rtmidi/seq64" as the running process.

Thanks for any ideas, I'm continuing to troubleshoot and will try almost anything.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/160, or mute the thread https://github.com/notifications/unsubscribe-auth/AHnVqKRBq-kwgCogjYNdVoL_Fje10zMcks5uYUWdgaJpZM4WdPCX .

TDeagan commented 6 years ago

Cool! I'll try that tonight. Thanks!! --t

TDeagan commented 6 years ago

Whew, I've been through 8 or 9 builds, but I have it working!

As a note, I blew away my whole directory and started with a new git clone with each rebuild since some of the bootstrap things I was trying (even --full-clean,) didn't change the timestamp on Seq64rtmidi/seq64.

Running vanilla "./bootstrap" and then "./configure --disable-shared" resulted in a very frustrating "segmentation fault" when running "Seq64rtmidi/seq64". However, running "sudo Seq64rtmidi/seq64" works! As another check, I did the "sudo make install" step and verified that seq64 still requires sudo to work.

I haven't tested all the seq64 functionality yet, but I'm thrilled to get to a GUI!

TDeagan commented 6 years ago

Mmmmm. Troubleshooting. It's a lifestyle.

So, after successfully running seq64 multiple times (as sudo,) and testing a variety of functionality (all good so far,) all of a sudden this morning, after killing the seq64 GUI and trying to relaunch, I'm getting the dreaded "segmentation fault" response from the "sudo seq64" (as well as without sudo,) command that was working so well (some when running as su.) I've done a complete power cycle and have nuked the root's copies of sequencer64.rc and sequencer64.usr, but still no love.

I haven't done any permission changes or new installations since it was working previously. The only thing I've done to the system is rearrange the MIDI cables and hook up an external MIDI clock (which was successfully changing the seq64 BPM.) I have pulled the MIDI clock, rebooted and there are no changes to the seg fault response.

More testing to come as I try to get smarter about things to try.

TDeagan commented 6 years ago

Interesting....

After a reboot and power down to work on my arduino MIDI clock (added panel mounted reset switch and an LED on the MIDI send line,) started back up and "sudo seq64" worked!

Ever suspicious, I executed one of the other gadgets in the device. I have a Teensy (kinda like an Arduino,) that is attached to a button and acts as a USB keyboard. When I press the button, it sends keystrokes at the RPi. I use this (currently,) to send a custom MIDI file (aplaymidi -p 20:1 ~/booshbeats/lpad_leds.mid) to my Novation Launchpad to create a custom LED display.

The sequence used to execute the commands directly. I'd open a terminal, send the command and exit (CTRL-ALT-t, aplaymidi -p 20:1 ~/booshbeats/lpad_leds.mid, exit). This worked great so I decided to break it.

Instead of hard-coding a command onto the Teensy, I changed the sequence to: CTRL-ALT-t (open terminal) sh ~/ext_button.sh (execute a script) exit (close terminal)

This should let me do all kinds of crazy with the button without having to make changes on the Teensy itself. The script currently consists of the "aplaymidi -p 20:1 ~/booshbeats/lpad_leds.mid" command.

So... When I rebooted after the arduino surgery, I started a terminal and ran "sudo seq64" and was greeted with the GUI of joy. I then closed seq64, pushed my button, got the coolio LED pattern on my Launchpad and tried "sudo seq64" again. SEGMENTATION FAULT!

I'll try this combo a few times more and mix things up to triple verify.

(BTW, while I always try with and without Jack, I generally run with the --alsa switch since Jack just makes me frustrated and ALSA does everything I need.)

QUICK EDIT - The seg fault problem survives a reboot. I'll have to figure out what's staying alive enough to cause this.

ahlstromcj commented 6 years ago

Perhaps run the same in gdb and grab the output of the "backtrace" (bt) command if it segfaults. Indeed, this seems like a tough nut to crack!

On Sat, Sep 8, 2018, 13:08 Tim Deagan notifications@github.com wrote:

Interesting....

After a reboot and power down to work on my arduino MIDI clock (added panel mounted reset switch and an LED on the MIDI send line,) started back up and "sudo seq64" worked!

Ever suspicious, I executed one of the other gadgets in the device. I have a Teensy (kinda like an Arduino,) that is attached to a button and acts as a USB keyboard. When I press the button, it sends keystrokes at the RPi. I use this (currently,) to send a custom MIDI file (aplaymidi -p 20:1 ~/booshbeats/lpad_leds.mid) to my Novation Launchpad to create a custom LED display.

The sequence used to execute the commands directly. I'd open a terminal, send the command and exit (CTRL-ALT-t, aplaymidi -p 20:1 ~/booshbeats/lpad_leds.mid, exit). This worked great so I decided to break it.

Instead of hard-coding a command onto the Teensy, I changed the sequence to: CTRL-ALT-t (open terminal) sh ~/ext_button.sh (execute a script) exit (close terminal)

This should let me do all kinds of crazy with the button without having to make changes on the Teensy itself. The script currently consists of the "aplaymidi -p 20:1 ~/booshbeats/lpad_leds.mid" command.

So... When I rebooted after the arduino surgery, I started a terminal and ran "sudo seq64" and was greeted with the GUI of joy. I then closed seq64, pushed my button, got the coolio LED pattern on my Launchpad and tried "sudo seq64" again. SEGMENTATION FAULT!

I'll try this combo a few times more and mix things up to triple verify.

(BTW, while I always try with and without Jack, I generally run with the --alsa switch since Jack just makes me frustrated and ALSA does everything I need.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ahlstromcj/sequencer64/issues/160#issuecomment-419658261, or mute the thread https://github.com/notifications/unsubscribe-auth/AHnVqGPqTmueMdsCidAd5wSSpPI1xY0Mks5uY_l6gaJpZM4WdPCX .

TDeagan commented 6 years ago

I'll head down the gdb route next.

I just ran "seq64" (w/o elevating privs with sudo) and it launched right up. Closed it and tried it again, segfault. Makes me suspicious of whether the sudo success is a red herring. If there is some other process or port lock that's causing the segfault, then I'm just getting intermittent reinforcement for the things I'm trying that look like they're doing something.

I suppose I need to disconnect all the external stuff (Teensy and MIDI interface,) and see whether that's an issue. Other than that, this is a really basic system that isn't (supposed to be,) doing anything else.

TDeagan commented 6 years ago

Hmph.

while this may not be useful, i did run a non-debug build (but was built with --disable-shared,) under gdb and got a segfault with bt:

pi@raspberrypi:~ $ gdb seq64 GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from seq64...done. (gdb) r Starting program: /usr/local/bin/seq64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [Reading rc configuration /home/pi/.config/sequencer64/sequencer64.rc] [Filter-by-channel off] [Reading user configuration /home/pi/.config/sequencer64/sequencer64.usr] [Initialized, running without JACK sync] 3 rtmidi ports created: Input ports (2): [0] 0:1 system:announce [1] 14:0 Midi Through:Midi Through Port-0 Output ports (1): [0] 14:0 Midi Through:Midi Through Port-0

[New Thread 0x74dbc270 (LWP 1596)] [New Thread 0x745bc270 (LWP 1597)]

Thread 1 "seq64" received signal SIGSEGV, Segmentation fault. 0x768d2df0 in gdk_colormap_alloc_colors () from /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (gdb) bt

0 0x768d2df0 in gdk_colormap_alloc_colors ()

from /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0

1 0x768a315c in gdk_colormap_alloc_color ()

from /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0

2 0x76f39ca8 in Gdk::Colormap::alloc_color(Gdk::Color&, bool, bool) ()

from /usr/lib/arm-linux-gnueabihf/libgdkmm-2.4.so.1

3 0x000212ac in seq64::gui_palette_gtk2::gui_palette_gtk2 (this=0x25baa0,

__vtt_parm=0x152cc8 <VTT for seq64::maintime+8>, __in_chrg=<optimized out>)
at gui_palette_gtk2.cpp:127

4 0x00050158 in seq64::gui_drawingarea_gtk2::gui_drawingarea_gtk2 (

this=0x25baa0, __vtt_parm=0x152cc4 <VTT for seq64::maintime+4>, perf=..., 
windowx=328024, windowy=12, __in_chrg=<optimized out>)
at gui_drawingarea_gtk2.cpp:93

5 0x00051748 in seq64::maintime::maintime (this=0x25baa0, p=...,

__in_chrg=<optimized out>, __vtt_parm=<optimized out>) at maintime.cpp:83

6 0x00029c68 in seq64::mainwnd::mainwnd (this=0x7eff9fe8, p=...,

midifilename=<error reading variable: Cannot access memory at address 0x184a9d9>, allowperf2=<optimized out>, ppqn=192, mainwid_rows=1, mainwid_cols=1, 
mainwid_indep=false, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
at mainwnd.cpp:310

7 0x0001dc14 in main (argc=, argv=)

at seq64rtmidi.cpp:198
TDeagan commented 6 years ago

for troubleshooting purposes, these are my current libgtk/gdk versions:

pi@raspberrypi:~ $ dpkg -l | grep libg[dt]k ii libgdk-pixbuf2.0-0:armhf 2.36.5-2+deb9u2 armhf GDK Pixbuf library ii libgdk-pixbuf2.0-common 2.36.5-2+deb9u2 all GDK Pixbuf library - data files ii libgdk-pixbuf2.0-dev 2.36.5-2+deb9u2 armhf GDK Pixbuf library (development files) ii libgtk-3-0:armhf 3.22.11-1+rpi3 armhf GTK+ graphical user interface library ii libgtk-3-bin 3.22.11-1+rpi3 armhf programs for the GTK+ graphical user interface library ii libgtk-3-common 3.22.11-1+rpi3 all common files for the GTK+ graphical user interface library ii libgtk2.0-0:armhf 2.24.31-2 armhf GTK+ graphical user interface library ii libgtk2.0-bin 2.24.31-2 armhf programs for the GTK+ graphical user interface library ii libgtk2.0-common 2.24.31-2 all common files for the GTK+ graphical user interface library ii libgtk2.0-dev 2.24.31-2 armhf development files for the GTK+ library ii libgtkmm-2.4-1v5:armhf 1:2.24.5-1 armhf C++ wrappers for GTK+ (shared libraries) ii libgtkmm-2.4-dev:armhf 1:2.24.5-1 armhf C++ wrappers for GTK+ (development files) ii libgtkmm-2.4-doc 1:2.24.5-1 all C++ wrappers for GTK+ (documentation) ii libgtkmm-3.0-doc 3.22.0-1 all C++ wrappers for GTK+ (documentation)

TDeagan commented 6 years ago

This is the package that provides the complaining libgdk-x11-2.0.so.0 - libgtk2.0-0:armhf (2.24.31-2) Indeed, it's an ARM specific instance. (and the stable release for Debian Stretch)

kniknoo commented 6 years ago

Thank you both!!! I was getting the same no-GUI/no info issue on Pi3 and I just decided to go learn more of seq24 instead. (I'm on a deadline for a show and both are a lifesaver for my otherwise computer-less setup). I'm pleased to report that "--disable-shared" did the trick for me. I'm frustrated to report that I'm nowhere near as sanitary as TDeagan and yet am able to run without sudo with no SEGFAULT. I started to also build with "--enable-alsamidi" flag and that failed with an issue I found elsewhere that you fixed in the default build with rt-midi. Without doing a make clean or even a bootstrap after that I just ran configure again and make. I don't know the build process intimately but perhaps something in my alsmidi mistake made it easier to run? I do have a PiSound installed, so perhaps the dedicated midi port has something to do with the difference in results as well.

kniknoo commented 6 years ago

Sigh, was working repeatedly. Then I rebooted to be sure. Now it requires sudo or else I get the segmentation fault and I get a crash when trying to save a file stating that it can't create a temp file in root.

ahlstromcj commented 6 years ago

Perhaps you can get the Qt version to work. It's getting close to the original in functionality, check out the latest master.

-------- Tim Deagan 12:33 Sat 08 Sep --------

This is the package that provides the complaining libgdk-x11-2.0.so.0 - libgtk2.0-0:armhf (2.24.31-2) Indeed, it's an ARM specific instance.

— You are receiving this because you commented. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread.

References

Visible links

  1. https://github.com/ahlstromcj/sequencer64/issues/160#issuecomment-419667529
  2. https://github.com/notifications/unsubscribe-auth/AHnVqKzrCDhgRPMNqssPXG83AKtAP4FPks5uZBuJgaJpZM4WdPCX

-- You prefer the company of the opposite sex, but are well liked by your own.

jonaseberle commented 5 years ago

btw, 0.96 does not have the GUI problem. But 0.96 on arm needs this block in the Makefile

.c.lo:
      $(AM_V_CC)$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
      $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo

(thanks to https://stackoverflow.com/a/21642830/2819581) or it will moan that it's missing event_list.lo

Thanks to the developers. I am majorly impressed by the build system!