You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.