Bug 27103

Summary: mono-service segfault reflection.c:7477
Product: [Mono] Runtime Reporter: Stephen Wills <staphen>
Component: ReflectionAssignee: marcos.henrich
Status: RESOLVED FIXED    
Severity: normal CC: kumpera, mono-bugs+runtime, stephan
Priority: ---    
Version: 3.12.0   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Tags: Is this bug a regression?: ---
Last known good build:
Attachments: code for the test app to reproduce the segfault
script demonstrating steps to reproduce the segfault
stack trace dumped by mono
stack trace dumped by gdb

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:
https://github.com/mono/mono/pull/1849
Comment 5 marcos.henrich 2015-06-08 04:03:02 UTC
Fixed in master 6de51884fd82fbb64f05e7171ee5954dd82492a5.
https://github.com/mono/mono/commit/6de51884fd82fbb64f05e7171ee5954dd82492a5