Re: [PD] pd-extended crashes sending data to SSR with tcpclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-29 20:19, Iain Mott wrote: Hi list, Pd-extended (Pd-0.43.1 extended-20120430 compiled 00:31:34 Apr 30 2012) is crashing when I send data to the SoundScape Renderer on Ubuntu 12.04 using tcpclient. hmm, since Pd and SSR are only communicating via a network socket, i only have 2 possible explanations: - - either the network code is broken - - or SSR sends data in a format that exposes/triggers a bug (e.g. a memory leak) in Pd since there are several network implementations, which one are you using? mrpeach? iemnet?? do SSR and Pd agree on the actual protocol? e.g. OSC over TCP/IP (if it is that) used to be badly defined in the olde days, and you still see the deprecated non-SLIP implementation. afaik liblo only recently changed their TCP/IP code to use SLIP. could you get a backtrace of the crash? [1] do you notice anything weird? like when running htop besides Pd, do you see an excess of memory usage? try running Pd with -verbose -verbose -stderr; sometimes their is a printout when Pd is crashing, which get's lost once the Pd-GUI closes (that is: quite immediately) fgamsdr IOhannes [1] http://wiki.debian.org/HowToGetABacktrace -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHRLlQACgkQkX2Xpv6ydvT/ogCgrciJSnp5LcHZFr14yxISiLIq fkUAoJl4cIchubi2Ua1GaLF9S6qpH+LB =cc4X -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
Thanks very much IOhannes! The mrpeach version was being loaded by default. When I use iemnet/tcpclient it doesn't crash. That's great. There's a difference however in the way mrpeach/tcpclient and iemnet/tcpclient sends received data to its output. Messages from SSR received by mrpeach/tcpclient are sent to its output as a list (if that's the right word), for example as: 60 117 112 100 97 116 101 62 60 115 111 117 114 99 101 32 105 100 61 39 49 39 32 108 101 118 101 108 61 39 45 57 56 46 56 53 51 49 39 47 62 60 115 111 117 114 99 101 32 105 100 61 39 50 39 32 108 101 118 101 108 61 39 45 49 48 48 46 49 55 55 39 47 62 60 115 111 117 114 99 101 32 105 100 61 39 51 39 32 108 101 118 101 108 61 39 45 49 48 48 46 53 53 54 39 47 62 60 115 111 117 114 99 101 32 105 100 61 39 52 39 32 108 101 118 101 108 61 39 45 57 56 46 51 50 51 57 39 47 62 60 47 117 112 100 97 116 101 62 0 This is easily converted to a readable XML string with string2any 0 0 to get: updatesource id='1' level='-98.8531'/source id='2' level='-100.177'/source id='3' level='-100.556'/source id='4' level='-98.3239'//update iemnet/tcpclient on the other hand sends individual numbers to its output as a stream rather than a list. eg 60 117 112 100 97 ... etc. And there are various messages of various lengths. I guess if I use iemnet/tcpclient I'll need to find a different way of parsing these numbers Not my strong point with Pd! I'll try the backtrace and other things you suggest and report back on mrpeach/tcpclient in another email. Cheers and thanks again, Iain Em Mon, 2013-07-01 às 09:23 +0200, IOhannes m zmoelnig escreveu: On 2013-06-29 20:19, Iain Mott wrote: Hi list, Pd-extended (Pd-0.43.1 extended-20120430 compiled 00:31:34 Apr 30 2012) is crashing when I send data to the SoundScape Renderer on Ubuntu 12.04 using tcpclient. hmm, since Pd and SSR are only communicating via a network socket, i only have 2 possible explanations: - either the network code is broken - or SSR sends data in a format that exposes/triggers a bug (e.g. a memory leak) in Pd since there are several network implementations, which one are you using? mrpeach? iemnet?? do SSR and Pd agree on the actual protocol? e.g. OSC over TCP/IP (if it is that) used to be badly defined in the olde days, and you still see the deprecated non-SLIP implementation. afaik liblo only recently changed their TCP/IP code to use SLIP. could you get a backtrace of the crash? [1] do you notice anything weird? like when running htop besides Pd, do you see an excess of memory usage? try running Pd with -verbose -verbose -stderr; sometimes their is a printout when Pd is crashing, which get's lost once the Pd-GUI closes (that is: quite immediately) fgamsdr IOhannes [1] http://wiki.debian.org/HowToGetABacktrace ___ 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
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-01 16:40, Iain Mott wrote: Thanks very much IOhannes! The mrpeach version was being loaded by default. When I use iemnet/tcpclient it doesn't crash. That's great. it is, though i'm sometimes under the impression that mrpeach is a bit more stable than iemnet (rather than the other way around) There's a difference however in the way mrpeach/tcpclient and iemnet/tcpclient sends received data to its output. Messages from SSR received by mrpeach/tcpclient are sent to its output as a list (if that's the right word), for example as: [...] This is easily converted to a readable XML string with string2any 0 0 to get: updatesource id='1' level='-98.8531'/source id='2' level='-100.177'/source id='3' level='-100.556'/source id='4' level='-98.3239'//update iemnet/tcpclient on the other hand sends individual numbers to its output as a stream rather than a list. [...] ... etc. And there are various messages of various lengths. I guess if I use iemnet/tcpclient I'll need to find a different way of parsing these numbers Not my strong point with Pd! well the point is, that TCP/IP as an underlying protocol doesn't know anything about packets - it is stream-based, like a serial connection. if you are relying on the packets coming out of the [tcpclient] object as strings of the correct length, then your code is broken. you *must* have a way to determine the end of an atomic junk of data without relying on the list length. [iemnet/tcpclient] makes this obvious from the beginning, as it will never lure you into security of correct length lists (though there is a hidden flag that gives you the same behaviour as [mrpeach/tcpclient]). outputting the bytes one-by-one should actually make it easier to re-packetize the data. e.g. your example string looks like '0' was a delimiting character (at least it appears at the end of the [mrpeach/tcpclient] example output). if this is indeed the case, you only have to [list append] the incoming bytes until you encounter 0, and then flush the buffer to the output - this way your packages will always be of the correct length. 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... fgmads IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHRn7IACgkQkX2Xpv6ydvSoSgCeO4rVMd8osut8fFoFaIAUNK0U aGAAoPAzjQXENf4nNq5SEtep4ssw+820 =rsof -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x 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
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x 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
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
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.pe...@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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-**svn/externals/mrpeach/net/** tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/**libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.**6 #6 0x 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 http://lists.puredata.info/listinfo/pd-list __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
Hi Martin, The actual patch I'm using is translating MIDI pitch bend data recorded in Ardour3 (location data encoded as pitchbend for practical purposes), translating it into XML and sending it through to the SSR. It's already limiting the rate to 10 messages every second for each moving source and so far I'm only using 4 sources. This rate, done for testing, is already less than ideal. Each location message sent SSR for a given source looks something like the following: requestsource id=1position x=1.234 y=-0.234//source/request Does this seem excessive? Cheers, Iain Em Mon, 2013-07-01 às 13:20 -0400, Martin Peach escreveu: 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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x 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
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
Forty times a second is relatively slow. Must be something else. I would use wireshark to see what packets are actually going over the wire, especially to see what the last one is. These speeds are probably too fast for [print]ing to the console; that can cause problems. Are you sending to the same machine? If not is WiFi involved? Can you use UDP instead of TCP (for lower overhead and no out-of-order packets)? Martin On 2013-07-01 13:58, Iain Mott wrote: Hi Martin, The actual patch I'm using is translating MIDI pitch bend data recorded in Ardour3 (location data encoded as pitchbend for practical purposes), translating it into XML and sending it through to the SSR. It's already limiting the rate to 10 messages every second for each moving source and so far I'm only using 4 sources. This rate, done for testing, is already less than ideal. Each location message sent SSR for a given source looks something like the following: requestsource id=1position x=1.234 y=-0.234//source/request Does this seem excessive? Cheers, Iain Em Mon, 2013-07-01 às 13:20 -0400, Martin Peach escreveu: 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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x 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
[PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
I'm reformulating my question as the problem is evolving: do we have an object that - Displays and holds a text value (like Symbol or Message box), - is Graph-on-Parent, - can be resized (like Number2)? (or small enough by default?) Something like a Number2 for symbols...? Or a settable comment...? Thanks, András On Sun, Jun 23, 2013 at 9:22 PM, András Murányi muran...@gmail.com wrote: Hi List, I'm trying to switch from oldstyle dropdown combo box (toxy/widget popup) to tof/plist which is a nice dropdown menu except it has no placeholder, but the menu appears wherever when sent a bang. My question is: do we have an object that - Displays and holds a text value (like Symbol or Message box), - is Graph-on-Parent, - emits a bang when clicked? It doesn't have to be Vanilla. Thanks, András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
On Mon, 2013-07-01 at 13:20 -0400, Martin Peach 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. There seem to exist different approaches to address this problem. If I'm not mistaken, [netsend] uses a fixed buffer and when filled it blocks Pd until the buffer gets emptied. [iemnet/tcp[client|send]] allocates just as much RAM as it needs and does not block Pd. If [net/tcpclient] really is designed to crash Pd when the buffer gets full, then I would think this is the least desirable behavior of all three. @Iain If it really crashes due to network saturation can easily be verified by testing the same patch with [iemnet/tcpclient]. If you throw more messages at it than it can actually transmit, you would notice an increasing lag on the other end. Roman 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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: I'm reformulating my question as the problem is evolving: do we have an object that - Displays and holds a text value (like Symbol or Message box), * symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' message - is Graph-on-Parent, applies to all above solutions. - can be resized (like Number2)? (or small enough by default?) see above. To make something send a bang, you could put some [bng] objects behind your whatever text displaying objects. Interestingly, hidden GUI objects have priority over visible objects when clicked. Another way is to use a construct like the following to make a slider send bangs only when clicked, but not when dragged: [hsl] | [t a a] \/ /\ [sel 0] Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
Using iemnet/tcpclient and implementing IOhannes parsing suggestion, my patch is now communicating with SSR without crashing. There is a bogging down problem though and testing with just 3 sources, I need to keep the limit at 10 messages/sec for each. It stops working at higher rates but doesn't crash. SSR is running on this local machine and there is no WiFi involved. Unfortunately I don't think UDP is an option with SSR. SSR also sends XML level data to tcpclient constantly for each source in the scene. Perhaps this extra traffic isn't helping. eg. updatesource id='1' level='-98.5405'/source id='2' level='-99.8139'/source id='3' level='-99.6628'/source id='4' level='-101.127'//update I'll wait to hear back from SSR to see if they have any suggestions. Cheers and thanks for your help everyone, Iain Em Mon, 2013-07-01 às 14:29 -0400, Martin Peach escreveu: Forty times a second is relatively slow. Must be something else. I would use wireshark to see what packets are actually going over the wire, especially to see what the last one is. These speeds are probably too fast for [print]ing to the console; that can cause problems. Are you sending to the same machine? If not is WiFi involved? Can you use UDP instead of TCP (for lower overhead and no out-of-order packets)? Martin On 2013-07-01 13:58, Iain Mott wrote: Hi Martin, The actual patch I'm using is translating MIDI pitch bend data recorded in Ardour3 (location data encoded as pitchbend for practical purposes), translating it into XML and sending it through to the SSR. It's already limiting the rate to 10 messages every second for each moving source and so far I'm only using 4 sources. This rate, done for testing, is already less than ideal. Each location message sent SSR for a given source looks something like the following: requestsource id=1position x=1.234 y=-0.234//source/request Does this seem excessive? Cheers, Iain Em Mon, 2013-07-01 às 13:20 -0400, Martin Peach escreveu: 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 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x 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
