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.