New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gleak tests failing on Windows 10 with go1.19 #576
Comments
Hi @davidhsingyuchen, thank you for reporting this issue! I've been able to reproduce it and most can be automatically handled with an updated ignore list. @onsi I need to pick your brain on
If it is, can you give me a hint how I might be able to deal with it? I don't think that adding |
The solution I've now come up with is to call a new |
hey @thediveo - my bad here, I had assumed that Gomega's CI was running the tests in parallel and would have caught this issue sooner. When I ran locally I didn't think to try running in parallel which, in retrospect, was an obvious gap on my part. I'm able to reproduce this on my MacOS box by simply running When running in parallel ginkgo spawns multiple processes that then communicate back to the CLI using an RPC client. On Unix/Darwin (but not on windows as it is not supported), Ginkgo also runs goroutines on each parallel process that intercept the stdout/stderr of that process in order to associate it with the spec and pass it back to the server. On windows you see the
this is the stdout/stderr intercepting stuff I was talking about earlier. I can fix this leak by adding: IgnoringCreator("github.com/onsi/ginkgo/v2/internal.(*genericOutputInterceptor)..."), to the The Can you think of anything I could do on the Ginkgo side? I don't think so, since the goroutine is created in the go library code by calling a private function and the goroutine stack ends at the creator and not the creator's caller (where all the |
After finally locating the internal parallel stuff in Ginkgo and looking at it I don't see a good way to integrate here, so I would propose to stay with an upgraded ignore list and the BeforeSuite way. I've all the things ready for a PR, just adding a small paragraph to the doc that when not liking the BeforeSuite way, then using the snapshot solution instead. |
Thanks @thediveo - sorry for not catching this sooner, but I agree that that sounds like the best solution. |
I didn't noticed either, as I have to admit that I routinely use I would rather keep the specialized Somehow slightly ironic that we follows Go's principle of not hiding to many things but instead making clear what happens. |
Summary
This issue is created out of this issue comment.
System information:
go1.19 windows/amd64
10.0.19043 N/A Build 19043
(obtained bysysteminfo
)Test Output
The text was updated successfully, but these errors were encountered: