hi all,
I've just notice [tcpserver] crashes when the 34th client try to connect both iemnet and mrpeach are affected
iemnet version send a strange number on the 33th connection (like 2.8686e+07) and crashes on the 34th
here is a gdb output for iem : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcdbca746 in tcpserver_connectpoll (x=0x66994c0) at tcpserver.c:503 503 x->x_sr[i] = y; (gdb) watchdog: signaling pd...
and for mrpeach : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcddaf585 in tcpserver_connectpoll (x=0xadfc1c0) at tcpserver.c:1113 1113 outlet_float(x->x_sockout, x->x_sr[i]->sr_fd); /* the socket number */ (gdb) watchdog: signaling pd...
it happens on ubuntu 12.04 64 bit pd 0.44.2 and SVN update today
i'm certainly doing something wrong to get this (like keeping clients connected all the time) but a crash is never welcome...
cheers
antoine
do it yourself http://antoine.villeret.free.fr
so I reply to myself...
I found this in the code of both tcpserver.c : #define MAX_CONNECT 32 /* maximum number of connections */
which could be an answer embryo
so, I shouldn't make more than 32 connections on the same tcpserver, ok, but why ? is there a good reason to fix this to 32 ?
and this doesn't tell me why it crashes... reaching the MAX_CONNECT should handles in the code isn't it ?
cheers
a
-- do it yourself http://antoine.villeret.free.fr
2013/5/16 Antoine Villeret antoine.villeret@gmail.com
hi all,
I've just notice [tcpserver] crashes when the 34th client try to connect both iemnet and mrpeach are affected
iemnet version send a strange number on the 33th connection (like 2.8686e+07) and crashes on the 34th
here is a gdb output for iem : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcdbca746 in tcpserver_connectpoll (x=0x66994c0) at tcpserver.c:503 503 x->x_sr[i] = y; (gdb) watchdog: signaling pd...
and for mrpeach : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcddaf585 in tcpserver_connectpoll (x=0xadfc1c0) at tcpserver.c:1113 1113 outlet_float(x->x_sockout, x->x_sr[i]->sr_fd); /* the socket number */ (gdb) watchdog: signaling pd...
it happens on ubuntu 12.04 64 bit pd 0.44.2 and SVN update today
i'm certainly doing something wrong to get this (like keeping clients connected all the time) but a crash is never welcome...
cheers
antoine
do it yourself http://antoine.villeret.free.fr
Yes, it seems that the routine that adds new connections doesn't check to see if it has passed the number of connection slots. There are MAX_CONNECT slots allocated when [tcpserver] starts.
Thanks for finding this bug!
There is no reason to limit the number of connections to 32 except to not use up memory. I think it could be changed to either dynamically add space for new connections without limit or set MAX_CONNECT with a creation argument.
For now you could recompile it with MAX_CONNECT set to another value. (At some point the OS will run out of sockets. Before that Pd will slow down...)
#define MAX_CONNECT 10000
Martin
On 2013-05-18 17:37, Antoine Villeret wrote:
so I reply to myself...
I found this in the code of both tcpserver.c : #define MAX_CONNECT 32 /* maximum number of connections */
which could be an answer embryo
so, I shouldn't make more than 32 connections on the same tcpserver, ok, but why ? is there a good reason to fix this to 32 ?
and this doesn't tell me why it crashes... reaching the MAX_CONNECT should handles in the code isn't it ?
cheers
a
-- do it yourself http://antoine.villeret.free.fr
2013/5/16 Antoine Villeret <antoine.villeret@gmail.com mailto:antoine.villeret@gmail.com>
hi all, I've just notice [tcpserver] crashes when the 34th client try to connect both iemnet and mrpeach are affected iemnet version send a strange number on the 33th connection (like 2.8686e+07) and crashes on the 34th here is a gdb output for iem : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcdbca746 in tcpserver_connectpoll (x=0x66994c0) at tcpserver.c:503 503 x->x_sr[i] = y; (gdb) watchdog: signaling pd... and for mrpeach : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcddaf585 in tcpserver_connectpoll (x=0xadfc1c0) at tcpserver.c:1113 1113 outlet_float(x->x_sockout, x->x_sr[i]->sr_fd);/* the socket number */ (gdb) watchdog: signaling pd... it happens on ubuntu 12.04 64 bit pd 0.44.2 and SVN update today i'm certainly doing something wrong to get this (like keeping clients connected all the time) but a crash is never welcome... cheers antoine -- do it yourself http://antoine.villeret.free.fr
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Martin,
Thanks for your reply.
For now, I increase the MAX_CONNECT value and I also make each client disconnecting after they receive expected data, and they connect again if needed.
But I experience another issue. If Pd crashes for any reason, the socket stay in a TIME_WAIT state and if Pd restarts asap, the port may not be available and thus tcpserver can't bind to it. I have to wait until the end of TIME-OUT before restarting Pd. I found a solution [1] (restart network service) to release the socket, so that tcpserver can bind to the same port again. But it could be good to handle this inside Pd isn't it ?
So I guess two ways : 1- according to WMR in [1], we can set SO_REUSEADDR via setsockopt(2), but I don't know if this possible without lots of code rewriting... 2- tcpserver could also have a [bind <port_number>( message to select the port to bind to and send out error through its right outlet to notice if port is available or not, so that we can try to bind again until a port is available.
But I'm not very familiar with sockets, so maybe I'm wrong...
Cheers
Antoine
[1] http://serverfault.com/questions/329845/how-to-forcibly-close-a-socket-in-ti...
-- do it yourself http://antoine.villeret.free.fr
2013/5/19 Martin Peach martin.peach@sympatico.ca
Yes, it seems that the routine that adds new connections doesn't check to see if it has passed the number of connection slots. There are MAX_CONNECT slots allocated when [tcpserver] starts.
Thanks for finding this bug!
There is no reason to limit the number of connections to 32 except to not use up memory. I think it could be changed to either dynamically add space for new connections without limit or set MAX_CONNECT with a creation argument.
For now you could recompile it with MAX_CONNECT set to another value. (At some point the OS will run out of sockets. Before that Pd will slow down...)
#define MAX_CONNECT 10000
Martin
On 2013-05-18 17:37, Antoine Villeret wrote:
so I reply to myself...
I found this in the code of both tcpserver.c : #define MAX_CONNECT 32 /* maximum number of connections */
which could be an answer embryo
so, I shouldn't make more than 32 connections on the same tcpserver, ok, but why ? is there a good reason to fix this to 32 ?
and this doesn't tell me why it crashes... reaching the MAX_CONNECT should handles in the code isn't it ?
cheers
a
-- do it yourself http://antoine.villeret.free.**fr http://antoine.villeret.free.fr
2013/5/16 Antoine Villeret <antoine.villeret@gmail.com <mailto:antoine.villeret@**gmail.com antoine.villeret@gmail.com>>
hi all, I've just notice [tcpserver] crashes when the 34th client try toconnect both iemnet and mrpeach are affected
iemnet version send a strange number on the 33th connection (like 2.8686e+07) and crashes on the 34th here is a gdb output for iem : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcdbca746 in tcpserver_connectpoll (x=0x66994c0) at tcpserver.c:503 503 x->x_sr[i] = y; (gdb) watchdog: signaling pd... and for mrpeach : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcddaf585 in tcpserver_connectpoll (x=0xadfc1c0) at tcpserver.c:1113 1113 outlet_float(x->x_sockout, x->x_sr[i]->sr_fd);/* the socket number */ (gdb) watchdog: signaling pd... it happens on ubuntu 12.04 64 bit pd 0.44.2 and SVN update today i'm certainly doing something wrong to get this (like keeping clients connected all the time) but a crash is never welcome... cheers antoine -- do it yourself http://antoine.villeret.free.**fr <http://antoine.villeret.free.fr>______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
shame on me,
there does exist a [port <port_number>( message in iemnet's tcpserver with which I can change the port on the fly the rightmost outlet sends [port -1( if binding failed
but this is not explained in the help patch, I should have to go through the code to see that could I push an updated version of help patch to the SVN ? here it is attached
kind regards
a
-- do it yourself http://antoine.villeret.free.fr
2013/5/20 Antoine Villeret antoine.villeret@gmail.com
Hi Martin,
Thanks for your reply.
For now, I increase the MAX_CONNECT value and I also make each client disconnecting after they receive expected data, and they connect again if needed.
But I experience another issue. If Pd crashes for any reason, the socket stay in a TIME_WAIT state and if Pd restarts asap, the port may not be available and thus tcpserver can't bind to it. I have to wait until the end of TIME-OUT before restarting Pd. I found a solution [1] (restart network service) to release the socket, so that tcpserver can bind to the same port again. But it could be good to handle this inside Pd isn't it ?
So I guess two ways : 1- according to WMR in [1], we can set SO_REUSEADDR via setsockopt(2), but I don't know if this possible without lots of code rewriting... 2- tcpserver could also have a [bind <port_number>( message to select the port to bind to and send out error through its right outlet to notice if port is available or not, so that we can try to bind again until a port is available.
But I'm not very familiar with sockets, so maybe I'm wrong...
Cheers
Antoine
[1] http://serverfault.com/questions/329845/how-to-forcibly-close-a-socket-in-ti...
-- do it yourself http://antoine.villeret.free.fr
2013/5/19 Martin Peach martin.peach@sympatico.ca
Yes, it seems that the routine that adds new connections doesn't check to see if it has passed the number of connection slots. There are MAX_CONNECT slots allocated when [tcpserver] starts.
Thanks for finding this bug!
There is no reason to limit the number of connections to 32 except to not use up memory. I think it could be changed to either dynamically add space for new connections without limit or set MAX_CONNECT with a creation argument.
For now you could recompile it with MAX_CONNECT set to another value. (At some point the OS will run out of sockets. Before that Pd will slow down...)
#define MAX_CONNECT 10000
Martin
On 2013-05-18 17:37, Antoine Villeret wrote:
so I reply to myself...
I found this in the code of both tcpserver.c : #define MAX_CONNECT 32 /* maximum number of connections */
which could be an answer embryo
so, I shouldn't make more than 32 connections on the same tcpserver, ok, but why ? is there a good reason to fix this to 32 ?
and this doesn't tell me why it crashes... reaching the MAX_CONNECT should handles in the code isn't it ?
cheers
a
-- do it yourself http://antoine.villeret.free.**fr http://antoine.villeret.free.fr
2013/5/16 Antoine Villeret <antoine.villeret@gmail.com <mailto:antoine.villeret@**gmail.com antoine.villeret@gmail.com>>
hi all, I've just notice [tcpserver] crashes when the 34th client try toconnect both iemnet and mrpeach are affected
iemnet version send a strange number on the 33th connection (like 2.8686e+07) and crashes on the 34th here is a gdb output for iem : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcdbca746 in tcpserver_connectpoll (x=0x66994c0) at tcpserver.c:503 503 x->x_sr[i] = y; (gdb) watchdog: signaling pd... and for mrpeach : Program received signal SIGSEGV, Segmentation fault. 0x00007fffcddaf585 in tcpserver_connectpoll (x=0xadfc1c0) at tcpserver.c:1113 1113 outlet_float(x->x_sockout, x->x_sr[i]->sr_fd);/* the socket number */ (gdb) watchdog: signaling pd... it happens on ubuntu 12.04 64 bit pd 0.44.2 and SVN update today i'm certainly doing something wrong to get this (like keeping clients connected all the time) but a crash is never welcome... cheers antoine -- do it yourself http://antoine.villeret.free.**fr <http://antoine.villeret.free.fr>______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
On 2013-05-20 08:19, Antoine Villeret wrote:
Hi Martin,
Thanks for your reply.
For now, I increase the MAX_CONNECT value and I also make each client disconnecting after they receive expected data, and they connect again if needed.
But I experience another issue. If Pd crashes for any reason, the socket stay in a TIME_WAIT state and if Pd restarts asap, the port may not be available and thus tcpserver can't bind to it. I have to wait until the end of TIME-OUT before restarting Pd. I found a solution [1] (restart network service) to release the socket, so that tcpserver can bind to the same port again. But it could be good to handle this inside Pd isn't it ?
So I guess two ways : 1- according to WMR in [1], we can set SO_REUSEADDR via setsockopt(2), but I don't know if this possible without lots of code rewriting...
[mrpeach/tcpserver] already does this. If the socket is in some other state than TIME_WAIT it will still block. There is more than one version of [tcpserver] around. In Pd-extended there is [net/tcpserver], [iemnet/tcpserver] and [mrpeach/tcpserver].
2- tcpserver could also have a [bind <port_number>( message to select the port to bind to and send out error through its right outlet to notice if port is available or not, so that we can try to bind again until a port is available.
Yes, I could add that.
Martin
On 2013-05-20 11:58, IOhannes zmölnig wrote:
On 05/20/2013 05:45 PM, Martin Peach wrote:
There is more than one version of [tcpserver] around. In Pd-extended there is [net/tcpserver], [iemnet/tcpserver] and [mrpeach/tcpserver].
isn't [net/tcpserver] the same as [mrpeach/tcpserver]?
Yes, that's it. [iemnet/tcpserver] has a "port" method and [mrpeach/tcpserver] has SO_REUSEADDR. [mrpeach/tcpserver] is duplicated in [net/tcpserver].
Martin
-
Antoine Villeret -
IOhannes zmölnig -
Martin Peach