Bug 27103 - mono-service segfault reflection.c:7477
Summary: mono-service segfault reflection.c:7477
Alias: None
Product: Runtime
Classification: Mono
Component: Reflection ()
Version: 3.12.0
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: marcos.henrich
Depends on:
Reported: 2015-02-16 10:43 UTC by Stephen Wills
Modified: 2015-11-17 06:46 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

code for the test app to reproduce the segfault (2.37 KB, text/plain)
2015-02-16 10:43 UTC, Stephen Wills
script demonstrating steps to reproduce the segfault (222 bytes, application/octet-stream)
2015-02-16 10:44 UTC, Stephen Wills
stack trace dumped by mono (8.80 KB, text/plain)
2015-02-16 10:44 UTC, Stephen Wills
stack trace dumped by gdb (2.17 KB, text/plain)
2015-02-16 10:45 UTC, Stephen Wills

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Stephen Wills 2015-02-16 10:43:18 UTC
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.
Comment 1 Stephen Wills 2015-02-16 10:44:08 UTC
Created attachment 9853 [details]
script demonstrating steps to reproduce the segfault
Comment 2 Stephen Wills 2015-02-16 10:44:47 UTC
Created attachment 9854 [details]
stack trace dumped by mono
Comment 3 Stephen Wills 2015-02-16 10:45:09 UTC
Created attachment 9855 [details]
stack trace dumped by gdb
Comment 4 marcos.henrich 2015-06-04 05:59:10 UTC
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:
Comment 5 marcos.henrich 2015-06-08 04:03:02 UTC
Fixed in master 6de51884fd82fbb64f05e7171ee5954dd82492a5.