[PD-dev] Problem with [iemnet/tcpclient]? (was: Sporadic crashes of Pd)

Roman Haefeli reduzent at gmail.com
Tue Mar 13 14:52:28 CET 2012


Hi again

I was able to create a patch, that does not make Pd crash reliably, but
far more often. On my box it crashes roughly every second time I run the
patch.

This is how I run it:
$ gdb -ex run --args  pd-extended -noprefs -nrt -noaudio -stderr -open crashertest.pd

When the [bng] is hit, every 10ms an OSC message is sent over TCP. After
a while (on my box usually only a few seconds), no more messages are
received, though they are still sent. If [iemnet/tcpclient] is
disconnected at this point, Pd often crashes with the following
backtrace:

---
Program received signal SIGSEGV, Segmentation fault.
0x08086e42 in clock_unset (x=0x817f5b8) at m_sched.c:70
70	m_sched.c: No such file or directory.
	in m_sched.c
(gdb) backtrace
#0  0x08086e42 in clock_unset (x=0x817f5b8) at m_sched.c:70
#1  0x08086fb2 in clock_free (x=0x817f5b8) at m_sched.c:131
#2  0x00707ce0 in iemnet__receiver_destroy (rec=0x817f4c8) at iemnet_receiver.c:303
#3  0x007022e0 in tcpclient_disconnect (x=0x81042b8) at tcpclient.c:188
#4  0x0807f3f2 in pd_typedmess (x=0x81042b8, s=0x80f11e8, argc=<value optimized out>, argv=0xbffff1fc) at m_class.c:791
#5  0x080807fa in outlet_anything (x=0x8113e70, s=0x80f11e8, argc=0, argv=0xbffff1fc) at m_obj.c:470
#6  0x0807efe6 in pd_typedmess (x=0x8113e5c, s=0x80f11e8, argc=0, argv=0xbffff1fc) at m_class.c:812
#7  0x08085782 in binbuf_eval (x=0x8113e88, target=0x8113e5c, argc=0, argv=0x0) at m_binbuf.c:767
#8  0x0805fe2b in message_bang (x=0x8113e40) at g_text.c:351
#9  0x080804d3 in outlet_bang (x=0x8115bb0) at m_obj.c:399
#10 0x007137eb in delay_tick (x=0x8115b68) at delay.c:43
#11 0x08087414 in sched_tick (next_sys_time=49233920) at m_sched.c:372
#12 0x0808780b in m_pollingscheduler () at m_sched.c:485
#13 m_mainloop () at m_sched.c:571
#14 0x0808f14b in main (argc=7, argv=0xbffff3d4) at s_entry.c:32
---

This is with Pd-0.43.1-extended-20120307

With Pd-vanilla and the necessary externals, I get the same kind of
crash, but a different (corrupt) backtrace:

---
Program received signal SIGSEGV, Segmentation fault.
0x080a1fe5 in clock_unset (x=0x8140768) at m_sched.c:70
70	            while (x2->c_next != x) x2 = x2->c_next;
(gdb) backtrace
#0  0x080a1fe5 in clock_unset (x=0x8140768) at m_sched.c:70
#1  0x080a217c in clock_free (x=0x8140768) at m_sched.c:131
#2  0x00501b79 in iemnet__receiver_destroy () from /usr/local/lib/pd/extra/iemnet/libiemnet.so
#3  0x08140768 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
---

The fact, that [iemnet/tcpclient] suddenly stops transmitting data,
indicates that there is some problem there, whether the crash is caused
by it or not.

Roman



