[Problem] Protection Check stalls on specific disk #769

New Issue

claunia · 2026-01-29T16:21:58Z

claunia commented

2026-01-29 16:21:58 +00:00

Originally created by @hughobrien on GitHub (Dec 8, 2024).

Originally assigned to: @mnadareski, @Deterous on GitHub.

I've tried this on MPF.UI_3.2.4_net9.0-windows_win-x64_release and the Nov 5 Rolling.

When dumping Company of Heroes, which contains many archives of small files. The protection check stalls. If I mount the iso with wincdemu (to spare my drive) and run the protection scan that way it also stalls.

I let it run for about 6 hours so I'm confident it was truly stuck. Running without archive scan it completes as expected.

Running protection check on its own doesn't seem to have any issues (below is Linux but Windows worked fine also)

steam-run ProtectionScan_3.3.1_net9.0_linux-x64_release/ProtectionScan -d DISK1 | tee log

❯ wc -l log 
166073 log

❯ grep -v 'Time elapsed' log | wc -l
166052

❯ < log choose 1 | sort -u | wc -l
74648

I can provide the iso which with wincdemu should allow for reproduction. I'm in the VGPC discord.

Originally created by @hughobrien on GitHub (Dec 8, 2024). Originally assigned to: @mnadareski, @Deterous on GitHub. I've tried this on `MPF.UI_3.2.4_net9.0-windows_win-x64_release` and the Nov 5 Rolling. When dumping [Company of Heroes](http://redump.org/disc/65498/), which contains many archives of small files. The protection check stalls. If I mount the iso with wincdemu (to spare my drive) and run the protection scan that way it also stalls. I let it run for about 6 hours so I'm confident it was truly stuck. Running without archive scan it completes as expected. Running protection check on its own doesn't seem to have any issues (below is Linux but Windows worked fine also) ``` steam-run ProtectionScan_3.3.1_net9.0_linux-x64_release/ProtectionScan -d DISK1 | tee log ❯ wc -l log 166073 log ❯ grep -v 'Time elapsed' log | wc -l 166052 ❯ < log choose 1 | sort -u | wc -l 74648 ``` I can provide the iso which with wincdemu should allow for reproduction. I'm in the VGPC discord.

claunia added the bug label 2026-01-29 16:21:58 +00:00

claunia closed this issue

2026-01-29 16:21:58 +00:00

claunia commented

2026-01-29 16:21:58 +00:00

@mnadareski commented on GitHub (Dec 10, 2024):

This is likely related to the internal queue that is used by the logging part of the UI. It is easily overwhelmed especially in cases of many small files being scanned during a protection scan.

@mnadareski commented on GitHub (Dec 10, 2024): This is likely related to the internal queue that is used by the logging part of the UI. It is easily overwhelmed especially in cases of many small files being scanned during a protection scan.

claunia commented

2026-01-29 16:21:59 +00:00

@Deterous commented on GitHub (Dec 11, 2024):

I was able to replicate this issue somewhat, on my machine (laptop with 8GB memory) it completed the scan (status text made that clear) but MPF hung just before it could finish printing the last remaining log lines (last printed line was 99%... but not yet printed the final detection results).

I tried removing the internal queue completely, which did not fix the problem, but it did behave somewhat differently.

A solution to this would perhaps be to replace the internal queue with pushing chunks of text rather than line-by-line, and/or limiting how many messages scanning prints to the MPF log.

@Deterous commented on GitHub (Dec 11, 2024): I was able to replicate this issue somewhat, on my machine (laptop with 8GB memory) it completed the scan (status text made that clear) but MPF hung just before it could finish printing the last remaining log lines (last printed line was 99%... but not yet printed the final detection results). I tried removing the internal queue completely, which did not fix the problem, but it did behave somewhat differently. A solution to this would perhaps be to replace the internal queue with pushing chunks of text rather than line-by-line, and/or limiting how many messages scanning prints to the MPF log.

claunia commented

2026-01-29 16:21:59 +00:00

@mnadareski commented on GitHub (Dec 19, 2024):

This should be fixed as of 9207627fb0. Please test with this or a later build to confirm that it has been fixed

@mnadareski commented on GitHub (Dec 19, 2024): This should be fixed as of https://github.com/SabreTools/MPF/commit/9207627fb03648149bc04bcafb4f1fe6a4d6e1e0. Please test with this or a later build to confirm that it has been fixed

claunia commented

2026-01-29 16:21:59 +00:00

@mnadareski commented on GitHub (Dec 19, 2024):

The reason that this was hanging on these sort of discs is that it was a combination of 3 separate issues:

The internal dispatcher being used was invoking things "mostly synchronously", even though the method being used said that it acted async. This was fixed by using the async variant on all supported frameworks.
The internal queue was adding slight overhead on every single operation which was compounding when the log was overrun with lines to append. This was fixed by... removing the internal queue entirely because it was adding nothing after the previous issue was fixed.
The internal structure that holds the log data was getting overwhelmed and likely was hitting the per-object memory limit for collections. This was fixed by adding a 5000 line cap to the log, removing from the start of the log if it goes over.

@mnadareski commented on GitHub (Dec 19, 2024): The reason that this was hanging on these sort of discs is that it was a combination of 3 separate issues: - The internal dispatcher being used was invoking things "mostly synchronously", even though the method being used said that it acted async. This was fixed by using the async variant on all supported frameworks. - The internal queue was adding slight overhead on every single operation which was compounding when the log was overrun with lines to append. This was fixed by... removing the internal queue entirely because it was adding nothing after the previous issue was fixed. - The internal structure that holds the log data was getting overwhelmed and likely was hitting the per-object memory limit for collections. This was fixed by adding a 5000 line cap to the log, removing from the start of the log if it goes over.

claunia commented

2026-01-29 16:21:59 +00:00

@mnadareski commented on GitHub (Dec 20, 2024):

Confirmed to be fixed by two separate people.

@mnadareski commented on GitHub (Dec 20, 2024): Confirmed to be fixed by two separate people.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/MPF#769