Builder curl-ares-solaris10-i386 Build #4504
Results:
Failed
SourceStamp:
| Project | curl |
| Repository | https://github.com/curl/curl.git |
| Branch | master |
| Revision | 2dee5ea29416c498b6b9d21c897e9571ff3b3ec5 |
| Changes | 3 changes |
BuildSlave:
unstable10xReason:
The SingleBranchScheduler scheduler named 'schedule-curl-ares-solaris10-i386' triggered this build
Steps and Logfiles:
Build Properties:
| Name | Value | Source |
|---|---|---|
| branch | master | Build |
| builddir | /export/home/buildbot/slave/curl-ares-solaris10-i386 | slave |
| buildername | curl-ares-solaris10-i386 | Builder |
| buildnumber | 4504 | Build |
| codebase | Build | |
| project | curl | Build |
| repository | https://github.com/curl/curl.git | Build |
| revision | 2dee5ea29416c498b6b9d21c897e9571ff3b3ec5 | Build |
| scheduler | schedule-curl-ares-solaris10-i386 | Scheduler |
| slavename | unstable10x | BuildSlave |
| workdir | /export/home/buildbot/slave/curl-ares-solaris10-i386 | slave (deprecated) |
Forced Build Properties:
| Name | Label | Value |
|---|
Responsible Users:
- Daniel Stenbergdaniel@haxx.se
- Stefan Eissingstefan@eissing.org
- xhon-pelushixhon@pelushi.com
Timing:
| Start | Thu Sep 10 12:19:29 2026 |
| End | Thu Sep 10 17:34:31 2026 |
| Elapsed | 5 hrs, 15 mins, 2 secs |
All Changes:
:
Change #281322
Category curl Changed by Daniel Stenberg <daniel@haxx.se> Changed at Thu 10 Sep 2026 09:36:14 Repository https://github.com/curl/curl.git Project curl Branch master Revision 7d7fa4d7dd182b1bbb72ca20232fc15d00f6b335 Comments
easy: duplicating a zero byte memory area needs no malloc Added test 1791 to reproduce and verify fix. Reported-by: Max Dymond Closes #22893
Changed files
- lib/easy.c
- tests/data/Makefile.am
- tests/data/test1791
- tests/libtest/Makefile.inc
- tests/libtest/lib1791.c
Change #281323
Category curl Changed by xhon-pelushi <xhon@pelushi.com> Changed at Thu 10 Sep 2026 09:41:19 Repository https://github.com/curl/curl.git Project curl Branch master Revision 110936726e518ff843e0a2063db8143be07dd286 Comments
tool_easysrc: reset the handle between --next operations The curl tool creates a fresh easy handle for every operation, but the --libcurl output reuses a single handle for all of them and never resets it, so options set for one operation silently apply to the following ones and the generated program does not do what the command line did. 19d0f4acfa9d fixed this for SSL verification by re-emitting those two options after --next. Everything else still leaks. For curl -H "X-First: yes" --compressed http://host/one \ --next http://host/two the generated program sends X-First and Accept-Encoding on the second transfer as well, while the command line sends them only on the first. Confirmed by compiling the generated program and comparing what both actually put on the wire against a local server: operation 1 operation 2 curl X-First, Accept-Encoding neither generated program X-First, Accept-Encoding X-First, Accept-Encoding Emit curl_easy_reset() between operations instead, which covers the general case: every option the next operation needs is already re-emitted after the reset, because the tool writes out its options per operation. The call is deferred rather than written straight after curl_easy_perform() so that it only appears when another operation actually follows: a single-operation command generates no reset at all, and none is emitted before the trailing curl_easy_cleanup(). Existing --libcurl coverage (tests 1400-1407, 1420, 1465, 1481) is all single-operation, and 1679 checks only the SSL options, so add test 1687 for the general case. It fails without this change. Test 1679's expected output gains the same curl_easy_reset() line, since it is a --next test too. Ref: #22701 Closes #22890Changed files
- src/tool_easysrc.c
- tests/data/Makefile.am
- tests/data/data1679.c
- tests/data/data1687.c
- tests/data/test1687
Change #281337
Category curl Changed by Stefan Eissing <stefan@eissing.org> Changed at Thu 10 Sep 2026 11:45:05 Repository https://github.com/curl/curl.git Project curl Branch master Revision 2dee5ea29416c498b6b9d21c897e9571ff3b3ec5 Comments
mulit_ev: remove socket references on forget When multi_ev is informed that a socket is about to be closed, it cleans up its entry for it (if it exists), but it did not remove it from any remembered "last pollset"s. When the OS reuses the file descriptor, this may lead to socket identity confusion on detecting changes of use. Remove the socket from any pollset that is registered at the socket entry of multi_ev when a socket is being "forgotten". Found-by: Max Dymond Closes #22895
Changed files
- lib/multi_ev.c
- lib/select.c
- lib/select.h