[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