Builder curl-ares-solaris11-sparc Build #6460

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-curl-ares-solaris11-sparc' triggered this build

Steps and Logfiles:

1. git update ( 8 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 2 mins, 36 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 0 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Daniel Stenberg

   danielohnoyoudont@haxx.se
2. Joshua Rogers

   MegaManSecohnoyoudont@users.noreply.github.com
3. Paolo Ganci

   paolo.ganciohnoyoudont@nevis-security.com
4. xhon-pelushi

   xhonohnoyoudont@pelushi.com

Timing:

All Changes:

:

1. Change #282078

   Category	curl
   Changed by	Paolo Ganci <paolo.ganciohnoyoudont@nevis-security.com>
   Changed at	Thu 17 Sep 2026 22:04:01
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	11df32bc8e2d92c50c209a454e6e93b52588b365

   Comments

   http2: don't send a CURLE_SEND_ERROR after a valid http2 response
   Fixes #22984
   Suggested-by: https://github.com/szedenik-adam
   
   In this sequence:
    1. The client sends part of the request body.
    2. The server sends a complete early response and ends its response direction.
    3. The client resumes and finishes the request upload.
    4. Curl calls `cf_send(len=0, eos=1)` to finalize the request.
    5. libcurl sees `stream->closed` and unconditionally returns `CURLE_SEND_ERROR`, even though `stream->resp_hds_complete` is true and the response was valid.
   
   change that at point 5 no CURLE_SEND_ERROR is sent if the repsonse is valid
   
   Closes #22987

   Changed files

   • lib/http2.c

2. Change #282079

   Category	curl
   Changed by	Daniel Stenberg <danielohnoyoudont@haxx.se>
   Changed at	Thu 17 Sep 2026 22:18:29
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	e7f76c782b06ab6af9eb1f256a8d681d7fa13b7c

   Comments

   parsedate: find day names, months and time zones faster
   Implements faster lookups for which specific week name, month name and
   time zone that is provided; without loops.
   
   With this applied, the dateparser perf test completes almost twice as
   fast for me.
   
   Add unit test 4781 to verify each parser.
   
   Closes #22981

   Changed files

   • lib/parsedate.c
   • tests/data/Makefile.am
   • tests/data/test4781
   • tests/libtest/lib517.c
   • tests/unit/Makefile.inc
   • tests/unit/unit4781.c

3. Change #282080

   Category	curl
   Changed by	xhon-pelushi <xhonohnoyoudont@pelushi.com>
   Changed at	Thu 17 Sep 2026 22:22:56
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	ccecc619a5f2dbfddca92d9e61ff32d0e1a39366

   Comments

   KNOWN_BUGS: drop the empty error buffer entry, it no longer happens
   Issue 544 asked for a failf() in the connect path and was closed in
   April 2016. The call is there, but the entry stayed.
   
   Checked against current master by reading CURLOPT_ERRORBUFFER from a
   program rather than going by what the curl tool prints, and driving the
   failures with CURLOPT_RESOLVE. The buffer is set every time, with one,
   two, three and four addresses, for IPv4 and IPv6 alike.
   
   The entry describes addresses that cannot be reached at all rather than
   ones that time out, so the same set was run again inside a network
   namespace holding only loopback and no routes, where connect() fails
   immediately. That returns CURLE_COULDNT_CONNECT, which is the case the
   entry names, and the buffer still holds "Failed to connect to <host>
   after 0 ms: Could not connect to server".
   
   Fixes #544
   Closes #22952

   Changed files

   • docs/KNOWN_BUGS.md

4. Change #282081

   Category	curl
   Changed by	Joshua Rogers <MegaManSecohnoyoudont@users.noreply.github.com>
   Changed at	Thu 17 Sep 2026 22:23:58
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	cba4a7580e33d83884057bb67a0ea7bb6ba7d275

   Comments

   tool_help: guard category[2] access when category is bare "-"
   When category is "-" (length 1), category[1] is already the null
   terminator. The else-if on line 272 then reads category[2] without first
   confirming category[1] is non-null, producing a one-byte
   heap-buffer-overflow that ASan flags. Add the category[1] guard so the
   short-option path is only taken for exactly two-character inputs like
   "-x".
   
   Closes #22957

   Changed files

   • src/tool_help.c