serialoscd crashes when attempting grid discovery with grid unplugged
boqs opened this issue · comments
bug originally observed on arch linux with revision bfe0178 - also persists at currentHEAD ( d46c80a )
- unplug all monomes from usb ports
- start serialoscd in a terminal
- run the following shell script in another terminal:
while ; do oscsend localhost 12002 /serialosc/list si "localhost" 3444; sleep 0.1; done - plug in monome
- serialoscd segfaults, leaving at least one process hanging (so you can't just kick serialoscd after segfaults)
~ » serialoscd
`[1] 15613 segmentation fault (core dumped) serialoscd
~ » ps aux |grep serial
rick 15614 0.0 0.0 8752 844 pts/0 S 21:44 0:00 [serialosc-detec]
rick 15770 0.0 0.1 10888 2244 pts/0 S+ 21:44 0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn serial
~ »
Guess I could just run serialoscd in a wrapper script to clean up the hanging processes & reboot serialoscd every time it segfaults. This would be a joyless solution!
I'll have a quick look with gdb first...
@boqs this looks like it's new, can you provide a backtrace?
Just looking at list_devices_walk_cb right now. here's the stack:
(gdb) bt
#0 0x00007ffff6f2f506 in __strlen_sse2 () from /usr/lib/libc.so.6
#1 0x00007ffff7475e79 in lo_strsize () from /usr/lib/liblo.so.7
#2 0x00007ffff7475ea8 in lo_message_add_string () from /usr/lib/liblo.so.7
#3 0x00007ffff74760f9 in lo_message_add_varargs_internal ()
from /usr/lib/liblo.so.7
#4 0x00007ffff74756cd in lo_send_from_internal () from /usr/lib/liblo.so.7
#5 0x0000555555558ea9 in list_devices_walk_cb ()
#6 0x000055555555c73b in uv_walk (loop=0x55555577e580 <default_loop_struct>,
walk_cb=0x555555558dc9 <list_devices_walk_cb>, arg=0x7fffffffaed0)
at ../third-party/libuv/src/uv-common.c:268
#7 0x0000555555558f52 in osc_list_devices ()
#8 0x00007ffff74777f1 in ?? () from /usr/lib/liblo.so.7
#9 0x00007ffff7479e14 in ?? () from /usr/lib/liblo.so.7
#10 0x00007ffff747a1cd in lo_server_recv () from /usr/lib/liblo.so.7
#11 0x00005555555594d1 in osc_poll_cb ()
#12 0x0000555555560c43 in uv__poll_io (
loop=0x55555577e580 <default_loop_struct>, w=0x7fffffffe790, events=1)
at ../third-party/libuv/src/unix/poll.c:49
#13 0x000055555556bdde in uv__io_poll (
loop=0x55555577e580 <default_loop_struct>, timeout=-1)
at ../third-party/libuv/src/unix/linux-core.c:319
#14 0x000055555555d84a in uv_run (loop=0x55555577e580 <default_loop_struct>,
mode=UV_RUN_DEFAULT) at ../third-party/libuv/src/unix/core.c:324
#15 0x000055555555a274 in main ()
oh, nice find! looks like list_devices_walk_cb() doesn't check to see if devices are in the ready state. i've fixed this in b5cd618 – can you report on whether this fixes the issue?
also can you make sure that didn't accidentally break expected behaviour please?
woohoo it works! I can hammer away at serialoscd now requesting device list & waiting for my grid to be plugged.
- the list of one grid (I only have a single unit to test) comes back correctly when it's connected
- I receive no device notifications after sending the request to serialosc/list when it's not connected
After grid is plugged, the child process works as before & my app seems to run fine.
Awesome, thanks so much for that!
@boqs for the record, you could also do /serialosc/notify si <host> <port> to receive a notification the next time a device is added or removed (you must then re-send the /serialosc/notify message to re-subscribe.)
I'll have to think carefully about the notify messages
My pig-headed OSC strategy seems watertight now to share one varibright 128 between a lisp/OSC layer & several puredata 'apps', regardless of the launch ordering. I was very glad to receive the /sys/port notifications when organising this focus-stealing behaviour!
But for a multi-monome setup or arc/grid I would definitely have to revisit both codes (pd & lisp)