On 3/6/2017 12:07 AM, Saurav Babu wrote:
> I'm using libcurl v7.50.2. There is an application using libcurl which got blocked
> in select() function call in libcurl. When application got terminated then below
> backtrace was observed:
>
> (gdb)bt full
> #0 0xb5f73414 in select () at /usr/src/debug//////////////glibc-2.20/misc/../sysdeps/unix/syscall-template.S:81
> No locals.
> #1 0xb643bb5c in Curl_poll (ufds=ufds_at_entry=0xbe4625e8, nfds=nfds_at_entry=1, timeout_ms=timeout_ms_at_entry=-1) at /usr/src/debug/curl-7.50.2/lib/select.c:519
> pending_tv = {tv_sec = 17, tv_usec = -1102699240}
> ptimeout = 0x0
> fds_read = {__fds_bits = {65536, 0 <repeats 31 times>}}
> fds_write = {__fds_bits = {0 <repeats 32 times>}}
> fds_err = {__fds_bits = {0 <repeats 32 times>}}
> maxfd = 16
> initial_tv = {tv_sec = 0, tv_usec = 0}
> fds_none = false
> i = <optimized out>
> pending_ms = 0
> error = <optimized out>
> r = <optimized out>
> #2 0xb6444e62 in waitperform (timeout_ms=-1, conn=0x1a8e90) at /usr/src/debug/curl-7.50.2/lib/asyn-ares.c:281
> data = 0xfc3f0
> nfds = <optimized out>
> bitmask = 17
> socks = {16, -1237319519, -1, 0, 0, -1237037511, 16, 1741928, 2, -1102699020, 11, 1891400, 1067992, 374432, -1237037839, -1237343593}
> pfd = {{fd = 16, events = 65, revents = 0}, {fd = 6, events = 0, revents = 0}, {fd = 2, events = -27544, revents = 26}, {fd = 16, events = 65, revents = 0}, {fd = 1740432, events = 0, revents = 0}, {fd = 28, events = 0, revents = 0}, {fd = 0, events = -2752, revents = 35}, {fd = 12, events = -24128, revents = -18875}, {fd = 2, events = -20344, revents = -18959}, {fd = -1236861368, events = -12016, revents = 21}, {fd = 12, events = 19812, revents = 16}, {fd = 8818, events = 8773, revents = 0}, {fd = 8818, events = -8721, revents = 133}, {fd = 1067992, events = 2705, revents = -18880}, {fd = 8818, events = 8773, revents = 0}, {fd = 3, events = 28104, revents = 11}}
> i = <optimized out>
> num = 1
> #3 0xb64450d2 in Curl_resolver_wait_resolv (conn=conn_at_entry=0x1a8e90, entry=entry_at_entry=0xbe462744) at /usr/src/debug/curl-7.50.2/lib/asyn-ares.c:387
> tv = {tv_sec = 1033200, tv_usec = 1740432}
> store = {tv_sec = 0, tv_usec = -1000}
> timediff = <optimized out>
> itimeout = -1
> timeout_ms = <optimized out>
> tvp = <optimized out>
> result = CURLE_OK
> data = 0xfc3f0
> timeout = -1
> now = {tv_sec = 8818, tv_usec = 8771}
> temp_entry = 0xb6444fb5 <Curl_resolver_is_resolved+44>

#3 doesn't look right, store tv_usec should not be negative. A read of
the code in that area [1] only shows one possibility for that,

  timeout = Curl_timeleft(data, &now, TRUE);
  if(!timeout)
    timeout = CURL_TIMEOUT_RESOLVE * 1000; /* default name resolve
timeout */

Curl_timeleft can return -1 if expired; and indeed I suspect that is
what happens since later:

    store.tv_sec = itimeout/1000;
    store.tv_usec = (itimeout%1000)*1000;

(-1%1000)*1000 result is -1000 and then later:

    timeout_ms = (int)(tvp->tv_usec/1000);

(int)(-1000/1000) result is -1 so that's timeout_ms. Again I'm assuming
here since tvp is optimized out but based on the garbage results in tv
it seems impossible tvp would point to tv.

So either fix for timeout <=0 at the very beginning and set the default
timeout or since it's expired already just return? Should the resolve be
attempted even if timeout already occurred before the loop?

[1]: https://github.com/curl/curl/blob/curl-7_53_1/lib/asyn-ares.c#L361-L387

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-03-06