Page MenuHomePhabricator

AutoWikiBrowser throws System.OutOfMemoryException, followed by empty settings file error
Open, Needs TriagePublicBUG REPORT

Description

Description:
I have encountered a System.OutOfMemoryException error twice while using AutoWikiBrowser (AWB). After clicking "OK" on the error dialog, I received another error message stating that the settings file is empty:

Error
The settings file C:\Users\[USERNAME]\AppData\Local\AutoWikiBrowser\Default.xml is empty
This issue corrupts my AWB settings file, requiring me to manually restore or recreate it to continue using AWB.

Steps to reproduce(重現步驟):
I am unsure of the exact cause, but here is the observed behavior pattern:

Use AWB for editing large batches of pages (possibly with large regex rules or find & replace operations).

During a session, a dialog appears:
"已發生類型 'System.OutOfMemoryException' 的例外狀況。"

After clicking OK, another error appears:
"The settings file ...\Default.xml is empty"

Upon checking, the Default.xml file becomes 0 bytes in size.

Expected result:

AWB should handle memory exhaustion gracefully without corrupting configuration files.

Even in case of crash, the settings file should not be emptied or lost.

Actual result(實際結果):

OutOfMemoryException thrown.

Default.xml settings file is corrupted (empty).

Environment(環境資訊):

AutoWikiBrowser version:例如 v6.4.0.0

OS: Windows 10 64-bit (or specify your version)

.NET Framework version: v4.8.1

AWB configuration: Large regex Find & Replace rules, possibly long edit sessions

Additional information

Issue may relate to AWB keeping too much data in memory during long editing sessions or handling large regex replacements.

Suggestion: Implement better exception handling for OutOfMemoryException, and ensure configuration files are saved safely (e.g., use temporary files + atomic rename).

Event Timeline

While I agree that an exception should not clobber a settings file, it can be hard to do anything sensible if there's no memory to do it. So perhaps the general exception handler should take account of that.

Anyway, it's possible that the fix for T428372 will also address the root issue.

It seems that handling the OOM exception shows a dialog but leaves the MainWindow processing events as usual. Anything can go wrong (including showing the dialog) so after attempting to show that dialog the program should be fast-failed. Using the normal exit will need memory which may explain the corrupt files.