curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_multi_perform sometimes does not return while its threadus es1 00% cpu resources

From: <h9791521_at_docomo.ne.jp>
Date: Thu, 13 Dec 2018 16:46:10 +0900

Could somebody please explain to me what is done in the following loop?
curl\lib\multi.c
 do {
   multi->timetree = Curl_splaygetbest(now, multi->timetree, &t);
   if(t)
     /* the removed may have another timeout in queue */
     (void)add_next_timeout(now, multi, t->payload);

 } while(t);


>When you build on a system with unsigned time_t, you MUST also define
>HAVE_TIME_T_UNSIGNED, did you do that?

Thank you for giving me advice.
I'm looking into that.
In the meantime, I narrowed down where the loop get stuck when the event ocurred

curl\lib\multi.c
 do {
   multi->timetree = Curl_splaygetbest(now, multi->timetree, &t);
   if(t)
     /* the removed may have another timeout in queue */
     (void)add_next_timeout(now, multi, t->payload);

 } while(t);

Lib\spray.c
 if(compare(i, t->key) < 0) { <====== never become negative
   /* even the smallest is too big */
   *removed = NULL;
   return t;
 }

https://github.com/curl/curl/issues/2004
The loop happens on systems where time_t is defined to an unsigned type (e.g. QNX).
Differences between unsigned types will never become negative.

Is this also true for windows?

iPhoneから送信

2018/12/11 21:10、Daniel Stenberg <daniel_at_haxx.se>のメール:

>> On Tue, 11 Dec 2018, "h9791521_at_docomo.ne.jp" via curl-library wrote:
>>
>> When I call curl_multi_perform, it sometimes does not return while its
>> thread uses 100% cpu resources. It happens sometimes, not always. I use
>> libcurl 7.59.0 on windows.
>
> I think you need to help out a bit more and provide us with a reproducible
> example for us to understand and debug this issue.
>
> While I can't spot any significant change done since 7.59.0 that seems likely
> to have fixed such an issue, I would still urge you to try out the latest
> version first before spending a lot of time hunting this down. It might
> already be fixed!
>
>> The loop happens on systems where time_t is defined to an unsigned type.
>
> This stood out to me. Isn't Windows always using a signed time_t ?
>
> When you build on a system with unsigned time_t, you MUST also define
> HAVE_TIME_T_UNSIGNED, did you do that?
>
> --
>
> / daniel.haxx.se

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-12-13