tor-browser

commit 685b1d62bc22ada1cc7cc06a514217f387038b79
parent e4cdb388d44d6438687cea366201f16510659ff2
Author: David P. <daparks@mozilla.com>
Date:   Thu, 23 Oct 2025 22:07:12 +0000

Bug 1990634: Release circular reference when done searching zip archives r=kershaw

nsZipFind is a single-use iterator and was (strongly) holding it's
collection past the iteration, when it isn't useful.  What's worse, it
creates a circular reference that persists until shutdown.  This
(namely the memory mapped handle it causes us to keep) is what blocked the
zip file delete in Windows 10 automated tests.

Differential Revision: https://phabricator.services.mozilla.com/D267711

Diffstat:
M
modules/libjar/nsZipArchive.cpp
 | 
7
++++++-

1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/modules/libjar/nsZipArchive.cpp b/modules/libjar/nsZipArchive.cpp
@@ -582,7 +582,8 @@ nsresult nsZipArchive::FindInit(const char* aPattern, nsZipFind** aFind) {
 // nsZipFind::FindNext
 //---------------------------------------------
 nsresult nsZipFind::FindNext(const char** aResult, uint16_t* aNameLen) {
-  if (!mArchive || !aResult || !aNameLen) return NS_ERROR_ILLEGAL_VALUE;
+  if (!aResult || !aNameLen) return NS_ERROR_ILLEGAL_VALUE;
+  NS_ENSURE_TRUE(mArchive, NS_ERROR_FILE_NOT_FOUND);
 
   MutexAutoLock lock(mArchive->mLock);
   *aResult = 0;
@@ -616,6 +617,9 @@ nsresult nsZipFind::FindNext(const char** aResult, uint16_t* aNameLen) {
   }
   MMAP_FAULT_HANDLER_CATCH(NS_ERROR_FAILURE)
   LOG(("ZipHandle::FindNext[%p] not found %s", this, mPattern));
+  // Release the archive.
+  mArchive = nullptr;
+  mItem = nullptr;
   return NS_ERROR_FILE_NOT_FOUND;
 }
 
@@ -967,6 +971,7 @@ nsZipFind::nsZipFind(nsZipArchive* aZip, char* aPattern, bool aRegExp)
       mSlot(0),
       mRegExp(aRegExp) {
   MOZ_COUNT_CTOR(nsZipFind);
+  MOZ_ASSERT(mArchive);
 }
 
 nsZipFind::~nsZipFind() {