regarding p. 3, please ignore my suggestion to change mscoree cleanup on process exit. I found a true reason for crash and it is more severe then just crash on exit though easy to fix in Mono. The problem concerns the whole sgen garbage collection under x86_64 when using libmono like Wine does. It can be easily reproduced by a trivial .Net assembly calling GC.Collect() twice in Main (the assembly should be compiled and run as 64bit, 32bit is OK). The problem is sgen_marksweep.c bitcount(mword) function which does it wrong when __GNUC__ is defined (I am attaching a trivial patch which fixes it). I will try to submit it to Mono upstream somehow.
On 02/09/2016 05:16 PM, Paul Gofman wrote:
Hi Vincent,
I currently have all my cases with 64-bit mixed assemblies calling pure .Net working just fine under Wine/Mono (well, almost fine, it looks like I found a bug in Mono System.Windows.Forms cs code, but this is a separate issue), but not with vanilla ones. The following issues are not fixed upstream yet:
- Loading 32-bit pure assemblies in 64-bit code. The patch you attached
some time ago (which includes CorValidateImage implementation) works just fine for me. Do you have any plans for pushing it upstream soon?
- Mono JIT compiler PTR/I8 issues. I've extended a bit your test case
and updated the patch in the Mono bug info. While we are waiting for some reply on this in Mono maybe it is possible to send my patch for wine-mono? I am not sure that it is fully correct (it would in fact require to get familiar with the whole JIT code generation path to make sure), but I presume it is safe to use as:
- the changes relate to 64-bit code generation only, 32 bit is not
affected anyhow;
- as for 64 bit, the changes solely extend what instruction/call
parameters are considered valid for JIT code generator. If something was valid without this patch, it will not be affected. If something was invalid and gets touched by the patch incorrectly for some cases, it will likely result in segfault instead of 'invalid il code' exception in the worst case.
- 64-bit .Net programs constantly crashing on process exit for me (this
affects test case with exe and dll you sent previously as well). The crash happens in Mono GC finalizing code triggered by System.Process.Exit call from mscoree CorExitProcess. The immediate crash reason is that some objects touched by GC through its hash tables get NULL vtable pointer somewhere earlier in deinitialization. I did not find the exact reason for this yet, but looked at coree.c in Mono where they just call ExitProcess without anything else, and comment says: "FIXME: This is not currently supported by the runtime.". If I do the same in mscoree CorExitProcess it fixes the issue with crash. Do you think this is a right way to do for now? If yes I could send a patch for this.
Thanks, Paul.