You might want to try running under rr (record and replay) to find out where the memory usage is diverging from your expectations.
On Fri, May 12, 2017 at 11:21 AM Srinivasa Srikanth Podila < [email protected]> wrote: > Update: I am using multiple poll-handles on same sockfd's. However the > poll-handles are from different requests. It is like sending multiple HTTP > gets on same socket. > Please let me know if any problem with libuv to handle this. > > > On Friday, 12 May 2017 19:11:48 UTC+5:30, Srinivasa Srikanth Podila wrote: >> >> Hi, >> >> I am allocating memory for a struct "request" using malloc. The request >> object has a uv_poll_handle as a member. >> >> The request updates its poll_handle on a sockfd *[using >> uv_poll_init_socket(loop, &request->poll_handle, sockfd)] *received by >> libcurl. After init_socket, i update poll_handle.data to "request" object >> so that i could use in uv callback context, and starts polling on it using* >> [uv_poll_start(&request->poll_handle, events, poll_req_uv_cb);]* >> >> Now when i get poll_remove notification from libcurl, I am using >> *[uv_close((uv_handle_t >> *)&request->poll_handle, process_request_response)]. *The >> process_request_response is close_callback which i am planning to free the >> allocated "request" object. >> >> I do it for many request objects in a default-loop continuously. It works >> fine for some time and after some time, i see the SIGSEGV as >> poll_handle.data is NULL and loop object also NULL in the close callback api >> *[process_request_response]*. >> >> Please check the inline gdb logs. >> >> (gdb) p req >> $1 = (uv_handle_t *) 0xe159b0 >> (gdb) p *req >> $2 = {*data = 0x0, loop = 0x0*, type = UV_POLL, close_cb = 0x404b5d >> <process_request_response>, handle_queue = {0xe09760, 0x62e6a0}, u = {fd = >> 0, reserved = {0x0, 0x0, 0x0, >> 0x0}}, next_closing = 0xe09740, flags = 3} >> >> Just before i close the uv_poll_handle, I have a print to ensure if i >> have the data. >> INFO, 12:54:31.266583, curl_socket_cb, STOP POLL Curl Handle:0xeb26c0, >> Request:0xe159a0, poll_handle:0xe159b0 poll_request:0xe159a0 >> >> Please let me know if there is any problem in my design approach (or) let >> me know if there is any bug in this area. >> >> Thanks, >> Srikanth >> > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
