W.r.t. the asyn-thread failures (e.g. 241), this failure is reported as a close-without-open of a FD, but it might be a false positive. The failure occurs in a HAVE_PIPE build which means that instead of a socketpair, a pipe is opened at asyn-thread.c:254; however, it's closed in this error path using sclose at asyn-thread.c:584. sclose is replaced by the memdebug subsystem and seen by it but pipe is not, so it appears to the leak checker like a close without an open.

Building with HAVE_PIPE means it creates a socketpair instead of a pipe, except that socketpair is also not tracked by the memory tracker so once again it sees a close without an open.

I don't know how this ever passed the leak checker. Every test using the resolver ought to error out here.

On a related not, I don't think the sclose() at asyn-thread.c:584 is right; I think it should be wakeup_close. Although, that won't fix the torture test because it seems to be a limitation fo the leak checker.

I don't know how this ever passed the leak checker

Because we used to disable the memory tracking with the threaded resolver due to problems with the logging from multiple threads. I'm not entirely sure those problems are gone now.

When I re-run this torture test failure on test 20 with valgrind enabled, valgrind says nothing. This might hint that the problem is rather with the logging itself.

Combine this with CURLOPT_QUICK_EXIT set. It allows leaks on exit, which is probably the biggest explanation here. We need to avoid setting this option when doing torture tests.

Torture tests are all succeeding for me! Thanks.