Description
I got a weird crash report from someone using Paint.NET. They say it's crashing whenever they use copy/paste functionality.
System.NullReferenceException: Object reference not set to an instance of an object.
at System.IO.Compression.Deflater.DeallocateInputBufferHandle()
at System.IO.Compression.Deflater.Finalize()
GZIP compression is used when Paint.NET prepares some types of data for the clipboard, so that lines up with the user's report of it happening when they copy something to the clipboard.
Now, there might be something weird with their system configuration, but it does also look like there's a legitimate null ref access in the DeallocateInputBufferHandle() for both Deflater and Inflater.
In both classes, the finalizer calls Dispose(false) which then unconditionally calls DeallocateInputBufferHandle(), which then sets two properties on _zlibStream. Obviously if zlibStream is null then we'll get a NullReferenceException.
For Deflater, if the constructor didn't successfully assign _zlibStream, presumably because of an exception coming out of the call to ZLibNative.CreateZLibStreamForDeflate(), then this would result in eventual finalization and the ~Deflater() -> Dispose(false) -> DeallocateInputBufferHandle() -> set property attempt on null _zlibStream chain of events.
Inflater appears to maybe have a similar problem but it's a bit more complicated and I haven't fully analyzed it.
These two classes were last modified by @stephentoub in #71991 but I'm not convinced that was the cause of this.
Reproduction Steps
I'm not sure -- user reports it happens when using copy/paste in Paint.NET.
The low-level repro is "find some way to force an exception in ZLibNative.CreateZLibStreamForDeflate() when constructing a GZipStream which constructs a Deflater"
Expected behavior
No crash
Actual behavior
We eventually get a NullReferenceException on the finalizer thread:
System.NullReferenceException: Object reference not set to an instance of an object.
at System.IO.Compression.Deflater.DeallocateInputBufferHandle()
at System.IO.Compression.Deflater.Finalize()
Regression?
Maybe. I've never received a crash log with this signature before .NET 7.0.x, so it's possible this was working fine in .NET 6.0.x.
Known Workarounds
No response
Configuration
The crash log from the customer's system has this config info:
Intel(R) Core(TM) i5-10310U CPU
Intel(R) UHD Graphics (no dGPU, in other words)
.NET 7.0.2
Windows 10 Enterprise 10.0.19044.0 x64
16GB RAM
Other information
No response
Description
I got a weird crash report from someone using Paint.NET. They say it's crashing whenever they use copy/paste functionality.
GZIP compression is used when Paint.NET prepares some types of data for the clipboard, so that lines up with the user's report of it happening when they copy something to the clipboard.
Now, there might be something weird with their system configuration, but it does also look like there's a legitimate null ref access in the
DeallocateInputBufferHandle()for bothDeflaterandInflater.In both classes, the finalizer calls
Dispose(false)which then unconditionally callsDeallocateInputBufferHandle(), which then sets two properties on_zlibStream. Obviously ifzlibStreamis null then we'll get aNullReferenceException.For
Deflater, if the constructor didn't successfully assign_zlibStream, presumably because of an exception coming out of the call toZLibNative.CreateZLibStreamForDeflate(), then this would result in eventual finalization and the~Deflater() -> Dispose(false) -> DeallocateInputBufferHandle() -> set property attempt on null _zlibStreamchain of events.Inflaterappears to maybe have a similar problem but it's a bit more complicated and I haven't fully analyzed it.These two classes were last modified by @stephentoub in #71991 but I'm not convinced that was the cause of this.
Reproduction Steps
I'm not sure -- user reports it happens when using copy/paste in Paint.NET.
The low-level repro is "find some way to force an exception in
ZLibNative.CreateZLibStreamForDeflate()when constructing aGZipStreamwhich constructs aDeflater"Expected behavior
No crash
Actual behavior
We eventually get a
NullReferenceExceptionon the finalizer thread:Regression?
Maybe. I've never received a crash log with this signature before .NET 7.0.x, so it's possible this was working fine in .NET 6.0.x.
Known Workarounds
No response
Configuration
The crash log from the customer's system has this config info:
Intel(R) Core(TM) i5-10310U CPU
Intel(R) UHD Graphics (no dGPU, in other words)
.NET 7.0.2
Windows 10 Enterprise 10.0.19044.0 x64
16GB RAM
Other information
No response