Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 2432 [details]
test env for the failing test application
I have programs that have been running fine with the Boehm GC on 2.10.9 and 2.11.3 on both OSX and Linux. Switching to sgen to take advantage of larger memory and a newer GC, unfortunately results in runtime crashes or anomalous behavior.
The variations I have tried are:
1. mono (boehm collector)
2. mono --llvm
3. mono --gc=sgen
4. mono --gc=sgen --llvm
On 2.10.9 with OSX, #1, #2 and #3 succeed, but #4 crashes the VM with a segmentation fault.
On linux with 2.11.3, it is worse, #1 and $2 work, but #3 and #4 produce anomalous behavior, where a member variable in a class is not initialized.
I reduced the problem from a complex application to some tests against the application library. Unfortunately the library is quite integrated and involved, so have sent a tar with instructions on how to run. If you need source code for the whole library can provide, but suspect the problem will be visible without.
The problem on the linux side manifests as an exception, where I am checking to see whether a member variable is null. It should not be possible for this to ever be null, as is assigned in the solo ctor and the value is not ever changed. Nevertheless, in the context of sgen, the class member variable is null.
The class in question is DateParser (you'll see in the exception).
System.TypeInitializationException: An exception was thrown by the type initializer for com.gf.fin.instruments.InstrumentEquityDef ---> System.Exception: internal error, lexer should not be null
at com.gf.common.parsing.dates.DateParser.Parse (System.String sdate, com.gf.common.time.ZTimeZone default_zone) [0x00000] in <filename unknown>:0
at com.gf.common.time.ZDateTime.Parse (System.String date, com.gf.common.time.ZTimeZone zone) [0x00000] in <filename unknown>:0
at com.gf.common.time.ZDateTime..ctor (System.String date, com.gf.common.time.ZTimeZone zone) [0x00000] in <filename unknown>:0
at com.gf.common.time.ZDateTime.Parse (System.String date, System.String zone) [0x00000] in <filename unknown>:0
at com.gf.fin.instruments.InstrumentEquityDef.Load (com.gf.common.xml.XmlNode xdef) [0x00000] in <filename unknown>:0
at com.gf.fin.instruments.InstrumentEquityDef.LoadAll (System.String xml) [0x00000] in <filename unknown>:0
at com.gf.fin.instruments.InstrumentEquityDef..cctor () [0x00000] in <filename unknown>:0
with master mono-sgen on osx, normal mono works fine.
The exception above has now been fixed in master/2.10 branch.
Any idea whether this will also fix the segmentation fault when run on OSX as --gc=sgen --llvm?
I'll pull the latest for linux and test. I am not able to build mono on osx, so I just use the prebuilt packages.
>> Any idea whether this will also fix the segmentation fault when run on OSX as
>> --gc=sgen --llvm?
The bug could lead to random crashes, so this might got fixed too.
looks good on linux, thanks