Logos crash with System.AccessViolationException about logoslinuxinstaller HOT 4 OPEN

Notes and ideas (from someone quite new to .NET, so not everything might be correct):

• There are reports that the crash has something to do with a corrupted resource index. This matches the backtrace insofar as the code seems to be related to resource update (see CreateResourceUpdatePopupMessage)
• The functions starting with Libronix and LDLS4 seem to be Logos-specific functions (with Libronix being the technical core of Logos, according to https://www.logos.com/grow/so_do_i_call_it_logos_or_libro/ )
• The other functions are from .NET, though the code seems to be shipped with Logos, so not from the .NET install

The backtrace indicates that there might be heap corruption going on, but I could not verify this so far via WINEDEBUG=warn+heap, so this might be a different issue (needs another round of tests)

Ideas for further exploration:

• Catch the exception in a .NET debugger and look at which bitmap is being loaded (see call System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(System.Uri, System.Uri, System.IO.Stream, System.Windows.Media.Imaging.BitmapCreateOptions, System.Windows.Media.Imaging.BitmapCacheOption, System.Net.Cache.RequestCachePolicy, Boolean)). This might provide clues what is wrong.
• Look at Logos traces (see https://wiki.logos.com/diagnostic_logging) to see if there is any info related to corrupted data
• Try to run the corrupted database on Logos on Windows. If it crashes there, too, then this is a strong indication that the actual problem happened earlier

from logoslinuxinstaller.

Note: this bug is not specific to the installer, but this seems the best place to track it and collect infos on it.

I do this on GitHub while I gather enough info to open a bug at WineHQ. I was doing that with this issue: ferion11/LogosLinuxInstaller#105 until @jg00dman told me the issue was in wine 64bit having yet to implement error catching. My assumption was that in time Wine devs would fix it. I never found the PR or discussion associated with it.

Have you checked Wine's stuff to see if it's known or is that why you are thinking to test the corrupted DB on Windows, to rule things out?

Also, here's a link to our reported bugs:

https://appdb.winehq.org/objectManager.php?sClass=version&iId=41116

from logoslinuxinstaller.

See also the attachment at:

https://bugs.winehq.org/show_bug.cgi?id=54870#c2

from logoslinuxinstaller.

Thanks @thw26 for the pointers! I searched generically for the backtrace, but did not yet look at the Wine bug database in particular. I think that's worth doing.
I wanted to collect info here, since I don't know yet where the bug is, and I guessed that probably the Wine developers will only look at the bug if it is more specific (i.e. it is clear where the bug in Wine is). But I could be wrong of course.

I wanted to test the DBs on Windows to narrow down the problem space (since right now I only know that the exception causes the program to stop, but the real error (i.e. memory corruption) could have been much earlier). This could be very tricky to narrow down without the source code of the program, but I'll try at least :)

I think better understanding what the app is trying to load when the exception hits would be a good first step, but I'll need to get to know .NET debuggers first (having never debugged a .NET program before).

Regarding database corruption: most databases in Logos seem to be standard sqlite databases, so general file structure of .db files can be verified.

from logoslinuxinstaller.