It's somewhat flaky, slow (6-8 minutes), needs maintenance, and did not
turn up real issues to justify keeping.
Notably it did not help catch a regression seen on Solaris OS: #16915
Follow-up to 90e644f944#13583Closes#18314
`Win32::Process::List` and `Win32::Process`.
To replace external calls to `tasklist.exe` and `taskkill.exe`.
The perl modules are wrappers/binding to Win32 API calls. They avoid
launching external processes with a command shell (including MSYS2),
the external tool, and creating command-lines and parsing tool output.
According to local tests and the CI, one test session calls
`tasklist.exe` 350-400 times. `taskkill.exe` is rarely called:
https://github.com/curl/curl/actions/runs/17012376726?pr=18296
It's hard to predict any possible side-effect of dynamically loading
the two necessary, module DLLs into the Perl process. The MSYS2 runtime
if prone to fail when doing this in fork operations, as seen earlier
with the Win32.DLL module. But, is looks like a symptom, not the root
cause for these failures, because the failures are present with or
without perl.exe loading the Win32.DLL.
Ref: be01b60ce5#18287
Cherry-picked from #18296Closes#18308
This patch fixes flakiness caused by MSBuild scanning the runtests.pl
output for regex patterns. When finding a hit, it returns an error code
to cmake, making the build test CI step fail. This happens rarely after
an earlier mitigation tweaking outputs, but, as expected, it did not
resolve it completely.
MSBuild doesn't have an option to disable this behavior. To fix, this
patch migrates the two affected jobs from MSBuild to Ninja. To align
with existing multi-config logic, it uses the `Ninja Multi-Config`
generator, which hasn't been tested before in CI.
Switching to Ninja was not trivial. Visual Studio to this day relies on
an MS-DOS batch file stored at an unstable location (containing spaces
and parenthesis), to initialize its environment. Without this env,
`cl.exe` is unable to find its own components. GHA does not initialize
it (even if it did, it could only default to a single specific target).
CMake helps with this when using a Visual Studio generator, but doesn't
when using Ninja. (On local machines the VS installer adds a couple
of Start menu items for launching pre-configured command prompts.)
Ref: https://learn.microsoft.com/cpp/build/building-on-the-command-line
The MS-DOS batches don't integrate well with CI envs and even less so
with shell scripts. To avoid it, this patch uses manual configuration.
Also without using environment variables, to make it easy to use and
easy to debug and trace in logs. Configuring Visual Studio is relatively
stable across releases and hasn't changed a whole lot in the last 2
decades, but still may need more maintenance compared to llvm, or pretty
much any other toolchain out there. On the upside, it allows to manually
select compiler version, SDK version, cross-combinations, and allows
choosing clang-cl. The configuration aims to find the latest of these
automatically.
Some traps that had to be avoided:
- need to switch to MS-DOS short names to avoid spaces in the VS
component paths.
- need to switch to forward slashes to avoid confusing downstream tools
with backslashes.
- need to pass either MSYS2 for Windows-style path depending on setting.
- need to use a trick to retrieve the oddly named `ProgramFiles(x86)`
Windows env from shell script.
- need to match VS version (2022) and edition (Enterprise), found on GHA
runners.
- need to pass the CMake generator via env so that the space in the name
doesn't trip the shell when passed via a variable.
- trash and unexpected dirs when detecting SDK/toolchain versions.
- need to pass `-external:W0` to the C compiler to avoid MSVC warning:
`D9007: '/external:I' requires '/external:W'; option ignored`
- using cmake options only, to make it run without relying on envs and
work out-of-the-box when running subsequent cmake sessions.
- some others discovered while making work clang-cl locally in
cross-builds.
Ninja also improves performance in most cases (though wasn't a goal
here). After this patch configure is significantly faster (1.5-2x),
builds are a tiny bit faster, except examples which was twice as fast
with MSBuild. Disk space use is 10% lower.
MSBuild builds remain tested in AppVeyor CI and the UWP job.
Before: https://github.com/curl/curl/actions/runs/17025737223/job/48260856051
After: https://github.com/curl/curl/actions/runs/17027981486/job/48266133301
Fixes:
```
=== Start of file stderr1635
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 4 100 4 0 0 449 0 --:--:-- --:--:-- --:--:-- 500
curl : (22) The requested URL returned error : 429 [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
CUSTOMBUILD : warning : Problem : HTTP error. Will retry in 1 second. 1 retry left. [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
[...]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'D:\a\curl\curl\bld\CMakeFiles\621f80ddbb0fa48179f056ca77842ff0\test-ci.rule;D:\a\curl\curl\tests\CMakeLists.txt' exited with code -1. [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
Error: Process completed with exit code 1.
```
Ref: https://github.com/curl/curl/actions/runs/16966304797/job/48091058271?pr=18287#step:13:3471
Bug: https://github.com/curl/curl/discussions/14854#discussioncomment-14104166
Ref: a19bd43210#18307
Follow-up to 9463769f2e#16583Closes#18301
Pass curl's memory functions to the nghttp3 and ngtcp2 functions that
allow them. This allows custom memory functions passed by the curl user
to be used in nghttp3 and ngtcp2.
Closes#18196
- remove a superfluous if()
- edit the #ifdef to only do the timeout checks when socketpair support
is missing, as that code flow could not be reached otherways anyway
CodeSonar pointed out possible issue that led me to see this.
Closes#18306
`CMAKE_C_FLAGS` is not set by curl, but may contain custom options
required for a successful compiler run, when invoked by these tests.
One such case is when configuring Visual Studio or clang-cl via compiler
options, instead of envs.
Cherry-picked from #18301Closes#18307
When an application install its own OpenSSL verify callback and that
callback invokes `SSL_set_retry_verify()`, the transfer is automatically
paused and does not progress the connect attempt any further until
unpaused via `curl_easy_pause().
Added test758 to verify.
Ref: #18284
Original PR by @Natris
Bug: https://curl.se/mail/lib-2025-08/0012.htmlCloses#18288
Easily triggered when doing an FTP ranged download with the end range
larger than the file size.
A regression since 30de937bda (shipped in curl 8.9.0)
Add test 2307 to verify.
Reported-by: kupavcevdenis on github
Fixes#18283Closes#18295
- they are fake anyway
- these ones look more obvious fake and in need of replacement
- avoids the risk that they might decode to something of value
Closes#18261
Make the:
- mbedTLS valgrind job finish under 14m, vs 15m before.
- OpenSSL -O3 valgrind job finish in 14m30, vs 16m17.
- OpenSSL libssh2 valgrind job finish in 16m, vs 17m30.
- long valgrind rustls job finish 1 minute earlier, in return
for spending 30s more on the other rustls job.
Keep using autotools for the less slow valgrind job to test this combo.
Closes#18290
`Time::HiRes` was already used unconditionally before this patch in
`servers.pm`. This package, and functions used by runtests (`sleep` and
`gettimeofday`) are supported by the minimum Perl version required for
curl:
https://perldoc.perl.org/5.8.0/Time::HiRes
- Drop the `portable_sleep()` wrapper in favor of `Time::HiRes::sleep()`.
- Use `Time::HiRes` unconditionally in `serverhelp.pm`.
- Stop using the `Win32` package where available. It was included
to provide a Windows fallback for `Time::HiRes::sleep()`. It was never
actually called, but the dependency may have loaded `Win32.dll`, which
often appears in failed fork operations in GHA logs.
Ref: a6fed41f6f#5054#5034
Ref: https://github.com/curl/curl/discussions/14854Closes#18287
To not create a file named `nul` in the `tests` directory when running
tests with MSYS2/Cygwin Perl (the only supported Perl for Windows).
I imagine this may cause issues when being written in parallel. Also
`nul` is a reserved filename on Windows.
Closes#18282
Drop three interim macros and mbedTLS version checks in favor of feature
macros defined by mbedTLS itself.
These mbedTLS features require mbedTLS 3.6.0/3.6.1 for production.
Earlier versions may have partial/experimental support for them,
disabled by default and (AFAICS) without documented build options
to enable them.
One feature guard already used the native macro instead of the interim
one before this patch. (`MBEDTLS_SSL_SESSION_TICKETS`)
Ref: https://github.com/curl/curl/pull/18254#issuecomment-3182668817Closes#18271
Replace autotools with cmake to avoid libtool wrappers that are changing
`LD_LIBRARY_PATH` in a way incompatible with the thread sanitizer.
To fix the output when the sanitizier is finding something:
```
==51718==WARNING: Can't write to symbolizer at fd 7
/usr/bin/llvm-symbolizer-18: /home/runner/work/curl/curl/bld/lib/.libs/libcurl.so.4: no version information available (required by /usr/bin/llvm-symbolizer-18)
/usr/bin/llvm-symbolizer-18: symbol lookup error: /home/runner/openssl/lib/libcrypto.so.3: undefined symbol: __tsan_func_entry
```
Ref: https://github.com/curl/curl/actions/runs/16911402500/job/47913783729#step:39:4466
After:
```
13:50:04.117885 == Info:ThreadSanitizer: thread T1 finished with ignores enabled, created at:
closing connection #0#0 pthread_create <null> (libtests+0x6bc0f) (BuildId: 4fe889446291259934205ac03931c397aa0210d3)
#1 Curl_thread_create /home/runner/work/curl/curl/lib/curl_threads.c:73:6 (libcurl.so.4+0x55a76) (BuildId: cb0f14ba2ad68c9cab0c980d9a5d7a53cc0782da)
#2 async_thrdd_init /home/runner/work/curl/curl/lib/asyn-thrdd.c:500:26 (libcurl.so.4+0x1c153) (BuildId: cb0f14ba2ad68c9cab0c980d9a5d7a53cc0782da)
[...]
```
Ref: https://github.com/curl/curl/actions/runs/16939193922/job/48003405272?pr=18274#step:39:4018
Also:
- disable memory tracker which turned out to be incompatible with
the thread sanitizer and detaching threads.
Ref: #18263 and #curl IRC.
- the job is ~30 seconds faster after this patch.
Reported-by: Stefan Eissing
Bug: https://github.com/curl/curl/pull/18263#issuecomment-3179279440
Follow-up to a2bcec0ee0#14751Closes#18274
If there is only a leading slash in the path, keep that. Also add an
assert to make sure the path is never blank.
Reported-by: Google Big Sleep
Closes#18266
actions/checkout@v5 requires a newer libstdc++ than the container
contains. Update it to a backwards-compatible version just like we
already do for libc6.
Ref: #18250Closes#18255
Add support for CURLOPT_READFUNCTION with WebSocket urls when *not* in
connect-only mode, e.g. when using curl_multi_perform.
Install the callback function and set CURLOPT_UPLOAD. Return
CURL_READFUNC_PAUSE when having nothing more to send and unpause the
transfer when more data is ready.
This will send the read bytes in a WebSocket BINARY frame.
Add support for this mode in the pytest "ws_data" client and have all
tests run in 'curl_ws_send/recv' and 'peform' mode as well.
Add `curl_ws_start_frame()`. Document, cover in libcurl-ws.md and
explain the READFUNCTION mode for websockets.
Add example `websocket-updown` for this.
Closes#17683
* Add more tracing information to c-ares errors.
* remove CURL_ASYNC_SUCCESS, rename `ares->last_status` to
`ares->ares_status`. Give trace explanation for "common"
errors
* add ares "csv" information to tracing on failure
* DoH: invoke `Curl_resolver_error()` on failure to populate
error buf
Closes#18247
Instead realloc to the largest buffer and keep that for reuse during the
entire lifetime.
Co-authored-by: Jay Satiro <raysatiro@yahoo.com>
Closes#18233
