Rework the event based handling of transfers and connections to
be "localized" into a single source file with clearer dependencies.
- add multi_ev.c and multi_ev.h
- add docs/internal/MULTI-EV.md to explain the overall workings
- only do event handling book keeping when the socket callback
is set
- add handling for "connection only" event tracking, when internal
easy handles are used that are not really tied to a connection.
Used in connection pool.
- remove transfer member "last_poll" and connections "shutdown_poll"
and keep all that internal to multi_ev.c
- add CURL_TRC_M() for tracing of "multi" related things, including
event handling and connection pool operations. Add new trace
feature "multi" for trace config.
multi traces will show exactly what is going on in regard to
event handling.
- multi: trace transfers "mstate" in every CURL_TRC_M() call
- make internal trace buffer 2048 bytes and end the silliness
with +n here -m there. Adjust test 1652 expectations of resulting
length and input edge cases.
- add trace feature "lib-ids" to perfix libcurl traces with transfer
and connection ids. Useful for debugging libcurl applications.
Closes#16308
Make it possible to build curl for Windows CE using the CeGCC toolchain.
With both CMake and autotools, including tests and examples, also in CI.
The build configuration is the default one with Schannel enabled. No
3rd-party dependencies have been tested.
Also revive old code to make Schannel build with Windows CE, including
certificate verification.
Builds have been throughougly tested. But, I've made no functional tests
for this PR. Some parts (esp. file operations, like truncate and seek)
are stubbed out and likely broken as a result. Test servers build, but
they do not work on Windows CE. This patch substitutes `fstat()` calls
with `stat()`, which operate on filenames, not file handles. This may or
may not work and/or may not be secure.
About CeGCC: I used the latest available macOS binary build v0.59.1
r1397 from 2009, in native `mingw32ce` build mode. CeGCC is in effect
MinGW + GCC 4.4.0 + old/classic-mingw Windows headers. It targets
Windows CE v3.0 according to its `_WIN32_WCE` value. It means this PR
restores portions of old/classic-mingw support. It makes the Windows CE
codepath compatible with GCC 4.4.0. It also adds workaround for CMake,
which cannot identify and configure this toolchain out of the box.
Notes:
- CMake doesn't recognize CeGCC/mingw32ce, necessitating tricks as seen
with Amiga and MS-DOS.
- CMake doesn't set `MINGW` for mingw32ce. Set it and `MINGW32CE`
manually as a helper variable, in addition to `WINCE` which CMake sets
based on `CMAKE_SYSTEM_NAME`.
- CMake fails to create an implib for `libcurl.dll`, due to not
recognizing the platform as a Windowsy one. This patch adds the
necessary workaround to make it work.
- headers shipping with CeGCC miss some things curl needs for Schannel
support. Fixed by restoring and renovating code previously deleted
old-mingw code.
- it's sometime non-trivial to figure out if a fallout is WinCE,
mingw32ce, old-mingw, or GCC version-specific.
- WinCE is always Unicode. With exceptions: no `wmain`,
`GetProcAddress()`.
- `_fileno()` is said to convert from `FILE *` to `void *` which is
a Win32 file `HANDLE`. (This patch doesn't use this, but with further
effort it probably could be.)
https://stackoverflow.com/questions/3989545/how-do-i-get-the-file-handle-from-the-fopen-file-structure
- WinCE has no signals, current directory, stdio/CRT file handles, no
`_get_osfhandle()`, no `errno`, no `errno.h`. Some of this stuff is
standard C89, yet missing from this platform. Microsoft expects
Windows CE apps to use Win32 file API and `FILE *` exclusively.
- revived CeGCC here (not tested for this PR):
https://building.enlyze.com/posts/a-new-windows-ce-x86-compiler-in-2024/
On `UNDER_CE` vs. `_WIN32_WCE`: (This patch settled on `UNDER_CE`)
- A custom VS2008 WinCE toolchain does not set any of these.
The compiler binaries don't contain these strings, and has no compiler
option for targeting WinCE, hinting that a vanilla toolchain isn't
setting any of them either.
- `UNDER_CE` is automatically defined by the CeGCC compiler.
https://cegcc.sourceforge.net/docs/details.html
- `UNDER_CE` is similar to `_WIN32`, except it's not set automatically
by all compilers. It's not supposed to have any value, like a version.
(Though e.g. OpenSSL sets it to a version)
- `_WIN32_WCE` is the CE counterpart of the non-CE `_WIN32_WINNT` macro.
That does return the targeted Windows CE version.
- `_WIN32_WCE` is not defined by compilers, and relies on a header
setting it to a default, or the build to set it to the desired target
version. This is also how `_WIN32_WINNT` works.
- `_WIN32_WCE` default is set by `windef.h` in CeGCC.
- `_WIN32_WCE` isn't set to a default by MSVC Windows CE headers (the
ones I checked at least).
- CMake sets `_WIN32_WCE=<ver>`, `UNDER_CE`, `WINCE` for MSVC WinCE.
- `_WIN32_WCE` seems more popular in other projects, including CeGCC
itself. `zlib` is a notable exception amongst curl dependencies,
which uses `UNDER_CE`.
- Since `_WIN32_WCE` needs "certain" headers to have it defined, it's
undefined depending on headers included beforehand.
- `curl/curl.h` re-uses `_WIN32_WCE`'s as a self-guard, relying on
its not-(necessarily)-defined-by-default property:
25b445e479/include/curl/curl.h (L77)
Toolchain downloads:
- Windows:
https://downloads.sourceforge.net/cegcc/cegcc/0.59.1/cegcc_mingw32ce_cygwin1.7_r1399.tar.bz2
- macOS Intel:
https://downloads.sourceforge.net/cegcc/cegcc/0.59.1/cegcc_mingw32ce_snowleopard_r1397.tar.bz2Closes#15975
After fixing support for x32, unlock eventfd support for all CPUs.
Before this patch, it was explicitly limited to 64-bit ones.
You can disable eventfs manually on systems where it's auto-detected:
- cmake: `-DHAVE_EVENTFD=0`
- configure: `export ac_cv_func_eventfd=0`
Ref: c2aa504ab9#16239Closes#16277
- fold DoH and async HTTPS-RR handling into common code.
have common cleanups, etc. Have a CURLcode result in async
handling to allow HTTPS RR parsing to fail.
- keep target, ipv4hints, ipv6hints, port and echconfig also
when resolving via cares. We need to know `target` and `port`
when evaluating possible ALPN candidates to not go astray.
- add CURL_TRC_DNS for tracing DNS operations
- replace DoH specific tracing with DNS, use doh as alias
for dns in curl_global_tracea()
Closes#16132
When the c-ares setup fails and we get a NULL channel, the resolve still
continues and we just need to survive it and just not get any HTTPS RR.
Reported-by: nono303 on github
Fixes#16216Closes#16244
The eventfd manpage says:
A write(2) fails with the error EINVAL if the size of the supplied
buffer is less than 8 bytes
When doing x32 on a 64-bit system, pointers are still four bytes so this
code must not use the size of a pointer but the size of a 64-bit type.
Fixes#16237
Reported-by: Jan Engelhardt
Closes#16239
With `CURL_DISABLE_SOCKETPAIR` defined and `USE_HTTPSRR_ARES`
undefined, the local variable `socketi` was unused.
This fixes a regression from commit 0d4fdbf15d.
Closes https://github.com/curl/curl/pull/16179
By removing 'data' from the thread struct and passing it in as an
argument we avoid the case it could be dereferenced before stored when
shutting down HTTPS RR.
Also reordered the struct fields a little to remove holes.
Closes#16169
- replace deprecated `ares_init()` call with `ares_init_options()`.
Follow-up to 0d4fdbf15d#16054
- dedupe `CARES_STATICLIB` initalizations into `curl_setup.h`, to
ensure it's defined before the first (and every) `ares.h` include and
avoid a potential confusion.
- move `CARES_NO_DEPRECATED` from build level to `curl_setup.h`.
To work regardless of build system.
It is necessary because curl calls `ares_getsock()` from two places,
of which one feeds a chain of wrappers: `Curl_ares_getsock()`,
`Curl_resolver_getsock()`, `Curl_resolv_getsock()`.
Closes#16131
Allow building with c-ares and yet use threaded resolver for the main
host A/AAAA resolving:
`--with-ares` provides the c-ares install path and defaults to use
c-ares for name resolving
`--with-threaded-resolver` still uses c-ares in the build (for HTTPS)
but uses the threaded resolver for "normal" resolves.
It works similarly for cmake: ENABLE_ARES enables ares, and if
ENABLE_THREADED_RESOLVER also is set, c-ares is used for HTTPS RR and
the threaded resolver for "normal" resolves.
HTTPSRR and c-ares-rr are new features return by curl_version_info() and
thus shown by curl -V.
The c-ares-rr feature bit is there to make it possible to distinguish
between builds using c-ares for all name resolves and builds that use
the threaded resolves for the regular name resolves and c-ares for
HTTPSRR only. "c-ares-rr" means it does not use c-ares for "plain" name
resolves.
HTTPSRR support is EXPERIMENTAL only.
Closes#16054
When employing eventfd for socketpair, there is only one file
descriptor. Closing that fd twice might result in fd corruption.
Thus, we should avoid closing the eventfd twice, following the
pattern in lib/multi.c.
Fixes#15725Closes#15727
Reported-by: Christian Heusel
- For the threaded resolver backend on Windows, revert back to
exclusively use the threaded resolver with libcurl-owned threading
instead of GetAddrInfoExW with Windows-owned threading.
Winsock (the Windows sockets library) has a bug where it does not wait
for all of the name resolver threads it is managing to terminate before
returning from WSACleanup. The threads continue to run and may cause a
crash.
This commit is effectively a revert of several commits that encompass
all GetAddrInfoExW code in libcurl. A manual review of merge conflicts
was used to resolve minor changes that had modified the code for
aesthetic or build reasons in other commits.
Prior to this change if libcurl was built with the threaded resolver
backend for Windows, and Windows 8 or later was the operating system at
runtime, and the caller was not impersonating another user, then libcurl
would use GetAddrInfoExW to handle asynchronous name lookups.
GetAddrInfoExW support was added in a6bbc87f, which preceded 8.6.0, and
prior to that the threaded resolver backend used libcurl-owned threading
exclusively on Windows.
Reported-by: Ionuț-Francisc Oancea
Reported-by: Razvan Pricope
Ref: https://developercommunity.visualstudio.com/t/ASAN:-heap-use-after-free-in-NdrFullPoin/10654169
Fixes https://github.com/curl/curl/issues/13509#issuecomment-2225338110
Closes https://github.com/curl/curl/pull/14794
---
Revert "asyn-thread: avoid using GetAddrInfoExW with impersonation"
This reverts commit 0caadc1f24.
Conflicts:
lib/system_win32.c
--
Revert "asyn-thread: fix curl_global_cleanup crash in Windows"
This reverts commit 428579f5d1.
--
Revert "system_win32: fix a function pointer assignment warning"
This reverts commit 26f002e02e.
--
Revert "asyn-thread: use GetAddrInfoExW on >= Windows 8"
This reverts commit a6bbc87f9e.
Conflicts:
lib/asyn-thread.c
lib/system_win32.c
--
Based on the standards and guidelines we use for our documentation.
- expand contractions (they're => they are etc)
- host name = > hostname
- file name => filename
- user name = username
- man page => manpage
- run-time => runtime
- set-up => setup
- back-end => backend
- a HTTP => an HTTP
- Two spaces after a period => one space after period
Closes#14073
Add new job to test building for UWP (aka `CURL_WINDOWS_APP`).
Fix fallouts when building for UWP:
- rand: do not use `BCryptGenRandom()`.
- cmake: disable using win32 LDAP.
- cmake: disable telnet.
- version_win32: fix code before declaration.
- schannel: disable `HAS_MANUAL_VERIFY_API`.
- schannel: disable `SSLSUPP_PINNEDPUBKEY`
and make `schannel_checksum()` a stub.
Ref: e178fbd40a#1429
- schannel: make `cert_get_name_string()` a failing stub.
- system_win32: make `Curl_win32_impersonating()` a failing stub.
- system_win32: try to fix `Curl_win32_init()` (untested).
- threads: fix to use `CreateThread()`.
- src: disable searching `PATH` for the CA bundle.
- src: disable bold text support and capability detection.
- src: disable `getfiletime()`/`setfiletime()`.
- tests: make `win32_load_system_library()` a failing stub.
- tests/server/util: make it compile.
- tests/server/sockfilt: make it compile.
- tests/lib3026: fix to use `CreateThread()`.
See individual commits for build error details.
Some of these fixes may have better solutions, and some may not work
as expected. The goal of this patch is to make curl build for UWP.
Closes#13870
Currently, we use `pipe` for `wakeup_create`, which requires ***two***
file descriptors. Furthermore, given its complexity inside, `pipe` is a
bit heavyweight for just a simple event wait/notify mechanism.
`eventfd` would be a more suitable solution for this kind of scenario,
kernel also advocates for developers to use `eventfd` instead of `pipe`
in some simple use cases:
Applications can use an eventfd file descriptor instead of a pipe
(see pipe(2) in all cases where a pipe is used simply to signal
events. The kernel overhead of an eventfd file descriptor is much
lower than that of a pipe, and only one file descriptor is required
(versus the two required for a pipe).
This change adds the new backend of `eventfd` for `wakeup_create` and
uses it where available, eliminating the overhead of `pipe`. Also, it
optimizes the `wakeup_create` to eliminate the system calls that make
file descriptors non-blocking by moving the logic of setting
non-blocking flags on file descriptors to `socketpair.c` and using
`SOCK_NONBLOCK` for `socketpair(2)`, `EFD_NONBLOCK` for `eventfd(2)`.
Ref:
https://man7.org/linux/man-pages/man7/pipe.7.htmlhttps://man7.org/linux/man-pages/man2/eventfd.2.htmlhttps://man7.org/linux/man-pages/man2/socketpair.2.htmlhttps://www.gnu.org/software/gnulib/manual/html_node/eventfd.htmlCloses#13874
Multiple reports suggest that GetAddrInfoExW fails when impersonation is
used. This PR checks if thread is impersonating and avoids using
GetAddrInfoExW api.
Reported-by: Keerthi Timmaraju
Assisted-by: edmcln on github
Fixes#13612Closes#13738
- Make sure that asynchronous resolves handled by Winsock are stopped
before WSACleanup is called.
This is implemented by ensuring that when Curl_resolver_kill is called
(eg via multi_done) it will cancel the Winsock asynchronous resolve and
wait for the cancellation to complete. Winsock runs the asynchronous
completion routine immediately when a resolve is canceled.
Prior to this change it was possible that during curl_global_cleanup
"a DNS resolver thread created by GetAddrInfoExW did not terminate yet,
however curl is already shutting down, deinitializing Winsock with
WSACleanup() leading to an access violation."
Background:
If libcurl is built with the asynchronous threaded resolver option for
Windows then it resolves in one of two ways. For Windows 8.1 and later,
libcurl resolves by using the Winsock asynchronous resolver which does
its own thread management. For older versions of Windows, libcurl
resolves by creating a separate thread that calls getaddrinfo. This
change only affects the former and it's already handled for the latter.
Reported-by: Ch40zz@users.noreply.github.com
Fixes https://github.com/curl/curl/issues/13509
Closes https://github.com/curl/curl/pull/13518
- Compare to curl_thread_t_null instead of 0 for error.
Currently for both supported thread libraries (pthreads and Windows)
curl_thread_t_null is defined as 0. However, the pattern throughout the
code is to check against curl_thread_t_null and not 0 since for
posterity some thread library may not use 0 for error.
Closes https://github.com/curl/curl/pull/13542
Before this patch, two macros were used to guard IPv6 features in curl
sources: `ENABLE_IPV6` and `USE_IPV6`. This patch makes the source use
the latter for consistency with other similar switches.
`-DENABLE_IPV6` remains accepted for compatibility as a synonym for
`-DUSE_IPV6`, when passed to the compiler.
`ENABLE_IPV6` also remains the name of the CMake and `Makefile.vc`
options to control this feature.
Closes#13349
- resolving is done for a connection, not for every transfer
- save create/dup/free of a cares channel for each transfer
- check values of setopt calls against a local channel if no
connection has been attached yet, when needed.
Closes#12198
Previously it would always do PF_UNSPEC if CURL_IPRESOLVE_V4 is not
used, thus unnecessarily asking for addresses that will not be used.
Reported-by: Joseph Tharayil
Fixes#11564Closes#11565
Out of 415 labels throughout the code base, 86 of those labels were
not at the start of the line. Which means labels always at the start of
the line is the favoured style overall with 329 instances.
Out of the 86 labels not at the start of the line:
* 75 were indented with the same indentation level of the following line
* 8 were indented with exactly one space
* 2 were indented with one fewer indentation level then the following
line
* 1 was indented with the indentation level of the following line minus
three space (probably unintentional)
Co-Authored-By: Viktor Szakats
Closes#11134
- they are mostly pointless in all major jurisdictions
- many big corporations and projects already don't use them
- saves us from pointless churn
- git keeps history for us
- the year range is kept in COPYING
checksrc is updated to allow non-year using copyright statements
Closes#10205
Commit 3b16575ae9 removed support for
building on Novell Netware, but a few leftover traces remained. This
removes the last bits.
Closes: #9966
Reviewed-by: Daniel Stenberg <daniel@haxx.se>
This patch aims to cleanup the use of `process.h` header and the macro
`HAVE_PROCESS_H` associated with it.
- `process.h` is always available on Windows. In curl, it is required
only for `_beginthreadex()` in `lib/curl_threads.c`.
- `process.h` is also available in MS-DOS. In curl, its only use was in
`lib/smb.c` for `getpid()`. But `getpid()` is in fact declared by
`unistd.h`, which is always enabled via `lib/config-dos.h`. So the
header is not necessary.
- `HAVE_PROCESS_H` was detected by CMake, forced to 1 on Windows and
left to real detection for other platforms.
It was also set to always-on in `lib/config-win32.h` and
`lib/config-dos.h`.
In autotools builds, there was no detection and the macro was never
set.
Based on these observations, in this patch we:
- Rework Windows `getpid` logic in `lib/smb.c` to always use the
equivalent direct Win32 API function `GetCurrentProcessId()`, as we
already did for Windows UWP apps. This makes `process.h` unnecessary
here on Windows.
- Stop #including `process.h` into files where it was not necessary.
This is everywhere, except `lib/curl_threads.c`.
> Strangely enough, `lib/curl_threads.c` compiled fine with autotools
> because `process.h` is also indirecty included via `unistd.h`. This
> might have been broken in autotools MSVC builds, where the latter
> header is missing.
- Delete all remaining `HAVE_PROCESS_H` feature guards, for they were
unnecessary.
- Delete `HAVE_PROCESS_H` detection from CMake and predefined values
from `lib/config-*.h` headers.
Reviewed-by: Jay Satiro
Closes#9703
The check may take many milliseconds, so now it is performed once the
value is first needed. Also, this change makes sure that the value is
not used if the resolve is set to be IPv4-only.
Closes#9553
