Builder curl-ares-solaris11-sparc Build #4374

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 ...' ( 28 mins, 57 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 0 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Viktor Szakats

   commitohnoyoudont@vsz.me

Timing:

All Changes:

:

1. Change #243229

   Category	curl
   Changed by	Viktor Szakats <commitohnoyoudont@vsz.me>
   Changed at	Mon 18 Aug 2025 23:46:56
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	2388b0e5878da030fac0e9d1ad490bc5447e37e0

   Comments

   processhelp.pm: use `Win32::Process*` perl modules if available
   `Win32::Process::List` and `Win32::Process`.
   
   To replace external calls to `tasklist.exe` and `taskkill.exe`.
   
   The perl modules are wrappers/binding to Win32 API calls. They avoid
   launching external processes with a command shell (including MSYS2),
   the external tool, and creating command-lines and parsing tool output.
   
   According to local tests and the CI, one test session calls
   `tasklist.exe` 350-400 times. `taskkill.exe` is rarely called:
   https://github.com/curl/curl/actions/runs/17012376726?pr=18296
   
   It's hard to predict any possible side-effect of dynamically loading
   the two necessary, module DLLs into the Perl process. The MSYS2 runtime
   if prone to fail when doing this in fork operations, as seen earlier
   with the Win32.DLL module. But, is looks like a symptom, not the root
   cause for these failures, because the failures are present with or
   without perl.exe loading the Win32.DLL.
   Ref: be01b60ce532af6eb18c11fbd565355dbb570a2e #18287
   
   Cherry-picked from #18296
   Closes #18308

   Changed files

   • tests/processhelp.pm