[PD-dev] Sporadic crashes of Pd

[Roman Haefeli]

Hi all

Just to resume what I figured out in the meanwhile:

The crashes I often experienced seem related to [iemnet/tcpclient].
Simply bypassing it makes the crashes completely disappear. The good
news (at least for me) is that Pd itself runs astonishingly stable (as
in 'rock-solid stable'), even if I use some externals which all run in
Pd's thread. The bad news is that there seems to be a bug in
[iemnet/tcpclient] which is really difficult to hunt down.

IOhannes, if there is anything I could do to help you which debugging
this, please let me know. If you intend not to fix it, please let me
also know.

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
> 
>