Bug 21344 - Crash while inspecting symbols
Summary: Crash while inspecting symbols
Status: RESOLVED INVALID
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 7.2.6
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-07-15 16:03 UTC by Anuj Bhatia
Modified: 2014-07-23 10:12 UTC (History)
7 users (show)

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


Attachments
CrashGraphic1 (239.04 KB, image/png)
2014-07-15 16:04 UTC, Anuj Bhatia
Details
CrashGraphic2 (233.25 KB, image/png)
2014-07-15 16:04 UTC, Anuj Bhatia
Details
DebuggerCrash (2.43 MB, video/mp4)
2014-07-15 16:05 UTC, Anuj Bhatia
Details
Missing Getter ABENDs Debug Session (108.98 KB, image/png)
2014-07-23 08:31 UTC, Howard
Details


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 INVALID

Description Anuj Bhatia 2014-07-15 16:03:53 UTC
Please find attached error information and vide highlighting reproducible behavior when inspecting symbols.
Comment 1 Anuj Bhatia 2014-07-15 16:04:30 UTC
Created attachment 7372 [details]
CrashGraphic1
Comment 2 Anuj Bhatia 2014-07-15 16:04:59 UTC
Created attachment 7373 [details]
CrashGraphic2
Comment 3 Anuj Bhatia 2014-07-15 16:05:26 UTC
Created attachment 7374 [details]
DebuggerCrash
Comment 4 Zoltan Varga 2014-07-18 19:59:47 UTC
What is the problem here ? Is there a testcase ?
Comment 5 Howard 2014-07-19 10:34:04 UTC
I provided both a video and a project, source code and all, that, when executed in Xamarin Studio, will cause the program to terminate both on the mobile device and within Xamarin studio.  One need only to set a breakpoint after the call to the RscMgr = new (line 39) and hover over the rscMgr to begin to see the values. Moments later everything comes a-tumblin down.

Let me know if you need me to upload to DropBox this video, again. 

So, to anser your question most precisely,

What is the problem here ? Is there a testcase ?

Program termination when examing object values. Yes, both source code and a video have been provided.

Questions?
Comment 6 Zoltan Varga 2014-07-21 07:54:24 UTC
There is no testcase, just videos/images.
Comment 7 Howard 2014-07-21 09:12:32 UTC
My attempt at uploading and the reply from your system.  Please advise...
==================

This attached project is provided so that you may reproduce the terminating of the Xamarin Studio when expanding a symbol during a debug session.

You may set a breakpoint on line 39. Once hit, hover over the rscMgr symbol and then expand its content. Wait for a few seconds and the Studio, along with the app running on the iPod device, will terminate.

Please let me know if you require additional details.

Just tried uploading and received an error...

I uploaded this previously via DropBox.  If you can't access the prior upload, please provide instruction for uploading this attachment/project.

"The file you are trying to attach is 37307 kilobytes (KB) in size. Attachments cannot be more than 8000 KB. 
We recommend that you store your attachment elsewhere and then specify the URL to this file on the attachment creation page in the AttachURL field. 
Alternately, if your attachment is an image, you could convert it to a compressible format like JPG or PNG and try again."
Comment 8 Zoltan Varga 2014-07-21 09:26:53 UTC
This bug has no previous comments with links to dropbox.
Comment 10 Howard 2014-07-22 14:19:29 UTC
Ok, I've shrunk the app down to the minimum and was able to upload it.  I have no idea why Anuj didn't include the source/project when he created the ticket.  

You guys sure don't make helping you debug very easy.
Comment 11 Zoltan Varga 2014-07-22 15:01:11 UTC
This is not a debugger problem, adding the following code around TestAppViewController.cs:38 will make the app crash outside the debugger:

			rscMgr = new RscMgr();
			try {
				Console.WriteLine (rscMgr.Delegate);
			} catch (Exception ex) {
				Console.WriteLine ("HIT: " + ex);
			}
			rscMgr.Delegate = new RedParkDelegate();

