Builder curl-ares-solaris10-sparc Build #2788

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 3 mins, 29 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 2 hrs, 38 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. Stefan Eissing

   stefanohnoyoudont@eissing.org

Timing:

All Changes:

:

1. Change #230282

   Category	curl
   Changed by	Daniel Stenberg <danielohnoyoudont@haxx.se>
   Changed at	Tue 20 May 2025 10:44:53
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	3ec6aa5c07407d96ca2b3fc8a95d16cb16826ef6

   Comments

   formdata: fix memory leak in OOM situation
   Fixes #17390
   Follow-up to c26da713e7dfa8c26a71bf3c0c75
   Reported-by: Viktor Szakats
   Closes #17393

   Changed files

   • lib/formdata.c

2. Change #230301

   Category	curl
   Changed by	Stefan Eissing <stefanohnoyoudont@eissing.org>
   Changed at	Tue 20 May 2025 14:49:17
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	be45e014c6ae82ae7752ca874ecefdc5bbc000fa

   Comments

   dns_entry: move from conn to data->state
   The `struct Curl_dns_entry *` used to established a connection
   do not have the connection's lifetime, but the transfer's lifetime
   (of the transfer that initiates the connect).
   
   `Curl_dns_entry *` is reference counted with the "dns cache". That
   cache might be owned by the multi or the transfer's share. In the
   share, the reference count needs updating under lock.
   
   Therefore, the dns entry can only be kept *and* released using the
   same transfer it was initially looked up from. But a connection is
   often discarded using another transfer.
   
   So far, the problem of this has been avoided in clearing the connection's
   dns entries in the "multi_don()" handling. So, connections had NULL
   dns entries after the initial transfers and its connect had been handled.
   
   Keeping the dns entries in data->state seems therefore a better choice.
   
   Also: remove the `struct Curl_dns_entry *` from the connect filters
   contexts. Use `data->state.dns` every time instead and fail correctly
   when not present and needed.
   
   Closes #17383

   Changed files

   • lib/cf-https-connect.c
   • lib/cf-https-connect.h
   • lib/connect.c
   • lib/connect.h
   • lib/cshutdn.c
   • lib/easy.c
   • lib/ftp.c
   • lib/hostip.c
   • lib/hostip.h
   • lib/multi.c
   • lib/setopt.c
   • lib/url.c
   • lib/url.h
   • lib/urldata.h