Bug 27859 - App hangs/crashes when "Include the mono runtime in the application bundle" is selected.
Summary: App hangs/crashes when "Include the mono runtime in the application bundle" ...
Status: RESOLVED ANSWERED
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: mmp ()
Version: 1.10.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Chris Hamons
URL:
Depends on:
Blocks:
 
Reported: 2015-03-10 20:45 UTC by Jon Goldberger [MSFT]
Modified: 2015-03-19 02:41 UTC (History)
4 users (show)

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

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 Developer Community or GitHub 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:
Status:
RESOLVED ANSWERED

Description Jon Goldberger [MSFT] 2015-03-10 20:45:16 UTC
## Description:

App hangs/crashes only when the Mono runtime is included in the app bundle. Spoke briefly with Chris H about this and he indicated a suspicion that it is an MMP linker bug, hence filing it as such. Make sure you have Xam.Mac 1.10 when testing. Project won't launch with Xam.Mac >= 1.12 (an issue for another day, likely due to incompatible binaries)

## Steps to reproduce (NOTE: The test project is under NDA. Do not share.)

1. Download the test project and other files from the private comment below. You will need the .this file and import it into the project first.

2. Launch the test project. 

3. After the app loads go to Sync->Receive menu. You should only have to do steps 3 - 6 once, the first time you launch the app.

4. change the Transfer Method to Filesystem, and hit Sync. 

5. Select the TrackhunterNoPreloadsExport.ths file. 

6. After the OK prompt turn on the checkboxes for “Overwrite” and hit Sync again. It may take a couple minutes to get through this. 

7. Stop the app.

8. Run the app again and let it finish loading up tracks (about 5 seconds). 

9. On the Tracks menu choose “Recheck Prices”. 

Expected result: App will continue running.

Actual result: app crashes/hangs with exception: 

>TRACKHUNTER EXCEPTION : Object reference not set to an instance of an object
>Exception during TraceManager initialization:
>System.MissingMethodException: Default constructor not found for type System.Web.Configuration.WebConfigurationHost
>  at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] in <filename unknown>:0 
>  at System.Activator.CreateInstance (System.Type type) [0x00000] in <filename unknown>:0 
>  at System.Configuration.InternalConfigurationSystem.Init (System.Type typeConfigHost, System.Object[] hostInitParams) [0x00000] in <filename unknown>:0 
>  at System.Configuration.InternalConfigurationFactory.Create (System.Type typeConfigHost, System.Object[] hostInitConfigurationParams) [0x00000] in <filename unknown>:0 
>  at System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration (System.String path, System.String site, System.String locationSubPath, System.String server, System.String userName, System.String password, Boolean fweb) [0x00000] in <filename unknown>:0 


Note that this is slightly different than the error the customer noted in the desk case. I will paste that in a private comment below. 

## Additional notes:

Prior to the app crashing/hanging (I have actually only seen a hang) I see these messages in the system console:

3/10/15 2:38:23.000 PM kernel[0]: process Trackhunter[81241] thread 2497802 caught burning CPU! It used more than 50% CPU (Actual recent usage: 99%) over 180 seconds. thread lifetime cpu usage 90.024827 seconds, (62.967763 user, 27.057064 system) ledger info: balance: 90008153038 credit: 90008153038 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 90170478125 

and

>3/10/15 2:38:23.903 PM ReportCrash[81974]: Invoking spindump for pid=81241 thread=2497802 percent_cpu=99 duration=91 because of excessive cpu utilization

and

>3/10/15 2:38:26.466 PM spindump[70018]: Saved cpu_resource.diag report for Trackhunter version 1.5.5 (1.5.5) to /Library/Logs/DiagnosticReports/Trackhunter_2015-03-10-143826_Jons-iMac.cpu_resource.diag

There is also a crash report, which I will paste in a private comment below (in case there is any sensitive info)
Comment 8 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-19 02:41:34 UTC
## The short answer

