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

[release/7.0-staging] Revert Deflater/Inflater changes around SafeHandle initialization #88153

Merged

Commits on Jun 28, 2023

  1. Revert Deflater/Inflater changes around SafeHandle initialization

    Deflater/Inflater's ctor calls a P/Invoke that initializes a SafeHandle.  Previously this was being done to directly initialize a field, but I'd changed that months ago due to it leaving a handle for finalization.  What I failed to notice, however, was that these types themselves defined finalizers, and those finalizers expected that SafeHandle field to have been initialized; now that it's not, if a rare zlib initialization error occurs (e.g. zlib couldn't be found/loaded), the finalizer may crash the process due to an unhandled null reference exception.
    
    For Deflater, it'd be possible to just call GC.SuppressFinalize(this) inside the existing catch block that's disposing of the SafeHandle in the event of an exception.  But it's more complicated for Inflater, where the SafeHandle might be recreated during the Inflater's lifetime, and thus the existing catch block is inside of a helper method that's used from more than just the ctor, and we shouldn't be suppressing finalization in that case.
    
    So, rather than do something complicated for the small gains this provided (it was part of a much larger sweep to clean up non-disposed SafeHandles), I've just reverted these cases.
    stephentoub authored and github-actions committed Jun 28, 2023
    Configuration menu
    Copy the full SHA
    d2bcfcf View commit details
    Browse the repository at this point in the history