Builder curl-threaded-solaris11-i386 Build #3776

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-curl-threaded-solaris11-i386' triggered this build

Steps and Logfiles:

1. git update ( 1 hrs, 5 mins, 9 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 1 hrs, 15 mins, 1 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 22 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Daniel Stenberg

   danielohnoyoudont@haxx.se
2. Eshan Kelkar

   eshankelkarohnoyoudont@galorithm.com
3. Stefan Eissing

   stefanohnoyoudont@eissing.org

Timing:

All Changes:

:

1. Change #241075

   Category	curl
   Changed by	Eshan Kelkar <eshankelkarohnoyoudont@galorithm.com>
   Changed at	Mon 28 Jul 2025 22:35:39
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	f7af8adadd51997f11eadf06c843c04feb436c3f

   Comments

   libssh: Use sftp_aio instead of sftp_async for sftp_recv
   This commit replaces the usage of the old deprecated sftp_async API with
   the new sftp_aio API for remote file reading.
   
   Signed-off-by: Eshan Kelkar <eshankelkar@galorithm.com>
   
   Closes #17440

   Changed files

   • lib/vssh/libssh.c
   • lib/vssh/ssh.h

2. Change #241076

   Category	curl
   Changed by	Daniel Stenberg <danielohnoyoudont@haxx.se>
   Changed at	Mon 28 Jul 2025 22:37:59
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	9d2075bdce1234360bd41a9146ab9b465750a840

   Comments

   ws: avoid NULL pointer deref in curl_ws_recv
   If a NULL easy handle is passed in.
   
   Pointed out by Coverity
   
   Follow-up to 960fb4924523a853d5de8f30
   
   Closes #18065

   Changed files

   • lib/ws.c

3. Change #241080

   Category	curl
   Changed by	Stefan Eissing <stefanohnoyoudont@eissing.org>
   Changed at	Mon 28 Jul 2025 22:57:42
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	85e18a5b9a60109d139e702c9c1028fa6ff4366e

   Comments

   multi: process pending, one by one
   Before curl 8.14.0, when pending was a list, `process_pending_handles()`
   move a single transfer to processing. In 8.14.0 we changed that to move
   all pending transfers to processing. This lead to unwanted performance
   drops as reported in #18017.
   
   Restore the old behaviour.
   
   While the old behviour is better, the overall handling of "pending"
   transfers is not optimal, since we do not keep track of the "condition"
   a pending transfer is waiting on. This means, when moving a single,
   pending transfer, we might move one that still cannot be processed while
   another that could is kept pending.
   
   Since we trigger `process_pending_handles()` from various changes, the
   stalled pending will eventually make it to the processing queue, but
   this is not optimal.
   
   Fixes #18017
   Reported-by: rm-rmonaghan on github
   Closes #18056

   Changed files

   • lib/multi.c