fix(Session): prevent dangling pointers in DeleteAllSessions

Remove database_ref_.Reset() calls during DeleteAllSessions() iteration.

The issue: Reset() can trigger GC, which may finalize Session JS objects
that are still in our iteration list, creating dangling pointers → SIGSEGV.

Why this is safe:
- Our iteration only uses pure C/C++ ops (no Napi calls that trigger GC)
- When Sessions are later GC'd, Delete() returns early (session_ is nullptr)
- Napi::ObjectReference destructor handles reference cleanup automatically

Author: mceachen

src/sqlite_impl.cpp

@@ -1515,22 +1515,22 @@ void DatabaseSync::RemoveSession(Session *session) {
 
 void DatabaseSync::DeleteAllSessions() {
   // Copy and clear sessions while holding the lock, then release lock
-  // before calling Reset() which can trigger GC. GC can finalize other
-  // Session objects which call Delete() -> RemoveSession() which also
-  // tries to lock sessions_mutex_. Since std::mutex is not recursive,
-  // we must release the lock before any operation that could trigger GC.
+  // before doing cleanup. GC can finalize Session objects which call
+  // Delete() -> RemoveSession() which also tries to lock sessions_mutex_.
+  // Since std::mutex is not recursive, we must release the lock first.
   std::set<Session *> sessions_copy;
   {
     std::lock_guard<std::mutex> lock(sessions_mutex_);
     sessions_copy = sessions_;
     sessions_.clear(); // Clear first so RemoveSession() becomes a no-op
   }
 
-  // TWO-PASS cleanup to prevent double-free race condition:
-  // Pass 1: Delete all SQLite sessions and clear session_ pointers.
-  // This MUST happen before any Reset() calls because Reset() can trigger GC,
-  // which may finalize other Session objects whose destructors call Delete().
-  // By clearing all session_ pointers first, those Delete() calls become no-ops.
+  // Delete all SQLite sessions and clear session_ pointers.
+  // We do NOT call database_ref_.Reset() here because:
+  // 1. Reset() can trigger GC which may finalize Session JS objects
+  // 2. That would destroy objects we're still iterating over (dangling pointers!)
+  // 3. The Sessions will release their references when naturally GC'd later,
+  //    and their Delete() will be a no-op since session_ is nullptr.
   for (auto *session : sessions_copy) {
     if (session->GetSession()) {
       sqlite3session_delete(session->GetSession());
@@ -1540,14 +1540,6 @@ void DatabaseSync::DeleteAllSessions() {
       // Note: Don't null database_ - we need it to check IsOpen()
     }
   }
-
-  // Pass 2: Release database references. This can trigger GC which may finalize
-  // Session objects, but their Delete() calls are now no-ops (session_ == nullptr).
-  for (auto *session : sessions_copy) {
-    if (!session->database_ref_.IsEmpty()) {
-      session->database_ref_.Reset();
-    }
-  }
 }
 
 void DatabaseSync::AddBackup(BackupJob *backup) {