The "real" primary problem on this bug can be reproduced by adding 1 line of code to a template project:

> System.Web.HttpUtility.UrlEncode ("Hello world", System.Text.UTF8Encoding.Default);


That problem is a duplicate of bug 12565. A workaround suggested on that bug is to add the following line before the call to `UrlEncode()`:


> System.Web.Util.HttpEncoder.Current = System.Web.Util.HttpEncoder.Default;

This line is also _already present_ in the original full app from this bug, but it's commented out, suggesting that this issue was already answered for this code base at some time in the past. Uncommenting this line stops the problem. (You'll also want to upgrade to Xamarin.Mac 1.12. See below.)



### The "real" error message

> [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
>   at System.Web.Util.HttpEncoder.GetCustomEncoderFromConfig () [0x00000] in <filename unknown>:0 
>   at System.Lazy`1[System.Web.Util.HttpEncoder].InitValue () [0x00000] in <filename unknown>:0 




## The long (long) answer

As it was originally described above, this bug was a duplicate of bug 15389.

"Default constructor not found for type System.Web.Configuration.WebConfigurationHost" is the result of enabling link for apps that use certain APIs that depend on System.Configuration.


You can stop that problem (bug 15389) with the following:

1. Add the following lines in a file in the project called "System.Web.xml" (or any other name you like):

<linker>
  <assembly fullname="System.Web">
    <type fullname="System.Web.Configuration.WebConfigurationHost">
      <method name=".ctor" />
    </type>
  </assembly>
</linker>



2. Add the following under "project options -> Mac Build -> Additional mmp arguments"

--xml=${ProjectDir}/System.Web.xml



## What about the freezing behavior?

Note that fix for "System.Web.Configuration.WebConfigurationHost" has no effect on the app freezing behavior.

The remaining details below are actually essentially _irrelevant_ because the hang seems to be fixed on Xamarin.Mac 1.12. On Xamarin.Mac 1.12 the app exits _without hanging_ after the calls to `Environment.Exist(1)` in `Main.cs`.

Side note: I was able to solve the launch crash in Xamarin.Mac 1.12 by catching all exceptions in the IDE, and then looking at the exception messages. There are 2 changes to `[Export("CheckboxChanged:")]` attributes that need to be made to satisfy the stricter registrar in Xamarin.Mac 1.12.

After the upgrade to Xamarin.Mac 1.12, the only remaining issue is bug 12565, which is discussed above.



## Additional details about the investigation process

By "luck," I minimized the test case and found the other problems fairly quickly. The most important thing I did was to pay careful attention to the stack traces and the managed exception messages. Using a global exception handler in the app is OK if you're using it to send details back to an online error logging database, but at least when you're debugging exceptions locally you'll want to make sure you have access to the full stack trace and line numbers where those exceptions are originating.

In general, test case minimization will go more quickly for someone who's already familiar with the existing code base. So the outcome on this bug was rather lucky.



## Analysis of the hang in Xamarin.Mac 1.10

I was able to reproduce the stack trace from comment 1 with `lldb` attached to the app. That allowed me to grab the `mono_pmip()` output for the stack frames, which made it easy to see that the suspicious call to `mono_thread_suspend_all_other_threads()` happens while handling a `NullReferenceException` from `System.Web.Util.HttpEncoder.Current`. I suspect the call to `mono_thread_suspend_all_other_threads()` might be causing a deadlock.


I was able to avoid the hang and instead crash immediately with the NullReferenceException (bug 12565) if I simply commented out the 2 calls to `Environment.Exit(1)` in `Main.cs`.

Then I get the unhandled exception dumped straight to the console:
> [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
>   at System.Web.Util.HttpEncoder.GetCustomEncoderFromConfig () [0x00000] in <filename unknown>:0 
>   at System.Lazy`1[System.Web.Util.HttpEncoder].InitValue () [0x00000] in <filename unknown>:0