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.

Reply via email to