tor-browser

commit bdb7d7086eb7dbabbb632410a92e1273fde1407a
parent dd648ea6d0ebe30b137e0ebcc69c24048cbb42ac
Author: David P. <daparks@mozilla.com>
Date:   Wed, 29 Oct 2025 23:42:12 +0000

Bug 1990634: Part 4 - 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() {