Hi Cristian, Thanks for your insight –
We are no doing more than using Libcurl within a thread, executed inside a container in order to send many messages toward http AS. By attaching to the process where we observed the described symptoms, we managed to retrieve several threads stuck in curl_timediff_us function ( bt full on thread ) #0 0x00007f844a387b1a in Curl_timediff_us () from /home/actility/lib/libcurl.so.4 No symbol table info available. #1 0x00007f844a382923 in Curl_splay () from /home/actility/lib/libcurl.so.4 No symbol table info available. #2 0x00007f844a382c40 in Curl_splayremove () from /home/actility/lib/libcurl.so.4 No symbol table info available. #3 0x00007f844a3698cd in Curl_expire_ex () from /home/actility/lib/libcurl.so.4 No symbol table info available. #4 0x00007f844a369ec4 in process_pending_handles () from /home/actility/lib/libcurl.so.4 No symbol table info available. #5 0x00007f844a36b3c8 in multi_runsingle () from /home/actility/lib/libcurl.so.4 No symbol table info available. #6 0x00007f844a36d2d9 in curl_multi_perform () from /home/actility/lib/libcurl.so.4 Something we do not experienced out of a container. De : Cristian Rodríguez <[email protected]> Envoyé : mercredi 10 septembre 2025 16:27 À : libcurl development <[email protected]> Cc : Stephane Cruchon <[email protected]>; Gilles Lefèvre <[email protected]>; R&D Support <[email protected]> Objet : Re: High CPU usage associated to busy loop in curl_timediff_us() Vous n’obtenez pas souvent d’e-mail à partir de [email protected]<mailto:[email protected]>. Pourquoi c’est important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Wed, Sep 10, 2025 at 10:45 AM Stephane Cruchon via curl-library <[email protected]<mailto:[email protected]>> wrote: Can you put your AI down and tell us exactly what you are doing.. a container shouldn't have an unstable clock, it should be as stable as the host..unless of course the host is over capacity.. also even in a virtual machine most of the clock instability issues have been already sorted out.. time_t should be an signed 64 bit integer if you are running any recentish system that can host docker containers. POSIX 1.2024 confirms that and mandates so, so it is probably unrelated to the QNX issue. [Logo]<https://www.actility.com/> [Logo] Stephane Cruchon R&D team Manager Support Buy hardware in ThingPark Market<https://market.thingpark.com/>, try (free) on ThingPark Community<https://community.thingpark.org/>, deploy with Actility<https://www.actility.com/> [Banner]<https://www.actility.com/timeline-of-events/> The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. Actility.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
