[PD-dev] udpreceive~

[Michal Seta]

Hello Martin and others,

I think I should bring this issue to the general pd-dev attention
because there seem to be some serious glitches in the way pd interacts
with externals that try to send audio signal over the network.

Just to put everyone on a more or less the same page, I have been
trying to use pd in a situation where several musician will improvise
together over a local network.  The main requirement is that the
playing happens over WiFi.  I had netsend~/netreceive~ crash regularly
and Mr Peach's udpsend~/receive~ appeared on my radar.

They, too, crash, on WiFi networks.  Using them on wired connections
seems to be quite reliable (but I have not tested with wires
extensively).  It seems that udpreceive~ is the source of crashes.

I played quite a bit with udpreceive~ but I cannot put my finger on
any particular bug.  Even running just one udpreceive~ listening on 1
channel it will eventually crash.
I get sometimes this mysterious message:

error: udpreceive~: incoming stream has too many channels (2)

Even if I send 1 channel and receive 1.

At some point this happended to print into the pd console as well

udpreceive~: EFAULT: 0x832dda0 1900572 1576380
udpreceive~: recv data: Bad address (14)

The above messages are, I guess, udpreceive~ specific

gdb backtraces show that the problem lies deeper:

#0  0x01834f21 in ?? () from /home/mis/pd-externals/udpreceive~.pd_linux
#1  0x080c9335 in dsp_tick () at d_ugen.c:336
#2  0x080b6821 in sched_tick (next_sys_time=19501527040) at m_sched.c:382
#3  0x080b799d in m_pollingscheduler () at m_sched.c:482
#4  m_mainloop () at m_sched.c:558
#5  0x080ba96f in sys_main (argc=2, argv=0xbffff314) at s_main.c:307
#6  0x080c3fff in main (argc=Cannot access memory at address 0xb5ff0d00

but also occasional:

0x080bace5 in sys_domicrosleep (microsec=<value optimized out>,
    pollem=<value optimized out>) at s_inter.c:171
171	s_inter.c: No such file or directory.
	in s_inter.c
#1  0x080bbfe1 in sys_pollgui () at s_inter.c:833
#2  0x080b776f in m_pollingscheduler () at m_sched.c:488
#3  m_mainloop () at m_sched.c:558
#4  0x080ba96f in sys_main (argc=2, argv=0xbffff314) at s_main.c:307
#5  0x080c3fff in main (argc=Cannot access memory at address 0x1f
) at s_entry.c:32

sometimes:

#0  0x080b5299 in pd_float (x=0x86d5f08, f=nan(0x428487)) at m_pd.c:274
#1  0x080b8c77 in outlet_float (x=0x868dc18, f=nan(0x428487)) at m_obj.c:397
#2  0x08059af2 in env_tilde_tick (x=0x868db38) at d_ctl.c:671
#3  0x080c33fc in sched_tick (next_sys_time=901427200) at m_sched.c:374
#4  0x080c3843 in m_pollingscheduler () at m_sched.c:484
#5  m_mainloop () at m_sched.c:560
#6  0x080c6509 in sys_main (argc=2, argv=0xbffff354) at s_main.c:304
#7  0x080ce1ab in main (argc=2, argv=0xbffff354) at s_entry.c:32

or

#0  0x0166adeb in ?? () from /home/mis/pd-externals/udpreceive~.pd_linux
#1  0x080bafaa in sys_domicrosleep (microsec=<value optimized out>,
    pollem=<value optimized out>) at s_inter.c:184
#2  0x080bbfe1 in sys_pollgui () at s_inter.c:833
#3  0x080b776f in m_pollingscheduler () at m_sched.c:488
#4  m_mainloop () at m_sched.c:558
#5  0x080ba96f in sys_main (argc=2, argv=0xbffff314) at s_main.c:307
#6  0x080c3fff in main (argc=Cannot access memory at address 0xb
) at s_entry.c:32

or

#0  0x080ac7f6 in pd_checkobject (x=0x830bf78) at m_obj.c:554
#1  0x0808c7ba in canvas_hitbox (x=0x82f54f8, xpos=171, ypos=139, which=0,
    mod=<value optimized out>, doit=0) at g_editor.c:768
#2  canvas_doclick (x=0x82f54f8, xpos=171, ypos=139, which=0,
    mod=<value optimized out>, doit=0) at g_editor.c:1095
#3  0x0808d6fe in canvas_motion (x=0x82f54f8, xpos=171, ypos=139, fmod=0)
    at g_editor.c:1614
#4  0x080aaf27 in pd_typedmess (x=0x82f54f8, s=0x822bd10, argc=3,
    argv=0xbfffda5c) at m_class.c:728
#5  0x080aac24 in pd_typedmess (x=0x8323bf0, s=0x822bd10, argc=3,
    argv=0xbfffda5c) at m_class.c:749
#6  0x080af027 in binbuf_eval (x=0x823e078, target=0x8323bf0, argc=0, argv=0x0)
    at m_binbuf.c:722
#7  0x080bce19 in socketreceiver_read (x=0x823e088, fd=6) at s_inter.c:546
#8  0x080bafaa in sys_domicrosleep (microsec=<value optimized out>,
    pollem=<value optimized out>) at s_inter.c:184
#9  0x080bbfe1 in sys_pollgui () at s_inter.c:833
#10 0x080b776f in m_pollingscheduler () at m_sched.c:488
#11 m_mainloop () at m_sched.c:558
#12 0x080ba96f in sys_main (argc=4, argv=0xbffff304) at s_main.c:307
#13 0x080c3fff in main (argc=Cannot access memory at address 0x70008700
) at s_entry.c:32

All these backtraces seem to have m_pollingscheduler () in common
although the error originates at different points that seem quite
random to me.  This last one is particularly puzzling to me as I don't
understand what canvas has to do with signals (the crash happened the
moment I clicked on a message box...)

Most of these tests were done on pd 0.42.5-extended-20100110 and pd
vanilla 0.41-4 on Ubuntu Karmic and/or Ubuntu Jaunty.  I had also
tested a few times on MaxOSX 10.5 I believe, pd-extended, probably
0.41-something (I can check the version later if it is at all
important).  The crashes happen at different points in time, sometimes
as soon as signal connection is established sometimes it will run for
1 - 10 minutes.  The same behaviour is exhibited when running pd with
-nogui option and irrespective of mouse/keyboard interactions.

Any ideas anyone?

Thanks in advance

./MiS