Serialosc(d) and segmentation fault

back tweaking the raspberry pi and trying to understand debian, i’m encountering weird problems …

here’s what i’ve gathered:

  • booting into the desktop and autostarting serialoscd and pure data via ./.config/lxsession/LXDE-pi/autostart seems to work

  • using crontab -e to do the same neither works in desktop nor in command-line (– is that what it’s called when you’re not booting into the desktop?). it appears that serialoscd isn’t (correctly) launched. if i try to launch it manually after approaching this route, i get a “segmentation fault” error

i have absolutely no clue about this stuff! :roll_eyes: it’s frustrating…

edit: to elaborate – in my croontab-thingy i’ve put the line

@reboot /home/pi/bin/script_pd

my script_pd has this:

sleep 5
serialoscd &
sleep 5
sudo pd-l2ork -nogui -mididev 1 /home/pi/Desktop/share/mainboot.pd

tried it with and without sleeps, tried it with various constellations of “&” – nothing seems to work. the weird thing is: if i run the script from the console manually (/home/pi/bin/script_pd), it starts and the monome is even found.

Cronjobs are executed in a special context, you should try to specify the full path of serialoscd and pd-l2ork.

Tbh i would just configure the RPi to login your user automatically (doable easily via the sudo raspi-config utility) and then call your script at then end of your .bashrc file. This ensures you that the script has all the environment variables of your user (which probably pd makes use of), i’m not sure when @reboot is executed, but it might be before every service you need is available.

I also have segfaults with serialosc on the RPi (model B) which makes it difficult for me to use confidently as a headless system.

thanks a TON for the help – was checking back here frequently :slight_smile:

totally wasn’t aware of that, great! what is the full path of my serialosc?

i have it setup this way… i assume you mean configuring raspi-congig to log in to the non-GUI (with user “pi”)? do i understand correctly that the .bashrc file will then be run? i’m having real difficulties understanding when, at which user-level and under which circumstances (GUI / non-GUI) which particular startup-scripts/procedures etc are executed.

thanks again!


if i’m not mistaken, yes. .bashrc is evaluated when a user shell is started. I use it to autostart things in a context of machines that boot and are then left alone doing their things.

The full path of serialosc, after a default install should be /usr/bin/serialoscd (at least it is on my debian machines).

1 Like

thanks! <3 will give it a shot and report back :slight_smile:

are you building serialosc from the most recent github sources?

thanks brian! i don’t even know that! :slight_smile: … or, well – i followed your instructions (i recapped in another thread):

Hey @benniii your post got me all inspired to get my arduinome 128 running with the rpi, thanks!
I ran into the segmentation fault in serialosc too. For my setup I found two things.

  1. Building latest serialosc source also won’t detect my arduinome on the rpi, this seems to be due to the changes @artfwo made to the linux detector in serialosc, building the serialosc source without this commit on the rpi detects the two arduinomes inside my 128 fine.

I see you’re using a 256 so it looks like the detection problems are more specific to the rpi than the device.

  1. Once I got things detecting I was also running into a segmentation fault. On my setup this seems to be due to having two identical devices appear at the same time. I found that by editing /src/serialoscd/uv.c and adding a sleep to this function the problem went away.

dev->ready = 1;
osc_notify(self, dev, SOSC_DEVICE_CONNECTION);
fprintf(stderr, “serialosc [%s]: connected, server running on port %d\n”,
dev->serial, dev->port);
sleep (1);
return 0;

My unscientific hunch is that serialosc is not really designed to have two devices appear at the same time and it’s getting itself confused trying to connect to both at once.

What year is your 256? I’m assuming since it’s a monome it only shows up as a single device so I’m not sure if this would help in your case. Thought I’d share my findings anyway in case they’re useful.

nice one.

@herringson this is weird, i have a couple of arduinomes too (starfire, ft232-based i/o) and they’re detected just fine. what does udevadm info show about your device?

@artfwo Hi! So I forgot to mention it’s two teensy ++ 2.0 running stock arduinome firmware.
udevadm gives me this.

P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/tty/ttyACM1
N: ttyACM1
S: serial/by-id/usb-Teensyduino_USB_Serial_a40h_201-if00
S: serial/by-path/platform-3f980000.usb-usb-0:1.2.2:1.0
E: DEVLINKS=/dev/serial/by-path/platform-3f980000.usb-usb-0:1.2.2:1.0 /dev/serial/by-id/usb-Teensyduino_USB_Serial_a40h_201-if00
E: DEVNAME=/dev/ttyACM1
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/tty/ttyACM1
E: ID_BUS=usb
E: ID_MODEL_FROM_DATABASE=Teensyduino Serial
E: ID_PATH=platform-3f980000.usb-usb-0:1.2.2:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_2_2_1_0
E: ID_SERIAL=Teensyduino_USB_Serial_a40h_201
E: ID_TYPE=generic
E: ID_USB_DRIVER=cdc_acm
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_VENDOR=Teensyduino
E: ID_VENDOR_ENC=Teensyduino
E: ID_VENDOR_FROM_DATABASE=Van Ooijen Technische Informatica
E: MAJOR=166
E: TAGS=:systemd:

wow, never heard about teensyduinomes (dual or not) before. you should post pictures of your grid :slight_smile: could you also run udevadm info -a /dev/ttyACM1? it doesn’t seem to print out parent devices by default.

Hello @herringson - did you ever solve your issues here?

Could you point me to the serialosc linux detector source change you mentioned above?

I’ve got a teensy 3.2 based grid I’m working on and I’m having similar trouble with serialosc detecting the device on RaspberryPi.

Question - how do arduinomes show up in /dev? I’m guessing that the teensy showing up as ttyACM0 or ttyACM1 could be part of the problem in the device being recognized (?)

EDIT - I got my teensy grid to be recognized by serialoscd (I think I had a libmonome conflict). I am also getting segmentation faults from time to time so I need to look at your fix for that. Thx!

I think what I did was to checkout and build the version just before this commit

There has been a lot of action on the repo since then though so I’m not sure that’s still relevant.

In regards to the hack I made it’s just the horrible sleep addition I made to uv.c outlined above.

I hope that helps.

1 Like