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 9852 [details]
code for the test app to reproduce the segfault
In our application, we recently found that mono-service will sometimes crash when deserializing objects using the BinaryFormatter. I did some debugging and found that the crash will only occur given the following conditions.
1. Environment.CurrentDirectory is not the directory in which the assembly containing the deserialized object's type resides.
2. The version of the assembly containing the deserialized object's type is not the same as it was when the type was serialized.
On line 130 of mono-service.cs, the AppDomainSetup's ApplicationBase property is set to Environment.CurrentDirectory. This path is used as the search path for assemblies when loading types later on. If this path were pointing to the directory containing the assembly, the type loader would succeed before attempting to search for the type in mscorlib (icall.c:1320 in the gdb stack trace).
The gdb stack trace says that the segfault occurs in reflection.c on line 7477, but I believe it actually occurs on line 7464. The stack trace indicates that image is NULL upon entering this method, and the if statement prior to line 7464 doesn't check for that.
I'm not sure what the best solution for this would be. Candidate solutions I've thought of are to modify mono-service.cs to use the path containing the assembly for ApplicationBase, to check for null on line 7463 of reflection.c, or both. A workaround is to cd to the path containing the assembly before invoking mono-service. I've written a simple test app to reproduce this behavior (without mono-service) by creating my own AppDomain and explicitly setting AppDomainSetup.ApplicationBase.
* test.cs contains the code for the app used reproduce the segfault.
* test.sh demonstrates the steps to follow in order to reproduce the segfault.
* test-monotrace.txt is the stack trace dumped by mono after the segfault.
* test-gdb.txt is the stack trace dumped by gdb after the segfault.
Created attachment 9853 [details]
script demonstrating steps to reproduce the segfault
Created attachment 9854 [details]
stack trace dumped by mono
Created attachment 9855 [details]
stack trace dumped by gdb
Hi Stephen Wills,
Thank you for the detailed bug report.
The segmentation fault issue was solved in master now that it uses referencesource Serialization.
There is still an issue while running your test.
The recently introduced serialization code is calling a method that is not implemented.
The following pull request implements the method:
Fixed in master 6de51884fd82fbb64f05e7171ee5954dd82492a5.