00:00:01  <jshanab_>ooook, this place is deader than a Texas salad bar.
00:05:42  * brendanashworthjoined
00:10:09  * brendanashworthquit (Ping timeout: 248 seconds)
00:58:54  * rje_changed nick to rje
01:23:39  * niskaquit (Quit: Leaving)
01:24:50  * niskajoined
01:40:22  * parshapquit (Ping timeout: 276 seconds)
01:41:22  * parshapjoined
02:16:13  * daurnimatorquit (Changing host)
02:16:13  * daurnimatorjoined
07:11:44  * saghuljoined
07:35:07  * rendarjoined
08:10:47  * sgimeno__changed nick to sgimeno
08:36:49  * sgimeno_joined
08:39:26  * sgimenoquit (Ping timeout: 240 seconds)
09:05:30  * saghulquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:00:22  * saghuljoined
10:25:09  * mylesborinsquit (Remote host closed the connection)
10:25:50  * mylesborinsjoined
12:37:41  * sgimeno__joined
12:40:46  * sgimeno_quit (Ping timeout: 276 seconds)
12:47:49  * saghulquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:22:38  * saghuljoined
14:18:10  * Jacob843quit (Read error: Connection reset by peer)
14:45:13  * santjagojoined
14:47:14  <santjago>Hi. What could be a reason for a uv_stream_t hanging (1st send is a success, on any subsequent it just holds the data in write_queue and doesn't actually send it) ?
14:50:45  * Fishrock123joined
15:11:28  * jasnelljoined
15:14:57  <saghul>santjago TCP connection might be broken, it can take a long time to decet.
15:22:38  <santjago>well, does uv_is_active((uv_handle_t *)handle) == 0 guarantee it's alive?
15:25:34  <santjago>Also, messages are sent by timer, each 3000msec, I've run it for at least 5 minutes with, it didn't yield any error. It's also running on localhost so I'd not think of unstable connection.
15:34:14  <saghul>Alive doesn't mean the TCP connection is actually working
15:34:27  <saghul>Hum
15:34:31  <saghul>That's weird indeed.
15:34:42  <saghul>Are you reusing any requests?
15:37:32  * d0rukjoined
15:37:57  <santjago>no, they're free'd in *uv_write_cb
15:38:07  <santjago>just after request is sent
15:39:56  <santjago>I've seen the stream->connect_req check in source code. So I've checked in debugger, my handle's connect_req is not NULL'ed
15:41:09  <santjago>But when I try to nullify it just after uv_tcp_connect, It segfaults with assertion failure inside uv__write: assert(req->handle == stream);
16:36:21  * saghulquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:42:29  * santjagoquit (Ping timeout: 260 seconds)
18:06:26  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
19:56:44  <jshanab>I just had a similar situation between server and a camera in which the tcp socket stopped receiving, so in wireshark there are tcp window size errors but the acks keep coming so it stays alive. the send in this case was mistakenly implemented without a timeout and it just blocked forever. I can imagine a similar scenario causing issues. Is data moving out the connection?
20:52:39  * Fishrock123quit (Remote host closed the connection)
21:06:34  * Fishrock123joined
21:39:11  * Fishrock123quit (Quit: Leaving...)
22:09:46  * Jacob843joined
23:40:16  * jasnellquit (Ping timeout: 246 seconds)