Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
This error appeared when tapping a button, although there is no in-app code for handling the button touch. I set up the button touch handling visually by creating a segue in the storyboard using the XCode storyboard editor. This was done by Option-clicking the button in XCode, then dragging to the view controller that segued a transition to occur with.
2013-08-29 19:25:14.559 XNotesiOS[19348:907] Unhandled Exception: Failed to
marshal the Objective-C object 0x21be9290 (type:
not find an existing managed instance for this object, nor was it possible
to create a new managed instance (because the type
'MonoTouch.UIKit.UIGestureRecognizer+_UIGestureRecognizerDelegate' does not
have a constructor that takes one IntPtr argument).
Unable to provide a test case that consistently reproduces the issue since the UIGestureRecognizerDelegate error has only been displayed once.
Version 4.0.12 (build 3)
Installation UUID: 5c4c653a-6321-4998-a882-b71b1e1a4005
Mono 3.2.0 ((no/7c7fcc7)
Package version: 302000000
Apple Developer Tools
Xcode 4.6.3 (2068)
Version: 4.8.1 (Business Edition)
Supported Android versions:
1.6 (API level 4)
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
Java SDK: /usr
java version "1.6.0_51"
Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)
Version: 184.108.40.206 (Business Edition)
Build date: 2013-13-08 05:24:39-0400
Release ID: 400120003
Git revision: 593d7acb1cb78ceeeb482d5133cf1fe514467e39
Build date: 2013-08-07 20:30:53+0000
Xamarin addins: 25a0858b281923e666b09259ad4746b774e0a873
Mac OS X 10.8.4
Darwin um-mbp 12.4.0 Darwin Kernel Version 12.4.0
Wed May 1 17:57:12 PDT 2013
Created attachment 4765 [details]
Crash report device log from my phone when it occurred again after filing this report
This issue occurs repeatedly in my app as I am stress-testing it. I can go through a workflow 3 times before tapping the button causes this crash.
Created attachment 4766 [details]
Video of test workflow
App crashes consistently on starting the third round of the workflow by tapping the "Create XNote" button.
One clarification: The crash occurs consistently. I have only seen the message in the XS console output regarding the missing constructor with an IntPtr argument one time.
I have determined this issue and the other random crashes I've been seeing only occur if the SGen GC is being used. I switched my project back to the Boehm GC and no errors are occurring, even if I proceed through the same workflow 20 times. I also monitored overall memory consumption and leaks using the XCode Instruments profiler and see things being released as expected.
Such issues are, 99% of the time, related to a managed instance with no reference. At some point the GC will collect it and it will crash whenever some native code tries to callback into the (now freed) managed instance.
> The crash occurs consistently.
Please provide a self-contained test case (the smaller the better) and we'll look into it.
Thanks for the response. The crash occurs consistently in my app, being that it was always happening on the beginning of the third round of the workflow. Creating a small self-contained test case may not be so easy. You can watch the attached video to see the flow if you're interested.
Fortunately, I did determine the source of the problem. I was creating a UITapGestureRecognizer when the keyboard became visible so I could detect the user tapping outside of the edit field and dismiss the keyboard. I was properly releasing the recognizer if the the user tapped outside the edit field or otherwise dismissed the keyboard. However, I was only setting the property to null in my Dispose method, instead of first calling View.RemoveGestureRecognizer(). So, my case falls into the 99% as you say. :-)
Glad you got it to work :)