Builder curl-threaded-solaris11-i386 Build #5351

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

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

Build Properties:

Forced Build Properties:

Responsible Users:

1. Daniel Stenberg

   danielohnoyoudont@haxx.se
2. xhon-pelushi

   xhonohnoyoudont@pelushi.com

Timing:

All Changes:

:

1. Change #281322

   Category	curl
   Changed by	Daniel Stenberg <danielohnoyoudont@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

2. Change #281323

   Category	curl
   Changed by	xhon-pelushi <xhonohnoyoudont@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 #22890

   Changed files

   • src/tool_easysrc.c
   • tests/data/Makefile.am
   • tests/data/data1679.c
   • tests/data/data1687.c
   • tests/data/test1687