TrayIcon crashed during backup, with .NET runtime exception code c0000005 #5136
Comments
|
Where we left off from above, these were not linked in IndexBlockLink: Moving in smaller steps while collecting, inspecting, predicting, I ran Verify files, Repair, list-broken-files, Compact now, and backup which already had after-backup tests including dlist/dindex block check, Remotevolume/IndexBlockLink sanity, and test of recreate, Interestingly the repair below is not in repair, so only ran upon backup: duplicati/Duplicati/Library/Main/Operation/BackupHandler.cs Lines 484 to 485 in 6f2f8c5 2024-03-29 17:16:56 -04 - [Information-Duplicati.Library.Main.Operation.Backup.RecreateMissingIndexFiles-RecreateMissingIndexFile]: Re-creating missing index file for duplicati-b0a036e8f4a4d413887a64aa2e8e0119d.dblock.zip.aes 2024-03-29 17:16:57 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Put - Started: duplicati-ic0594262095a4474b7f5bc3be68732c0.dindex.zip.aes (5.36 KB) At this point, that was probably the second dindex for duplicati-b0a036e8f4a4d413887a64aa2e8e0119d.dblock.zip.aes, but it's uncertain because the old dblock and its new dindex got deleted in compact after deletes, because the dblock had excess waste. Regardless, the original dindex is still hanging around without a dblock, so recreate notices this. I also have a job to test recreate on the rclone sync of the actual destination, and can run it without bothering the production DB. On the GUI, it pops a red error which then can show me the job log (thanks to changes in Canary to make one rather than making me look into the server log). 2024-03-29 18:45:25 -04 - [Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b0a036e8f4a4d413887a64aa2e8e0119d.dblock.zip.aes by duplicati-i3d50ab7aa9384ceb8593fe0c8733150e.dindex.zip.aes, but not found in list, registering a missing remote file 2024-03-29 18:45:55 -04 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Found 1 missing volumes; attempting to replace blocks from existing volumes GUI Commandline version shows the same thing in a different format: Downloading file duplicati-i3d75c08ac5b64a08945d17b7f3420698.dindex.zip.aes (28.00 KB) ... I'm not sure I like the return code 0 after the error, but maybe it had other reasons to declare success despite logging an error. Because my IndexBlockLink checker was sounding an alarm, I looked at the recreated database, and found the orphaned dindex linked to a State Temporary dblock file, and had its blocks in the Block table. Is this a safe view? The dblock file is gone, and any backup that deduplicates it based on the Block table is going to be referencing a block that doesn't actually exist in the backup. My own Python script dlist/dindex checker would fall into the same trap, as it assumes the dindex blocks are actually in backup. Arguably this is a secondary issue to the original crash, but I didn't feel like opening another issue without any developer input. |
No it sounds like it will lead to bad things going forward.
That is because the messages are classified as warnings. I think the logic here is a bit weird, because those |
It did look like State Temporary files get deleted typically (maybe subject to options like no-backup-verification), to save things. Before finding you were here after the "Unexpected differences" forum work, I almost pointed out there that this issue causes:
and it's not because of a recently interrupted compact in a backup. Anyway, back to forum to keep catch up on recent actions. |
Environment info
Description
TrayIcon crashed during a routine backup, leaving its green icon which (as usual) vanished when moused over. Event log has:
Logged: 3/24/2024 12:59:32 PM Source: .NET Runtime Event ID: 1026 General:
Logged: 3/24/2024 12:59:39 PM Source: Application Error Event ID: 1000 General:
Steps to reproduce
Crash partway through backup. It managed to upload 10 dblock and 10 dindex files to OneDrive before the crash though.
Backup
As you can see, my Duplicati folder path is a little non-standard. For years I've been installing Duplicati from
.zipfiles into per-version folders, enabling easier start of whatever Duplicati I need for whatever purpose I'm aiming at. I also disable autoupdate notifications and the usual dual-procsss updater steps because I want to run exactly the version I need. I don't think this setup is related to crash though.Some Google searching makes me think .NET Framework had a memory access violation. I don't know how Duplicati can fix that beyond moving to a newer platform (to possibly get a different set of bugs -- but hopefully fewer overall). See Battle plan for migrating to .Net8
Screenshots
Debug log
I do have a profiling log with
--profile-all-database-queries, but I think there are intentional or accidental gaps in what that shows.A slightly anonymized chunk at the end is:
I'm also preserving the database at the time of crash (including
-journal), and I also have the DB before (I keep a rolling history).Some things in the crash DB look less than perfect, so I will probably bring this back up carefully, so any Duplicati goof gets found.
Sometimes all this care winds up being wasted, but I'd rather err on the side of caution because there are still unsolved corruptions around, which typically stay unsolved due to lack of information. If any developer experts want to advise on my analysis, please do.
Bad cleanups at backup time from a previous backup that failed were a suspected backup-breaker in the forum, but data is scarce...
Unexpected difference in fileset; unable to delete broken version. Crash here has lots of Duplicati info, but little on .NET Framework.
One thing I'll be looking at is what happens to a dblock/dindex pair that were uploaded but aren't currently in IndexBlockLink data.
The text was updated successfully, but these errors were encountered: