serialoscd crashes when attempting grid discovery with grid unplugged

[boqs]

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

[artfwo]

@boqs this looks like it's new, can you provide a backtrace?

[boqs]

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

[wrl]

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 b5cd618a7f0b89fcf2e4bc8b081da3942dbe557c – can you report on whether this fixes the issue?

[wrl]

also can you make sure that didn't accidentally break expected behaviour please?

[boqs]

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!

[wrl]

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

[boqs]

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)