gfs
commented
5 months ago Thanks for the report. I'll try to investigate today to see if I can reproduce.
Closed jachstet-sea closed 5 months ago
gfs
commented
5 months ago Thanks for the report. I'll try to investigate today to see if I can reproduce.
gfs
commented
5 months ago I ran two scans locally and was not able to reproduce this. Comparing the two releases I don't see or recall any changes that should have affected collectors in general, the database middleware, or the registry collector other than the update to Microsoft.Data.Sqlite 8.0.0 (vs 7.x previously) - where the error is ultimately thrown. However, I see there is an update for 8.0.1, which should be included with the build from #709 later today. Please let me know if the new build I anticipate releasing later today with the updated dependency resolves the issue.
jachstet-sea
commented
5 months ago Hi @gfs, thanks for the timely investigation. I would also assume that the root cause of the issues doesn't lie in your code but is rather to be looked for in the dotnet runtime. I'll check if I can add some easy debugging stuff to our build process or create a simple project to verify differences between dotnet 7 and 8.
jachstet-sea
commented
5 months ago Okay, maybe an deeper analysis is not required .... The VM we are using has around 6GByte of free space. The latest version of ASA writes 3GB for one run. I'll check if the older versions write less
jachstet-sea
commented
5 months ago Update: The database files of ASA v2.3.298 after one full scan are only 1.28GByte in sum, compared to the 3.00GByte that ASA v2.3.308 creates. So I that definitely hints that the cause or the error message we are getting is disk space (and as such, the error message is valid) but it leaves the question open why the file size differs that much.
gfs
commented
5 months ago Interesting. Thanks for doing the additional investigation. It sounds like you're unblocked for now then. I'm not sure immediately why the database size would have increased by such a large factor either. Perhaps its a difference in how the SQLite library calculates indices? I'll try to find some time to double check that I can reproduce this size difference between versions and see if I can identify anything within our control to shrink them back down a bit. I'll try to get to that later this week, or next week.
jachstet-sea
commented
5 months ago Indeed, we are no longer blocked. I can confirm that ASA works as expected once we gave the build VM some more disk space so it's no longer an issue for us. I'd be very interested if you can confirm the larger database sizses on your end 👍
gfs
commented
5 months ago I can reproduce a significant difference in the number of records collected for the registry collector between 2.3.298 and the latest. However, with further investigation I don't believe this indicates an error in the new code - but rather reflects a bug fix that was previously preventing some data from being collected. PR #701 added a fix for the registry walker bailing out too early if it encountered a null Key, preventing it from fully crawling a the rest of the subkey, thus the new version will have a more complete collection of data and thus the database is subsequently larger.
jachstet-sea
commented
5 months ago Thanks for investigating and the headup, #701 indeed seems like a worthy thing to be fixed :)
Describe the bug We recently updated our CI builders from v2.3.298 to v2.3.305 (alongside installing dotnet 8 runtime via Visual Studio installer). Since then, we are getting following errors on SECOND scan (first scan is fine), errors keep repeating:
To be honest, I cannot directly see the "disk space free" when it occurs since we are using ephemeral runners/VMs and I can not easily monitor disk space while the build is running. However, after reverting to v2.3.298, all is fine again.
To Reproduce Steps to reproduce the behavior:
Expected behavior Works as before (with v2.3.298)
Screenshots See log outputs below
System Configuration (please complete the following information):
Additional Context Log of first scan with v2.3.298:
Log of second/comparison scan with v2.3.298:
Log of first scan with v2.3.305:
Log of second scan with v2.3.305 (truncated since errors keep coming):