:) Ok, sorry for taking it worldwide then. I thought I was on to something.... :)
./MiS On Thu, Mar 11, 2010 at 12:44 PM, <[email protected]> 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: [email protected] >> Date: Thu, 11 Mar 2010 12:02:04 -0500 >> To: [email protected] >> 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 >> [email protected] >> http://lists.puredata.info/listinfo/pd-dev > -- ./MiS 514-344-0726 http://www.creazone.ca _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
