summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2014-05-21 18:22:27 +0200
committerStephan Bergmann <sbergman@redhat.com>2014-05-21 18:29:57 +0200
commit8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 (patch)
tree7c1000a821d3d895a8c3c0abb8620f2e882d5205 /include
parentc5a603ce2469ef6a23023ff276ccd24ca316f6c2 (diff)
So ZCodec::ReadAsynchron was wrong in using a persistent mpIStm after all
The fun thing is that with the (only) call-site to ReadAsynchron in PNGReaderImpl::ImplReadIDAT (vcl/source/gdi/pngread.cxx) passing in rIStm references to stack-allocated SvMemoryStream instances, mpIStm could point to an old, destroyed instance from a previous call, but which would have been located at exactly the same stack address as the currently passed in rIStm, so the wrong mpIStm->Read call would effectively behaved exactly the same as a correct rIStm.Read call. This went unnoticed "since the beginning" until AddressSanitizer's UseAfterReturn check came along... Change-Id: I7c75ed2d36a4c24c111d88eff647816bd2c5dbca
Diffstat (limited to 'include')
-rw-r--r--include/tools/zcodec.hxx1
1 files changed, 0 insertions, 1 deletions
diff --git a/include/tools/zcodec.hxx b/include/tools/zcodec.hxx
index c7424ab592cb..63a5ec2002e2 100644
--- a/include/tools/zcodec.hxx
+++ b/include/tools/zcodec.hxx
@@ -39,7 +39,6 @@ class TOOLS_DLLPUBLIC ZCodec
State meState;
bool mbStatus;
bool mbFinish;
- SvStream* mpIStm;
sal_uInt8* mpInBuf;
sal_uIntPtr mnInBufSize;
sal_uIntPtr mnInToRead;