Bug 39035 - App crashing on breakpoint
Summary: App crashing on breakpoint
Status: RESOLVED ANSWERED
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Other ()
Version: Master
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Chris Hamons
URL:
Depends on:
Blocks:
 
Reported: 2016-02-23 10:46 UTC by Adam Hartley [MSFT]
Modified: 2016-02-26 10:58 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 Adam Hartley [MSFT] 2016-02-23 10:46:32 UTC
## Steps to reproduce

1. Download sample and open the CefTest project
2. Place a breakpoint on CefWrapper.WindowlessInit (Line 26 of AppDelegate.cs)
3. Run app

## Expected result

Debugger should break at the specified breakpoint

## Actual result

App crashes:

https://gist.github.com/BytesGuy/a753a24352b2db960146

## Notes 

=== Xamarin Studio ===

Version 5.10.2 (build 56)
Installation UUID: 11a26d86-0d21-407a-8da9-8c197ecc0ad1
Runtime:
	Mono 4.2.2 (explicit/996df3c)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402020030

=== Xamarin.Profiler ===

Version: 0.31.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 7.2.1 (9548.1)
Build 7C1002

=== Xamarin.iOS ===

Version: 9.4.1.25 (Business Edition)
Hash: 962a050
Branch: master
Build date: 2016-01-29 16:59:11-0500

=== Xamarin.Android ===

Version: 6.0.1.10 (Business Edition)
Android SDK: /Users/Adam/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3 (API level 15)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)

SDK Tools Version: 24.4.1
SDK Platform Tools Version: 23.1
SDK Build Tools Version: 23.0.1

Java SDK: /usr
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

=== Xamarin Android Player ===

Not Installed

=== Xamarin.Mac ===

Version: 2.4.1.6 (Business Edition)

=== Build Information ===

Release ID: 510020056
Git revision: bb74ff467c62ded42b7b7ac7fdd2edc60f8647b0
Build date: 2016-01-26 16:24:41-05
Xamarin addins: 8b797d7ba24d5abab226c2cf9fda77f666263f1b
Build lane: monodevelop-lion-cycle6-c6sr1

=== Operating System ===

Mac OS X 10.11.3
Darwin Adams-Retina-MacBook-Pro.local 15.3.0 Darwin Kernel Version 15.3.0
    Thu Dec 10 18:40:58 PST 2015
    root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
Comment 2 Chris Hamons 2016-02-23 22:12:37 UTC
So the stack trace in question shows thread 3 as the thread crashing, which is all 

libBrowserExtension.dylib / org.chromium.ContentShell.framework

You may need to dig into it with a native debugger (lldb or Xcode) to figure out what is going on. From what I can tell, there is little to no C# involvement with this crash right now.
Comment 3 Bruce McNeish 2016-02-24 09:32:18 UTC
Hi Chris,

I appreciate that the issue lies within the dylib.  The issue I have is that the extension works when used from an Xcode project.  I was hoping that you would be able to provide me with more information that could help me pin point what is wrong.  Is there any more info?

Thanks,

Bruce
Comment 4 Chris Hamons 2016-02-24 16:16:53 UTC
So, I took a second look at the stack trace in question:

https://gist.github.com/chamons/8425a8492f7baf3cbe68

And it appears the mono debugger thought you hit stop when you hit the breakpoint. From looking at the code, there should be some useful information in your stdout/stderr. Can you reproduce and attach that output?
Comment 5 Bruce McNeish 2016-02-24 17:35:44 UTC
From your stack trace; it looks like exit was called away down need the app start.  That isn't what I get at all.


Here is my crash dump:

https://gist.github.com/TheBrooster/1833756340251ef80a19

and my application output:

https://gist.github.com/TheBrooster/86250bae2d8fff46ab56


Any insight will be well appreciated.

bruce
Comment 6 Chris Hamons 2016-02-24 22:13:28 UTC
So, it appears that something 

CefWrapper.WindowlessInit(AppDomain.CurrentDomain.BaseDirectory);

is doing is really messing up the mono debugger. I can have it do this:

			CefWrapper.WindowlessInit(AppDomain.CurrentDomain.BaseDirectory);
			CefWrapper.NewSession (400, 400);

			BeginInvokeOnMainThread (() => {
				Console.WriteLine ("Hey");
			});

and any breakpoint on the Hey line will blow up with:

[0224/160420:WARNING:mac_util.mm(472)] Assuming Darwin 15 is Mac OS X 10.11
2016-02-24 16:04:20.483 CefTest[13802:3209571] Internals of CFAllocator not known; out-of-memory failures via CFAllocator will not result in termination. http://crbug.com/45650
[0224/160420:WARNING:mac_util.mm(472)] Assuming Darwin 15 is Mac OS X 10.11
2016-02-24 16:04:20.540 SupportApp[13803:3209745] Internals of CFAllocator not known; out-of-memory failures via CFAllocator will not result in termination. http://crbug.com/45650
[0224/160420:WARNING:mac_util.mm(472)] Assuming Darwin 15 is Mac OS X 10.11
2016-02-24 16:04:20.565 SupportApp[13804:3209747] Internals of CFAllocator not known; out-of-memory failures via CFAllocator will not result in termination. http://crbug.com/45650
[0224/160420:ERROR:mach_broker_mac.mm(152)] Failed to look up named parent port: 0x44e unknown error code


That error appears here:

https://github.com/01org/pa-chromium/blob/master/content/browser/mach_broker_mac.mm#L152

My wild guess is that both our debugger and chromium want to do something with the same port. Some searching does not suggest what that mach error code means.

Considering that chromium also some interesting low level hooks into the memory manager (https://chromium.googlesource.com/chromium/src/+/ff07ccad13c0059e086387947b7fed5a930679dc/base/process/memory_mac.mm) which are the source of those warnings, I would lean towards this being their fault until proven otherwise.
Comment 7 Bruce McNeish 2016-02-25 17:31:21 UTC
Thanks for the update.

Forgetting about the issues surrounding the debugger; if I run the application via double click, or the terminal, CEF does initialise.  However I am hitting an issue with CEF and right clicking.

This post outlines a fix, basically adding a protocol to my application.  It uses MonoMac, how can I achieve the same thing using Xamarin.Mac??

Thanks,

Bruce
Comment 8 Chris Hamons 2016-02-25 19:33:13 UTC
So you can read about protocols here (iOS, but same applies):

https://developer.xamarin.com/guides/ios/application_fundamentals/delegates,_protocols,_and_events/#Protocols

The tl;dr; is that if you are implementing a protocol that is not bound, just make C# methods that take/return the correct types and then do use the export attribute:

    [Export ("tableView:cellForRowAtIndexPath:")]

to let objective-c know they are available.

Since you are a priority customer, you have access to business level support. However, bugzilla is not the best forum for that. If you have additional questions, please consider opening a desk case here:

https://xamarin.com/support

If it is still related to this issue, feel free to link this build and ask to be directly assigned to me. 

Thanks!
-- Chris H
Xamarin.Mac Lead
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2016-02-25 19:38:53 UTC
A quick little clarification in case it's helpful: to "open a desk case," simply send in an email via "Business & Enterprise Support" (from the page Chris mentioned: https://xamarin.com/support). Thanks!
Comment 10 Bruce McNeish 2016-02-25 21:10:30 UTC
Cheers Brendan, was just about to ask.  I'll do that tomorrow when I am in the office.

Chris:  How would I add a protocol to NSApplication at runtime?
Comment 11 Chris Hamons 2016-02-25 21:15:25 UTC
So in theory, there exists really really low level API that you can add/remove methods to your objective-c objects. Something like this:

http://theocacao.com/document.page/327

But let's back up. I feel like if you need to do that, something is really wrong. You normally only have to add protocols to your custom classes (Window Controllers, Windows, Views, etc). And you can do all of that at compile time.

I know of no use case where you need to start adding protocols to Apple framework class. Can you please point me to the doc you are getting this from?
Comment 12 Bruce McNeish 2016-02-26 10:58:10 UTC
Hey Chris,

It look like I have to do the following:

https://bitbucket.org/icenium/xilium.cefglue/commits/41414e4e2d8339ccd54a107d0a2dff0056ae5b93?at=default

Is it possible to use ClientApplication outlined above as the Principal Class in Xamarin Studio?

Thanks,

Bruce