|
KnightHawk75 -> RE: Unspecified Error when loading scenarios (1147.39) (1/22/2022 12:59:22 PM)
|
Hear me out.
I think there is a larger problem at play that causes this sporadically (pure timing related) in 1147.39, and not in prior builds.
101023 - There is a lot that goes on during that call that could be throwing that error which is an overall catch-all during parsing the xml data back into the system. The stack there leads me to think this is a manual throw prior to the 101023 catch-all for the parsing process. If I had to bet 5$ it relates to something going wrong during the DB hash matching and validity\file check, where the dbrecord returned is null and "error: " + dbfilecheckresult text (which in that case will be 'Unspecified error') is thrown, the cause being an exception trapped with-in the lower call but not specifically recorded.
Why that would happen is unclear at first, as not having the database file, or having one but it being unauthorized should throw other different errors that are not thrown prior. The same is true when DBUsed hash can't initially be parsed - you'll get a different error message. That would leave me to believe during the DBOps record checking (We'll call this DBOps.CheckAndGetValidRecord() for lack of knowing what it's actually called) an exception occurs, result gets set to UnspecifiedError (9999) and null is returned. 9999 is later converted to the text 'Unspecified error' during a manual throw that is invoked when the record is seen to be null. As to what might cause that exception in DBOps.CheckAndGetValidRecord(hash,ref record,checkexists,checkhash)..idk. A null hash would do it, during the dictionary-contains call, or during the else record assignment (but that should have caused earlier and different errors i think). A lower io-exception in the if-file-exists call could throw it, or an io-exception in the call to generate a hash and compare to authorized records for said file could also trigger it.
*shugs*
- I can't find (doesn't mean it doesn't exist), a reason for hash to be null\empty where it would not have caused an exception or logged errors prior. I could see it being a valid string not found in the observable database, but that (in non-pro) should expand out to a DBISUnregistered message and return. So that suggests the contain succeeded and a record set prior to the next two thing happening.
- Assuming that record existed, next is the simple file-exists check, and I can't think of a decent reason it would throw (outside of PathTooLong or fatal ones like outofmemory).
- That leaves the hashgen and compare with the record entry.
That process involves obtaining read\write access to open said entry's linked filename and compute the resulting hash and compare it.
It is possible a timing issue exists with the read\write access requested during the hash generation on the database file? Where perhaps access gets rejected due to 'file in use by another process', and throws? This would be because of the case if two calls are made to the same hashcheck function at roughly the same time with same file as it opens them with FileAccess:ReadWrite, the first call to do so can blocks a second.
Now what would be tying it up to cause that case to happen all of a sudden?
Well there is during startup a low prio thread that kicks off now to go validate each of the db files, including hashchecks.
However in .39 this check appears to be running CONSTANTLY in the background, such that all files are repeatedly checked. If that's the case and the timing is right then a 'process cannot access the file - because it's in use' exception can occur when it and the user action of loading a scene both involve the same database file.
For more detail on the constantly running background check new in 1147.39 see: [post removed by mods perhaps rightfully for TMI, but the right people are aware.]
For those that can at least sporadically generate the error - I'll bet you can't generate the problem at all in 1147.38, unless you force lock it first.
One way to force repo the exception in .39 or .38:
1. Load CMO to mainmenu, open Generic_FileLockTesting.exe .net4 winforms app, insert full path to your installs DB3K_491.db3 file, click "Lock RW", DO NOT close the pop-up message that is generated yet, as the file is release upon clicking ok.
2. Flip back into CMO, enter the editor, load the attached sample scene that uses DB3K_491.
3. Observe the unspecified exception error dialog and loading stop.
4. Now press 'ok' on the dialog from my locking app, exit CMO (order here does not matter).
att:Repo_Unspecifiederror_post5132408.zip
|
|
|
|
