In my experience, this may bog down pd but it should never crash it. If it does, something else is the problem.

On Jul 1, 2013 1:24 PM, "Martin Peach" <martin.peach@sympatico.ca> wrote:
It could be that you are overloading Pd with too many messages. If you are wildly moving the slider and [tcpclient] is sending one TCP packet per value you can add messages to the queue faster than they will be sent out and Pd will eventually run out of resources.

Maybe put a [speedlim] after your slider, or pack several values into one message?

Martin



On 2013-07-01 11:53, Iain Mott wrote:

I'll try the backtrace and other things you suggest and report back
on mrpeach/tcpclient in another email.

it could well be, that it only does not crash with [iemnet/tcpclient]
because you haven't parsed the output yet...


Don't think so - to crash Pd, I wasn't doing any parsing of incoming
messages - just sending messages out.

Did a backtrace using mrpeach/tcpclient - on a "freeze" as it didn't
actually crash. Got this response:

#0  0x0000000000442623 in clock_unset (x=0x8c5c80) at m_sched.c:70
#1  clock_unset (x=0x8c5c80) at m_sched.c:62
#2  0x000000000044266e in clock_set (x=0x8c5c80, setticks=<optimised
out>)
     at m_sched.c:81
#3  0x00007fffd21cfec1 in tcpclient_child_send (w=0xdec548)

at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380
#4  0x00007ffff7bc4e9a in start_thread ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007ffff6ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()


Will do some more tests later.

Thanks,


_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list