Skip to content
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

SharpZipLib 1.4.0 dependency may cause deadlocks #650

Closed
wterpstra opened this issue Nov 1, 2022 · 4 comments · Fixed by #671
Closed

SharpZipLib 1.4.0 dependency may cause deadlocks #650

wterpstra opened this issue Nov 1, 2022 · 4 comments · Fixed by #671
Assignees
Labels
bug Something isn't working dependencies Pull requests that update a dependency file question Have you tried our Slack workspace (https://testcontainers.slack.com)?
Milestone

Comments

@wterpstra
Copy link
Contributor

wterpstra commented Nov 1, 2022

Describe the bug
SharpZipLib has found a regression in its codebase (icsharpcode/SharpZipLib#786) between 1.3.3 and 1.4.0 which can cause deadlocks when writing tarballs

v2.2.0 references SharpZipLib 1.4.0 which may cause deadlocks.

To Reproduce
In my case I was running Testcontainers in a BeforeFeature binding in Specflow.

Expected behavior
No deadlocks. I don't see any preview versions where this fix is included. However, rolling back to 1.3.3 should also work.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • Testcontainers v2.2.0

Additional context
icsharpcode/SharpZipLib#788
icsharpcode/SharpZipLib#791

@wterpstra wterpstra changed the title SharpZibLib 1.4.0 dependency may cause deadlocks SharpZipLib 1.4.0 dependency may cause deadlocks Nov 1, 2022
@HofmeisterAn
Copy link
Collaborator

I assume you call something like Wait(), GetAwaiter().GetResult() or Result in BeforeFeature? That will block the async context and is not recommended anyway. You will probably get around this by wrapping your call in Task.Run(() => {}); (not recommended either), but might work. Best is to stick to the async context.

@HofmeisterAn HofmeisterAn added question Have you tried our Slack workspace (https://testcontainers.slack.com)? bug Something isn't working dependencies Pull requests that update a dependency file labels Nov 1, 2022
@wterpstra
Copy link
Contributor Author

No, SpecFlow is all async, the BeforeFeature bindings are async too. The .GetAwaiter().GetResult() is done inside the SharpZipLib library code.

See this diff: https://github.com/icsharpcode/SharpZipLib/pull/791/files#diff-99397a219e400099c43754f54b5b72a2fdd17d5e1bdbeef6ca31e160cef4b07bL384

They use an isAsync flag which was set incorrectly (this is the change where they fixed it). This change has not yet been released. With the isAsync flag set to true, like in 1.4.0, it will write out to the outputStream asynchronously. This is then awaited in the TarOutputStream: public TarEntry GetNextEntry() => GetNextEntryAsync(CancellationToken.None, true).GetAwaiter().GetResult(); and deadlocks.

@HofmeisterAn
Copy link
Collaborator

Yep, that looks not right. I think you can override the version with 1.3.3 in your project file (in the dependency graph) in the meantime.

@wterpstra
Copy link
Contributor Author

When I reference SharpZipLib 1.3.3 I get a package version downgrade detected error from dotnet restore because the Testcontainers v2.2.0 NuGet package has a SharpZipLib >= 1.4.0 dependency. I downgraded Testcontainers to v2.1.0 which also works for now! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dependencies Pull requests that update a dependency file question Have you tried our Slack workspace (https://testcontainers.slack.com)?
Projects
None yet
2 participants