When calling .close() on a zlib.createGunzip() stream while the engine is still working on decompressing some stuff, sometimes this exception is thrown:
zlib.js:633
var newReq = self._handle.write(flushFlag,
^
TypeError: Cannot read property 'write' of null
at Zlib.callback (zlib.js:633:32)
Looking at the code, it seems that when _processChunk sets a callback, it does not sufficiently check that this._handle has not been unset in the meantime. The earlier code has assert(this._handle, 'zlib binding closed'); check, but the callback code does not.
But even the assert is wrong, as calling .close() on a stream, even when there's unprocessed data, should not throw any exceptions. I guess the function should check for this._closed similarily as it checks for this._hadError currently.
Unfortunately this bug is triggered very rarely on a production system, so I haven't been able to write short code to reproduce the issue.
When calling
.close()on azlib.createGunzip()stream while the engine is still working on decompressing some stuff, sometimes this exception is thrown:Looking at the code, it seems that when
_processChunksets a callback, it does not sufficiently check thatthis._handlehas not been unset in the meantime. The earlier code hasassert(this._handle, 'zlib binding closed');check, but the callback code does not.But even the assert is wrong, as calling
.close()on a stream, even when there's unprocessed data, should not throw any exceptions. I guess the function should check forthis._closedsimilarily as it checks forthis._hadErrorcurrently.Unfortunately this bug is triggered very rarely on a production system, so I haven't been able to write short code to reproduce the issue.