mboxview64.exe crashes

[WorkOfStan]

Hi, the mbox file is a gmail takeout. Few days ago mboxview64.exe opened it without problem. Now it crashes. Pls find enclosed the dump generated by the ReleasePlusStackTrace executable:

mboxview_UnhandledException_StackDump.txt

[zigm]

Thanks for the stack dump. It looks MBox Viewer is trying to read the index file created when folder with mail archives was open the first time.

Also MBox Viewer is trying to restore the last selection, i.e. last folder, mail archive, mail index and/or label index.

I will need some time to review the stack trace. Sounds MBox Viewer is crashing consistently upon startup., right?

I will assume that you have enough memory to load the index file. Index file contains header fields of all mails. Sometimes, lack of memory can occur if you are running other applications that consume large amount of memory.

It is possible that MBox Viewer gets corrupted during startup or somehow the index file got corrupted. I would suggest that you remove the index file (or all index files) first and see whether that resolves the issue during startup and restart.

Location of index files depend on data folder configuration you did after installation and initial startup. You need find *.mboxview files under the MBoxViewer directory and sub-directory depending on the the data folder configuration.

Let me know if manage to remove the index files. I the meantime I will do preliminary investigation.

[zigm]

Regarding your Merge request. Since this my first I need to review implication of 3 different Merge request types proposed. It seems that the first type is recommended which I guess is safe to follow. Anyway, good catch, thanks.

It will not address the crash you reported so I will be continue investigating. There was a lot of code changes in v1.0.3.27 that could cause the reported crash.

[WorkOfStan]

Yes, MBox Viewer was crashing consistently upon startup. Removing the *.mboxview did the trick - MBox Viewer rebuilt the index and I initiated Gmail labels/Create again. It seems that it was a hardware problem :( as it was possible to move mboxview file but not to copy it, because of a "cyclic redundancy checking (CRC) error". So IMHO the issue can be closed. Thanks for the assistance.

Regarding the 3 merge options - if it is "Create a merge commit / Squash and merge / Rebase and merge", I'd propose "Rebase and merge". If you happy with my proposal that is. Otherwise, change the place you don't like with another commit to the pull request branch and then I'd propose you use "Squash and merge" as it would add just one commit with all the changes.

[zigm]

Thanks for the feedback. I will keep the ticket open for a while. If you or potentially other users don't report the same problem for sometime, I will close the ticket. File corruption is rather rare so I will review the stack trace to see if I can spot any potential issue.

If index file gets corrupted, MBox Viewer will very likely crash. Strings are saved in the index file as Data Length (as the integer), followed by the actual data. If the Data Length is corrupted, MBox Viewer will eventually crash. I guess I could add some sanity checks of the Data Length to detect corruption. Simple checks may not work under all scenarios but it would help.

Possibly the index file format should be enhanced and the version of the index file updated. One approach would be append some unique magic ID (as the integer) after the data block or append the same data length again. It was not done this way since I guess the file corruption is rare. However, when it happens, MBox Viewer is not able to recover automatically until the user takes manual steps to resolve the issue.

Thanks for your helpful comments regarding merge options.

[zigm]

I will try "Squash and merge" and see if I have permissions to accept the pull request since I am not the administrator. If I am not able to accept the pull request I am just apply changes you suggested to my local repository.

[zigm]

Merge worked and I finished work in progress and released new v1.0.3.32.

[zigm]

No more similar issues was reported for a couple of months. Not able to recreate the reported issue in our environment.