Repository navigation
Curl_resolver_init is not thread-safe #13065
Description
Activity
I'm pretty sure this is still thread safe, even if we should make it done nicer.
thank you, guys
when could we expect the next release?The next release ships on March 27, 2024 and will become version 8.7.0. The pending release notes for the coming release are always available on this URL: https://curl.se/dev/release-notes.html
Reacted by Nikita TaranovI'd also love to get your advice on how we should proceed on our end. is it safe to use master version instead of the last release? to get the fix earlier. or maybe we could back-port the fix to the last release branch?
is it safe to use master version instead of the last release? to get the fix earlier. or maybe we could back-port the fix to the last release branch?
Do not use master in production. master is our development branch. I suggest use git to cherry pick the fixes you need.
Reacted by Nikita Taranovis it safe to use master version instead of the last release?
I believe sticking to the previous version is fine until the next release ships. I think this not thread-safe warning was a warning and it should be and was fixed, but the effects of the problem are totally harmless.
Reacted by Nikita Taranov- added 2 commits that reference this issue
on Mar 12, 2024
I did this
Hi!
We start getting sanitiser reports like this in our CI.
I assume that this code is supposed to be thread-safe, please correct me if I'm wrong.
If so, seems like the problematic code was introduced recently here:
4224d6e
so static variable
ares_vercould be simultaneously read and modified by two threads.it seems enough to replace l. 176 with
get_ares_version()will do the same call, but now compiler will guarantee single initialisation (btw, I'm not a C expert, do we have this guarantee in C?).I expected the following
no sanitiser complains
curl/libcurl version
curl 8.6.0+
operating system
linux