Builder curl-ares-solaris11-sparc Build #4319

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 6 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 30 mins, 7 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 3 mins, 40 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Daniel Stenberg

   danielohnoyoudont@haxx.se
2. Stefan Eissing

   stefanohnoyoudont@eissing.org

Timing:

All Changes:

:

1. Change #242247

   Category	curl
   Changed by	Stefan Eissing <stefanohnoyoudont@eissing.org>
   Changed at	Wed 06 Aug 2025 14:12:46
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	6cebd35b4cda026d6f4ad682a51561be10b7e915

   Comments

   lib: xfer_setup simplify
   Make variants for transfers that send/receive or do both with just the
   parameters they need. Split out the shutdown setting into a separate
   function. Only FTP bothers with that.
   
   Closes #18203

   Changed files

   • lib/curl_rtmp.c
   • lib/dict.c
   • lib/ftp.c
   • lib/gopher.c
   • lib/http.c
   • lib/imap.c
   • lib/openldap.c
   • lib/pop3.c
   • lib/rtsp.c
   • lib/smtp.c
   • lib/transfer.c
   • lib/transfer.h
   • lib/vssh/libssh.c
   • lib/vssh/libssh2.c
   • lib/vssh/wolfssh.c

2. Change #242248

   Category	curl
   Changed by	Daniel Stenberg <danielohnoyoudont@haxx.se>
   Changed at	Wed 06 Aug 2025 14:13:36
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	019991c25ef0b0867381636f7f3d83b752e396be

   Comments

   multi: fix bad splay management
   The splay tree is a tree where each easy handle can be added *once*. The
   expire time for that node is the closest expire time for that easy
   handle.
   
   Easy handles can however have more expire times queued up, so when the
   node is removed from the splay tree because it is the next in line to
   take care of, we must check if there is another expire time in the queue
   and then add the node back into the splay.
   
   Failing to do the later part, the calling of add_next_timeout after
   Curl_splaygetbest, would leave the state.expiretime on the previous time
   stamp, which when could make the next call to Curl_splaygetbest use the
   wrong time stamp and get a wrong node out, causing trouble.
   
   Reported-by: letshack9707 on hackerone
   Closes #18201

   Changed files

   • lib/multi.c