with the following stack trace:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Jul 22 20:58:52 Zoltan-Vargas-iPhone TestApp[6537] <Error>: -[RscMgr Delegate]: unrecognized selector sent to instance 0x16e82680
Jul 22 20:58:52 Zoltan-Vargas-iPhone TestApp[6537] <Warning>: HIT: MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown.  Name: NSInvalidArgumentException Reason: -[RscMgr Delegate]: unrecognized selector sent to instance 0x16e82680
at (wrapper managed-to-native) ApiDefinition.Messaging:IntPtr_objc_msgSend (intptr,intptr)
at SimpleRedparkTestWithThreads.RscMgr.get_WeakDelegate () [0x00018] in /Users/vargaz/Downloads/SimpleSymbolViewProgramExit/SimpleRedparkTestWithThreads/obj/Debug/ios/SimpleRedparkTestWithThreads/RscMgr.g.cs:415
at SimpleRedparkTestWithThreads.RscMgr.get_Delegate () [0x00002] in /Users/vargaz/Downloads/SimpleSymbolViewProgramExit/SimpleRedparkTestWithThreads/obj/Debug/ios/SimpleRedparkTestWithThreads/RscMgr.g.cs:348
at TestApp.TestAppViewController..ctor (IntPtr handle) [0x0001a] in /Users/vargaz/Downloads/SimpleSymbolViewProgramExit/TestApp/TestAppViewController.cs:40
NSInvalidArgumentException: -[RscMgr Delegate]: unrecognized selector sent to instance 0x16e82680
0   CoreFoundation                      0x2fab1f23 <redacted> + 154
1   libobjc.A.dylib                     0x3a244ce7 objc_exception_throw + 38
2   CoreFoundation                      0x2fab5837 <redacted> + 202
3   CoreFoundation                      0x2fab4137 <redacted> + 706
4   CoreFoundation                      0x2fa03098 _CF_forwarding_prep_0 + 24
5   TestApp                             0x00134e78 wrapper_managed_to_native_ApiDefinition_Messaging_IntPtr_objc_msgSend_intptr_intptr + 224
6   TestApp                             0x00132d58 SimpleRedparkTestWithThreads_RscMgr_get_WeakDelegate + 264
7   TestApp                             0x001322e8 SimpleRedparkTestWithThreads_RscMgr_get_Delegate + 156
8   TestApp                             0x00045550 TestApp_TestAppViewController__ctor_intptr + 300
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Comment 12 Howard 2014-07-22 15:26:09 UTC
You believe that when I hover over the rscMgr object on the line rscMgr = new RscMgr() to show the symbol information while sitting at the breakpoint on the line rscMgr.Delegate should cause the debugger to stop debugging rather than showing the delegate selector as invalid within your symbol popup is proper behavior?  Would this behavior recur if I were to produce this app using VS and display the symbol information?
Comment 13 Rolf Bjarne Kvinge [MSFT] 2014-07-23 05:35:09 UTC
Howard, the app is crashing (the error message comes from Apple's Objective-C code), there's nothing Xamarin.iOS can do about it.

Using Visual Studio will not change the outcome, the app will crash regardless.

The problem is that there's no getter for RscMgr.Delegate, it's a setter only (setDelegate:) in Objective-C.

Changing the api definition like this fixes the problem:

		[Export ("Delegate"), NullAllowed]
		NSObject WeakDelegate { set; }

		[Wrap ("WeakDelegate")]
		RscMgrDelegate Delegate { set; }
Comment 14 Howard 2014-07-23 08:31:38 UTC
Created attachment 7476 [details]
Missing Getter ABENDs Debug Session

Attached is a screen capture of how Xcode handles the situation during a debug session when a symbol has no getter.  They've elected not to terminate the debug session. Why?  Because ABENDing a debug session defeats the purpose of analyzing the state of things so that a correction might be made.  It is of no value if the very debugger one relies upon for such situations simply disappears.

It is your code that is retrieving the symbolic information for display.  It is your analysis that was able to determine the failure related to the missing getter. It is your code, shortly after during the symbolic display appeared, that ultimately ceased to operate, and with it, tearing down the debug session without any information to the developer, me.  Thus, it's clear you have the wherewithal to address the situation in a more 'developer friendly' manner.  Right?

If you would like to see how VS handles a situation where the application is about to fail and how the VS debugger doesn't terminate I will put a scenario together for your review.
Comment 15 Rolf Bjarne Kvinge [MSFT] 2014-07-23 10:12:27 UTC
(In reply to comment #14)
> 
> Attached is a screen capture of how Xcode handles the situation during a debug
> session when a symbol has no getter. 

This is not exactly the same, because Xcode will not execute code, it will only inspect variables. If Xcode were to execute the getter in order to evaluate it, it would be easy to end up crashing the process (which is probably why Xcode doesn't do it).

The problem stems from the fact that Xamarin Studio assumes that executing a property getter will not modify the state of the program; if that assumption is wrong, anything can happen.

In your project Xamarin Studio tries to evaluate the managed getter (btw you can disable this feature in Xamarin Studio (Preferences -> Projects -> Debugger -> "Allow implicit property evaluation and method invocation")), and that ends up crashing the process once the managed getter tries to call the corresponding Objective-C getter.

> It is your code that is retrieving the symbolic information for display.
Yes.

> It is your analysis that was able to determine the failure related to the missing getter.
No. The code that created that "unrecognized selector sent to instance" message is Apple's, not ours. We try to print out as much information as we can at this point, but there is no way to prevent the app from eventually exiting once this condition occurs.

> It is your code, shortly after during the symbolic display appeared,
> that ultimately ceased to operate, and with it, tearing down the debug session
> without any information to the developer, me.  Thus, it's clear you have the
> wherewithal to address the situation in a more 'developer friendly' manner. 

Admittedly Xamarin Studio could be a bit more helpful when an app crashes, and give hints where to look for more information (I've filed an enhancement request for this: bug #21546).

> If you would like to see how VS handles a situation where the application is
> about to fail and how the VS debugger doesn't terminate I will put a scenario
> together for your review.

The closest equivalent code for Windows/Visual Studio would be a managed getter that calls the Win32 ExitProcess method.

Also have in mind that Xamarin Studio is a managed debugger only, it can't do mixed-mode debugging (i.e. debug native code and managed code at the same time) like Visual Studio can. Even if Xamarin Studio had support for mixed-mode debugging, it would not be possible to implement it reliably due to limitations in Apple's debugger toolchain (which we would have to rely on for the native debugging part).