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