Big Question: To what value should |statsOffset| be initialized when m_startOfMsg ? Analysis: I have run the test with the attached patch to dump some variables and to make sure the compaction to run ALWAYS (as opposed to the random behavior (approximately once in 100 tries). I think I found the culprit by checking the log. When m_startOfMsg = 0, statusOffset is not initialized and used at https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#758 The uninitialized value can be anything. When m_startOfMsg != 0, statusOffset is initialized by the call to (void)m_curSrcHdr->GetStatusOffset(&statusOffset); https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#733 The code is sprinkled with code snippet to check for bogus statusOffset value. At least in one control flow path It is not initialized before use and thus very likely that the the check would kick in and then keyword processing is not done most of the cases(!). For example, the usage mentioned above is part of a sanity check. https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#758 If the value seems insane, checkForKeyword = false; and no keyword related processing takes place. There is another one at https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#739 too. Thus, I think the failure to initialize |statusOffset| is the cause of previously observed loss of keyword or tag information after compaction(?). Possibly related bugs? https://bugzilla.mozilla.org/buglist.cgi?quicksearch=key%20compact&list_id=15087348 Big Question: To what value should |statsOffset| be initialized when m_startOfMsg ? I am attaching an excerpt from the log in another post.
Bug 1611708 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Big Question: To what value should |statsOffset| be initialized when m_startOfMsg ? Analysis: I have run the test with the attached patch to dump some variables and to make sure the compaction to run ALWAYS (as opposed to the random behavior (approximately once in 100 tries). I think I found the culprit by checking the log. When m_startOfMsg = 0, statusOffset is not initialized and used at https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#758 The uninitialized value can be anything. When m_startOfMsg != 0, statusOffset is initialized by the call to (void)m_curSrcHdr->GetStatusOffset(&statusOffset); https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#733 The code is sprinkled with code snippet to check for bogus statusOffset value. At least in one control flow path It is not initialized before use and thus very likely that the the check would kick in and then keyword processing is not done most of the cases(!). For example, the usage mentioned above is part of a sanity check. https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#758 If the value seems insane, checkForKeyword = false; and no keyword related processing takes place. There is another one at https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#739 too. Thus, I think the failure to initialize |statusOffset| is the cause of previously observed loss of keyword or tag information after compaction(?). Possibly related bugs? https://bugzilla.mozilla.org/buglist.cgi?quicksearch=key%20compact&list_id=15087348 Big Question: To what value should |statusOffset| be initialized when m_startOfMsg ? I am attaching an excerpt from the log in another post.
Big Question: To what value should |statsOffset| be initialized when m_startOfMsg = 0 ? Analysis: I have run the test with the attached patch to dump some variables and to make sure the compaction to run ALWAYS (as opposed to the random behavior (approximately once in 100 tries). I think I found the culprit by checking the log. When m_startOfMsg = 0, statusOffset is not initialized and used at https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#758 The uninitialized value can be anything. When m_startOfMsg != 0, statusOffset is initialized by the call to (void)m_curSrcHdr->GetStatusOffset(&statusOffset); https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#733 The code is sprinkled with code snippet to check for bogus statusOffset value. At least in one control flow path It is not initialized before use and thus very likely that the the check would kick in and then keyword processing is not done most of the cases(!). For example, the usage mentioned above is part of a sanity check. https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#758 If the value seems insane, checkForKeyword = false; and no keyword related processing takes place. There is another one at https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#739 too. Thus, I think the failure to initialize |statusOffset| is the cause of previously observed loss of keyword or tag information after compaction(?). Possibly related bugs? https://bugzilla.mozilla.org/buglist.cgi?quicksearch=key%20compact&list_id=15087348 Big Question: To what value should |statusOffset| be initialized when m_startOfMsg = 0? I am attaching an excerpt from the log in another post.