1634499 - ASSERTION: morkBool_kFalse: 'Error', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/db/mork/src/morkConfig.cpp, line 20

Status: NEW

(MailNews Core :: Database, defect)

Description

[ISHIKAWA, Chiaki]

Attachment: Log of 104:35.81 TEST_START: comm/mail/test/browser/folder-display/browser_virtualFolderCommands.js

While running mochitest of FULL DEBUG version of TB, I got the following error.

ASSERTION: morkBool_kFalse: 'Error', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/db/mork/src/morkConfig.cpp, line 20

The assertion is trigged in a test of browser_virtualFolderCommands.js:
The following is an excerpt from the output of the command.:

 ...
104:35.81 TEST_START: comm/mail/test/browser/folder-display/browser_virtualFolderCommands.js
104:35.82 INFO Entering test bound setupModule
104:36.24 INFO Entering test bound test_single_folder_select_thread
104:41.15 INFO Entering test bound test_cross_folder_select_thread
104:41.65 GECKO(771813) [771813, Main Thread] ###!!! ASSERTION: morkBool_kFalse: 'Error', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/db/mork/src/morkConfig.cpp, line 20
104:49.77 TEST_END: Test OK. Subtests passed 4/5. Unexpected 0
...

I am attaching an excerpt from the logfile of the above test.
It is with a FULL DEBUG version of TB with additional local patches and so the log is more verbose than the one on the tryserver.

There was bug 436622 from 12 years ago,
"ASSERTION: morkBool_kFalse: '0'" when going back to an IMAP folder after deleting a message from the trash

This may be related.

Comment 1

[ISHIKAWA, Chiaki]

Please note that I use -gsplit-dwarf to make gdb startup short.

However, the recent fix-stacks script/binary does not like the split debug information.
The stack trace in the attachment is busted, I am afraid. Sorry about the inconvenience.

It may take a week for me to fix this breakage. Hmm. :-(

Comment 2

[ISHIKAWA, Chiaki]

Attachment: (with corrected stack trace) Log of comm/mail/test/browser/folder-display/browser_virtualFolderCommands.js

I am uploading a log of comm/mail/test/browser/folder-display/browser_virtualFolderCommands.js test with corrected stack trace. The top several lines are more like it.

109:36.07 GECKO(1194826) [1194826, Main Thread] ###!!! ASSERTION: morkBool_kFalse: 'Error', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/db/mork/src/morkConfig.cpp, line 20
109:36.07 GECKO(1194826) #01: morkRowSpace::NewTable(morkEnv*, unsigned int, unsigned char, mdbOid const*) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/db/mork/src/morkRowSpace.cpp:282)
109:36.07 GECKO(1194826) #02: morkStore::NewTable(nsIMdbEnv*, unsigned int, unsigned int, unsigned char, mdbOid const*, nsIMdbTable**) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/db/mork/src/morkStore.cpp:1716)
109:36.07 GECKO(1194826) #03: nsMsgDatabase::GetSearchResultsTable(char const*, bool, nsIMdbTable**) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/db/msgdb/src/nsMsgDatabase.cpp:5166)
109:36.07 GECKO(1194826) #04: nsMsgDatabase::HdrIsInCache(char const*, nsIMsgDBHdr*, bool*) (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nsCOMPtr.h:1309)

Comment 3

[ISHIKAWA, Chiaki]

It is still there, at least in my local log of March 2024.

Comment 4

[ISHIKAWA, Chiaki]

Attachment: 2024/05/30 log

I am attaching a log.
I hate to think the test system annouces the test succeeded when there are asserts during tests.

Anyway, i today's C-C TB, I see that the error occurs in
test_cross_folder_select_thread as before, and
with a lower-level debug dump code which I inserted, I see that there are
virt2.msf
gabba0.msf
virt3.msf
MSF handled by mork
and the error is recorded
when GetSearchResultsTable() calls morkStore::NewTable.
This calls morkRowSpace::NewTable and blows up in my local copy fo morkSpace.cpp
at line 281:

  268	
  269	morkTable* morkRowSpace::NewTable(
  270	    morkEnv* ev, mork_kind inTableKind, mdb_bool inMustBeUnique,
  271	    const mdbOid* inOptionalMetaRowOid)  // can be nil to avoid specifying
  272	{
  273	  morkTable* outTable = 0;
  274	  morkStore* store = mSpace_Store;
  275	
  276	  if (inTableKind && store) {
  277	    if (inMustBeUnique)  // need to look for existing table first?
  278	      outTable = this->FindTableByKind(ev, inTableKind);
  279	
  280	    if (!outTable && ev->Good()) {
* 281	      mork_tid id = this->MakeNewTableId(ev);   <==== HERE
  282	      if (id) {
  283	        nsIMdbHeap* heap = mSpace_Store->mPort_Heap;
  284	        morkTable* table = new (*heap, ev)
  285	            morkTable(ev, morkUsage::kHeap, heap, mSpace_Store, heap, this,
  286	                      inOptionalMetaRowOid, id, inTableKind, inMustBeUnique);
  287	        if (table) {
  288	          if (mRowSpace_Tables.AddTable(ev, table))
  289	            outTable = table;
  290	          else
  291	            table->Release();
  292	
  293	          if (this->IsRowSpaceClean() && store->mStore_CanDirty)
  294	            this->MaybeDirtyStoreAndSpace();  // morkTable does already
  295	        }
  296	      }
  297	    }
  298	  } else if (store)
  299	    this->ZeroKindError(ev);
  300	  else
  301	    this->NilSpaceStoreError(ev);
  302	
  303	  return outTable;
  304	}

B U T,
actually the assertion seems to come from the following code in morkRowSpace.cpp, so I presume maybe the function MakeNewTableID is inlined?

mork_tid morkRowSpace::MakeNewTableId(morkEnv* ev) {
  mork_tid outTid = 0;
  mork_tid id = mRowSpace_NextTableId;
  mork_num count = 9;  // try up to eight times

  while (!outTid && --count)  // still trying to find an unused table ID?
  {
    if (!mRowSpace_Tables.GetTable(ev, id))
      outTid = id;
    else {
      MORK_ASSERT(morkBool_kFalse);  // alert developer about ID problems   <=== HERE
      ++id;
    }
  }

  mRowSpace_NextTableId = id + 1;
  return outTid;
}

This seems to suggest we run out for an ID for the newly created table.
But I have no idea how many IDs are allowed, etc. (We seem to have used up 10 tables.
Maybe we have forgotten to release the unused table?)