On Wed, 2012-03-07 at 11:39 +0100, Roman Haefeli wrote:
> Hi all
> 
> While developing on and playing with netpd2, Pd sometimes crashes. This
> hadn't happened so frequently until recently, so  I didn't investigate
> it further. However, with running more and bigger patches I seem to
> experience those crashes more often and I started running pd inside gdb
> to get some more information.
> 
> I haven't yet figured a way to reliably trigger a crash. It seems to
> happen at random times. However, it seems to me that it only happens
> when I touch a GUI element (sliders, numberboxes, arrays, etc), but this
> doesn't necessarily is the cause, as most interactions trigger a message
> sent to the network. 
> 
> 
> >From the many backtraces I collected, most of them look very similar:
> 
> ---
> Program received signal SIGSEGV, Segmentation fault.
> 0x080a1fe5 in clock_unset (x=0x83c03f0) at m_sched.c:70
> 70                  while (x2->c_next != x) x2 = x2->c_next;
> 
> #0  0x080a1fe5 in clock_unset (x=0x83c03f0) at m_sched.c:70
> #1  0x080a2040 in clock_set (x=0x83c03f0, setticks=5047173120) at m_sched.c:81
> #2  0x080a2109 in clock_delay (x=0x83c03f0, delaytime=0) at m_sched.c:103
> #3  0x080b9fb3 in bang_tilde_perform (w=0x885abd0) at d_misc.c:90
> #4  0x080af8b2 in dsp_tick () at d_ugen.c:336
> #5  0x080a298d in sched_tick (next_sys_time=5047173120) at m_sched.c:382
> #6  0x080a2b7e in m_pollingscheduler () at m_sched.c:482
> #7  0x080a2d67 in m_mainloop () at m_sched.c:568
> #8  0x080a347a in sys_main (argc=9, argv=0xbffff3c4) at s_main.c:302
> #9  0x080ab147 in main (argc=9, argv=0xbffff3c4) at s_entry.c:32
> ---
> 
> or another very similar one:
> 
> ---
> Program received signal SIGSEGV, Segmentation fault.
> 0x080a1fe5 in clock_unset (x=0x83d1660) at m_sched.c:70
> 70                  while (x2->c_next != x) x2 = x2->c_next;
> 
> #0  0x080a1fe5 in clock_unset (x=0x83d1660) at m_sched.c:70
> #1  0x080a2040 in clock_set (x=0x83d1660, setticks=6376652800) at m_sched.c:81
> #2  0x080a2109 in clock_delay (x=0x83d1660, delaytime=0) at m_sched.c:103
> #3  0x080b9fb3 in bang_tilde_perform (w=0x88f6c68) at d_misc.c:90
> #4  0x080af8b2 in dsp_tick () at d_ugen.c:336
> #5  0x080a298d in sched_tick (next_sys_time=6376652800) at m_sched.c:382
> #6  0x080a2b7e in m_pollingscheduler () at m_sched.c:482
> #7  0x080a2d67 in m_mainloop () at m_sched.c:568
> #8  0x080a347a in sys_main (argc=9, argv=0xbffff3c4) at s_main.c:302
> #9  0x080ab147 in main (argc=9, argv=0xbffff3c4) at s_entry.c:32
> ---
> 
> I have many more of this kind, but I think it doesn't help to post them
> here.
> 
> In a few other cases, the network transmission suddenly stops, though Pd
> keeps running. When I then send 'disconnect' to [iemnet/tcpclient], Pd
> segfaults and the backtrace looks like this:
> 
> ---
> Program received signal SIGSEGV, Segmentation fault.
> 0x080a1fe5 in clock_unset (x=0x8211148) at m_sched.c:70
> 70                  while (x2->c_next != x) x2 = x2->c_next;
> 
> #0  0x080a1fe5 in clock_unset (x=0x8211148) at m_sched.c:70
> #1  0x080a217c in clock_free (x=0x8211148) at m_sched.c:131
> #2  0x00508b79 in iemnet__receiver_destroy ()
> from /usr/local/lib/pd/extra/iemnet/libiemnet.so
> #3  0x08211148 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> ---
> 
> (What does the last line mean?) 
> 
> What can I do to help to track down the reason for those crashes? Would
> using valgrind reveal more useful information here? Is it possible to
> tell from the backtraces, whether the cause is in Pd itself or in the
> externals used?
> 
> This is on/with:
> Pd 0.43.1 
> iemnet (current svn)
> zexy (2.2.6 current svn)
> osc (current svn mrpeach/osc)
> slipdec/slipenc (current svn mrpeach)
> 
> 
> Roman
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crashertest.pd
Type: text/x-puredata
Size: 1304 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120313/74f0daee/attachment.bin>


More information about the Pd-dev mailing list