[PD-dev] udpreceive~

Michal Seta mis at artengine.ca
Thu Mar 11 21:15:24 CET 2010


:)

Ok, sorry for taking it worldwide then.  I thought I was on to something.... :)

./MiS

On Thu, Mar 11, 2010 at 12:44 PM,  <martin.peach at sympatico.ca> wrote:
>
> Hi Michal,
> I don't think it's any bug with Pd, it's just that you are suffering from dropped packets. The packets are sent by UDP, which sends each packet once and forgets about it, unlike TCP which checks that the other end actually received the packet and resends as necessary.
> So it seems that [udpreceive~] sometimes tries to read a data packet as a header packet and gets confused. Here
>> udpreceive~: EFAULT: 0x832dda0 1900572 1576380
> it thinks that it wants to read 1576380 bytes, which is too many for the buffer.
> In other cases the size is probably acceptable but Pd crashes because it's trying to access memory out of its allowed space.
> I think that a first step would be to have [udpreceive~] check that the header is sane before attempting to use it. I'll try to do that today.
>
>
> Martin
>
>
> ----------------------------------------
>> From: mis at artengine.ca
>> Date: Thu, 11 Mar 2010 12:02:04 -0500
>> To: pd-dev at iem.at
>> Subject: [PD-dev] udpreceive~
>>
>> 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=,
>> pollem=) 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=,
>> pollem=) 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=, doit=0) at g_editor.c:768
>> #2 canvas_doclick (x=0x82f54f8, xpos=171, ypos=139, which=0,
>> mod=, 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=,
>> pollem=) 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
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>



-- 
./MiS
514-344-0726
http://www.creazone.ca




More information about the Pd-dev mailing list