Hello,

I am using curl_multi_socket_action interface for uploading files in an
asynchronous way. I am using libev (lib event library) for asynchronous
communication.

I am registering two callbacks for CURLMOPT_SOCKETFUNCTION and
CURLMOPT_TIMERFUNCTION respectively.

In the call back of CURLMOPT_SOCKETFUNCTION, I am registering another
callback with libevent which takes care of doing curl_multi_socket_action.
(Hence making sure curl_mutli_socket_action happens in a different thread).

In the call back of CURLMOPT_ TIMERFUNCTION, I am registering another
callback with libevent which takes care of doing curl_multi_socket_action
but with a timeout value of 0. (Hence making sure curl_mutli_socket_action
happens in a different thread).

As soon as I have created my multi handle using curl_multi_init, I call
“ev_timer_init(&g.timer_event, timer_cb, 0., 0.);” which is nothing but
calling curl_multi_socket_action with timeout. (as suggested in curl
example evhiperfifo.c)

I tried two cases. In 1st case I assumed I need not do mutex locking as
libevent takes care of locking as it runs in a separate thread:

Effect of case1: I get segmentation fault as below:

Program terminated with signal 11, Segmentation fault.

#0 0x00000000004524e3 in Curl_raw_nequal ()

(gdb) bt

#0 0x00000000004524e3 in Curl_raw_nequal ()

#1 0x0000000000456c8f in Curl_checkheaders ()

#2 0x0000000000458209 in Curl_http ()

#3 0x000000000046303b in Curl_do ()

#4 0x000000000044f67c in multi_runsingle ()

#5 0x000000000044ffcf in multi_socket ()

#6 0x00000000004500af in curl_multi_socket_action ()

#7 0x00000000004213fe in
CORE::SERVER_COMMUNICATOR::ServerAgent::executeJob (loop=0x7f408060b840,
data=0xb8c278, action=1)

    at
/home/sandeep/SyncProjectLinux/onecomsync-linux//src/core/ServerCommunicator/src/ServerAgent.cpp:333

#8 0x00007f4080400b6f in ev_invoke_pending () from /usr/lib/libev.so.4

#9 0x00007f4080404c1d in ev_run () from /usr/lib/libev.so.4

#10 0x0000000000416174 in ev_loop (loop=0x7f408060b840, flags=0) at
/usr/local/include/ev.h:810

#11 0x000000000041c3d4 in CORE::SERVER_COMMUNICATOR::ServerAgent::dowait
(this=0x9c08c0) at
/home/sandeep/SyncProjectLinux/onecomsync-linux//src/core/ServerCommunicator/include/ServerAgent.h:37

#12 0x000000000041ee66 in boost::_mfi::mf0<void,
CORE::SERVER_COMMUNICATOR::ServerAgent>::operator() (this=0x7f407f69fac0,
p=0x9c08c0) at /usr/include/boost/bind/mem_fn_template.hpp:49

#13 0x000000000041edd6 in
boost::_bi::list1<boost::_bi::value<CORE::SERVER_COMMUNICATOR::ServerAgent*>
>::operator()<boost::_mfi::mf0<void,
CORE::SERVER_COMMUNICATOR::ServerAgent>, boost::_bi::list0> (

    this=0x7f407f69fad0, f=..., a=...) at
/usr/include/boost/bind/bind.hpp:253

#14 0x000000000041ed4b in boost::_bi::bind_t<void, boost::_mfi::mf0<void,
CORE::SERVER_COMMUNICATOR::ServerAgent>,
boost::_bi::list1<boost::_bi::value<CORE::SERVER_COMMUNICATOR::ServerAgent*>
> >::operator() (

    this=0x7f407f69fac0) at /usr/include/boost/bind/bind_template.hpp:20

#15 0x000000000041ec9b in
boost::asio::asio_handler_invoke<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, CORE::SERVER_COMMUNICATOR::ServerAgent>,
boost::_bi::list1<boost::_bi::value<CORE::SERVER_COMMUNICATOR::ServerAgent*>
> > > (function=...) at /usr/include/boost/asio/handler_invoke_hook.hpp:64

#16 0x000000000041eb74 in
boost_asio_handler_invoke_helpers::invoke<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, CORE::SERVER_COMMUNICATOR::ServerAgent>,
boost::_bi::list1<boost::_bi::value<CORE::SERVER_COMMUNICATOR::ServerAgent*>
> >, boost::_bi::bind_t<void, boost::_mfi::mf0<void,
CORE::SERVER_COMMUNICATOR::ServerAgent>,
boost::_bi::list1<boost::_bi::value<CORE::SERVER_COMMUNICATOR::ServerAgent*>
> > > (

    function=..., context=...) at
/usr/include/boost/asio/detail/handler_invoke_helpers.hpp:39

#17 0x000000000041ea1b in
boost::asio::detail::completion_handler<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, CORE::SERVER_COMMUNICATOR::ServerAgent>,
boost::_bi::list1<boost::_bi::value<CORE::SERVER_COMMUNICATOR::ServerAgent*>
> > >::do_complete (owner=0x9c1200, base=0xb26fd0) at
/usr/include/boost/asio/detail/completion_handler.hpp:63

#18 0x000000000043dc85 in
boost::asio::detail::task_io_service_operation::complete (this=0xb26fd0,
owner=...) at
/usr/include/boost/asio/detail/task_io_service_operation.hpp:35

#19 0x000000000043ea53 in boost::asio::detail::task_io_service::do_one
(this=0x9c1200, lock=..., this_idle_thread=0x7f407f69fcb0) at
/usr/include/boost/asio/detail/impl/task_io_service.ipp:278

#20 0x000000000043e76c in boost::asio::detail::task_io_service::run
(this=0x9c1200, ec=...) at
/usr/include/boost/asio/detail/impl/task_io_service.ipp:130

#21 0x000000000043ed4f in boost::asio::io_service::run (this=0x9c08d8) at
/usr/include/boost/asio/impl/io_service.ipp:57

#22 0x000000000044005a in boost::_mfi::mf0<unsigned long,
boost::asio::io_service>::operator() (this=0x9c1688, p=0x9c08d8) at
/usr/include/boost/bind/mem_fn_template.hpp:49

#23 0x000000000043ffcb in
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*>
>::operator()<unsigned long, boost::_mfi::mf0<unsigned long,
boost::asio::io_service>, boost::_bi::list0> (this=0x9c1698,

    f=..., a=...) at /usr/include/boost/bind/bind.hpp:243

#24 0x000000000043ff79 in boost::_bi::bind_t<unsigned long,
boost::_mfi::mf0<unsigned long, boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> >
>::operator() (this=0x9c1688)

    at /usr/include/boost/bind/bind_template.hpp:20

#25 0x000000000043ff3e in
boost::detail::thread_data<boost::_bi::bind_t<unsigned long,
boost::_mfi::mf0<unsigned long, boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > >::run
(this=0x9c1500) at /usr/include/boost/thread/detail/thread.hpp:61

#26 0x00007f408081cba9 in thread_proxy () from
/usr/lib/libboost_thread.so.1.46.1

#27 0x00007f407f92cefc in start_thread (arg=0x7f407f6a0700) at
pthread_create.c:304

#28 0x00007f407fc2389d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112

#29 0x0000000000000000 in ?? ()

CASE 2: I explicitly do mutex locking where ever I call any curl_multi
functions (be it curl_multi_socket_action or curl_multi_assign). (I used
Boost scoped lock)

Effect: I see mutex lock is always blocked on the call back associated with
CURLMOPT_ TIMERFUNCTION, hence the actual curl_multi_socket_action which is
associated with the callback CURLMOPT_SOCKETFUNCTION never gets a chance.
Hence none of my files would download.

PLEASE SUGGEST WHICH APPROACH I NEED TO FOLLOW (leave libevent to take care
of locking or I need to do explicitly) AND WHY IS THE SEGMENTATION FAULT.

And one more question: I would never want to call curl_multi_cleanup as my
application would always be running. Having said that do I still need to
call ev_loop(loop, 0) as discussed in the example evhiperfifo.c ???

Thanks and Regards,

-Sandeep A

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-27