Hi Thanks for the reply. 
I don't think upgrade or changing resolution part is an option as this is the only concern on existing software. 
I tried to analyse further and I see there are more than one threads which maintain download queues and continuously keep creating easy handle which are reused as soon as removed from multi- like 
- curl_easy_init
---curl_multi_add_handle---curl_multi_perform ....<<timeout at application/client of curl triggers either cancel download so it calls >>
---curl_multi_remove_handle-curl_easy_cleanup

As Curl application keep adding more downloads to download queue, I see immediately that same handle is getting assigned again if curl_easy_init is called. 
So I am wondering if the reuse of the easy handle with multi interface instantaneously is allowed or it is a concern. 
Also I tried to run multiple time to confirm where it crashes and I see following two crashes consistently 
Regards Digam 

The backtrace is fairly consistent. It either 
 #0  0x202c4c4c in ?? ()#1  0x00240174 in showit (data=<optimized out>, type=<optimized out>, ptr=0xb608cb8c "Curl_getaddrinfo: getaddrinfo(3) failed for :80\n", size=48) at src/sendf.c:677#2  0x0024038a in Curl_debug (data=data_at_entry=0xb538c838, type=type_at_entry=CURLINFO_TEXT, ptr=0xb608cb8c "Curl_getaddrinfo: getaddrinfo(3) failed for :80\n", ptr_at_entry=0xb608cb74 "\bE\223\254\070\310\070\265\323\003$", size=48, conn=conn_at_entry=0x0) at src/sendf.c:732#3  0x002403d2 in Curl_infof (data=data_at_entry=0xb538c838, fmt=0xb88e53 "%s: getaddrinfo(3) failed for %s:%d\n") at src/sendf.c:153#4  0x002427be in Curl_getaddrinfo (conn=conn_at_entry=0xac934508, hostname=hostname_at_entry=0xac94b634 "", port=port_at_entry=80, waitp=waitp_at_entry=0xb608d490) at src/hostip6.c:220#5  0x0023e052 in Curl_resolv (conn=conn_at_entry=0xac934508, hostname=0xac94b634 "", port=80, entry=entry_at_entry=0xb608d7e8) at src/hostip.c:463#6  0x0023e0de in Curl_resolv_timeout (conn=conn_at_entry=0xac934508, hostname=<optimized out>, port=<optimized out>, entry=entry_at_entry=0xb608d7e8, timeoutms=timeoutms_at_entry=300000) at src/hostip.c:641#7  0x0023cdd4 in resolve_server (async=0xb608d944, conn=0xac934508, data=0xb538c838) at src/url.c:4785#8  create_conn (data=data_at_entry=0xb538c838, in_connect=in_connect_at_entry=0xac9477dc, async=async_at_entry=0xb608d944) at src/url.c:5283#9  0x0023d61e in Curl_connect (data=data_at_entry=0xb538c838, in_connect=in_connect_at_entry=0xac9477dc, asyncp=asyncp_at_entry=0xb608d944, protocol_done=protocol_done_at_entry=0xb608d941) at src/url.c:5445#10 0x0023068c in multi_runsingle (multi=multi_at_entry=0xb605ce48, now=..., easy=easy_at_entry=0xac9477d0) at src/multi.c:1057#11 0x00230e24 in curl_multi_perform (multi_handle=0xb605ce48, running_handles=running_handles_at_entry=0xb606a6d8) at src/multi.c:1753
or 
#0  addbyter (output=<optimized out>, data=0xb618d474) at src/mprintf.c:1014#1  0x00234126 in dprintf_formatf (data=data_at_entry=0xb618d474, stream=stream_at_entry=0x233aed <addbyter>, format=format_at_entry=0xb618d4b0 "\206k\270", ap_save=...) at src/mprintf.c:877#2  0x002346a2 in curl_mvsnprintf (buffer=<optimized out>, maxlength=<optimized out>, format=format_at_entry=0xb618d4b0 "\206k\270", ap_save=..., ap_save_at_entry=...) at src/mprintf.c:1032#3  0x00240376 in Curl_failf (data=data_at_entry=0xb53417e8, fmt=0xb86f47 "%s: Couldn't resolve host '%s'") at src/sendf.c:170#4  0x0023cd7c in resolve_server (async=0xb618d944, conn=0xaca51800, data=0xb53417e8) at src/url.c:4794#5  create_conn (data=data_at_entry=0xb53417e8, in_connect=in_connect_at_entry=0xaca530bc, async=async_at_entry=0xb618d944) at src/url.c:5283#6  0x0023d59a in Curl_connect (data=data_at_entry=0xb53417e8, in_connect=in_connect_at_entry=0xaca530bc, asyncp=asyncp_at_entry=0xb618d944, protocol_done=protocol_done_at_entry=0xb618d941) at src/url.c:5445#7  0x00230608 in multi_runsingle (multi=multi_at_entry=0xb615ce48, now=..., easy=easy_at_entry=0xaca530b0) at src/multi.c:1057#8  0x00230da0 in curl_multi_perform (multi_handle=0xb615ce48, running_handles=running_handles_at_entry=0xb616a6d8) at src/multi.c:1753

    On Monday, 16 May 2016, 9:53, Daniel Stenberg <daniel_at_haxx.se> wrote:
 

 On Wed, 11 May 2016, d_rasal_at_sky.com wrote:

> I am currently working on our legacy system which has fairly old Curl v7_26.
> It is a multithreaded system and one of the obvious problem which is
> discussed multiple times is discovered during testing - when network is
> unavailable, Dns resolution is taking longer or timing out and curl perform
> is crashing( stack trace is below).

Does it always crash when the DNS resolving times out? What OS is this running
on?

When using the synchronous name resolver backend and doing timeouts, curl is
taking some freedoms with the signal handler in order to fascilitate the
timeout so there's a small risk there.

If you're able to upgrade your libcurl it would be intersting to hear how a
later version works. Or possibly a version rebuilt to use the threaded
resolver instead which times out without a signal handler.

-- 
  / daniel.haxx.se
  

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-users
FAQ: https://curl.haxx.se/docs/faq.html
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-05-17