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.
MT 5.2.11, iOS Simulator, DEBUG build
- Run the project attached (iPhone Simulator - iPad is not implemented!).
- Hit the DONE button on top of the keyboard and the second input field will become 1st responder.
- Hit the "DONE" button again.
- A UIActionSheet is shown with a date picker in it.
- Then simulate a memory warning in the Simulator.
- Next, hit the UITabBarItem labelled "ITEM" in the action sheet.
Result is the crash below. There has recently been a discussion about NULL refs in combination with UIActionSheet on the MT mailing list. Maybe this is related?
at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string,intptr,intptr) <IL 0x0009f, 0xffffffff>
at MonoTouch.UIKit.UIApplication.Main (string,string,string) [0x00042] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:29
at CashTracker.Application.Main (string) [0x00000] in /Users/Krumelur/Documents/Develop/CashTracker/CashTracker/Main.cs:17
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>
0 CashTracker 0x0009094c mono_handle_native_sigsegv + 284
1 CashTracker 0x00005cd8 mono_sigsegv_signal_handler + 248
2 libsystem_c.dylib 0x9340e59b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 UIKit 0x02499a0e -[UIBarButtonItem(UIInternal) _sendAction:withEvent:] + 145
5 CoreFoundation 0x011d6e99 -[NSObject performSelector:withObject:withObject:] + 73
6 UIKit 0x0225b14e -[UIApplication sendAction:to:from:forEvent:] + 96
7 UIKit 0x0225b0e6 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 61
8 UIKit 0x02301ade -[UIControl sendAction:to:forEvent:] + 66
9 UIKit 0x02301fa7 -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 503
10 UIKit 0x02301266 -[UIControl touchesEnded:withEvent:] + 549
11 UIKit 0x022803c0 -[UIWindow _sendTouchesForEvent:] + 513
12 UIKit 0x022805e6 -[UIWindow sendEvent:] + 273
13 UIKit 0x02266dc4 -[UIApplication sendEvent:] + 464
14 UIKit 0x0225a634 _UIApplicationHandleEvent + 8196
15 GraphicsServices 0x047c5ef5 PurpleEventCallback + 1274
16 CoreFoundation 0x011a9195 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
17 CoreFoundation 0x0110dff2 __CFRunLoopDoSource1 + 146
18 CoreFoundation 0x0110c8da __CFRunLoopRun + 2218
19 CoreFoundation 0x0110bd84 CFRunLoopRunSpecific + 212
20 CoreFoundation 0x0110bc9b CFRunLoopRunInMode + 123
21 GraphicsServices 0x047c47d8 GSEventRunModal + 190
22 GraphicsServices 0x047c488a GSEventRun + 103
23 UIKit 0x02258626 UIApplicationMain + 1163
24 ??? 0x0cce29d5 0x0 + 214837717
25 ??? 0x0cce1080 0x0 + 214831232
26 ??? 0x0cce0d78 0x0 + 214830456
27 ??? 0x0cce0ece 0x0 + 214830798
28 CashTracker 0x0000a042 mono_jit_runtime_invoke + 722
29 CashTracker 0x00169f4e mono_runtime_invoke + 126
30 CashTracker 0x0016e034 mono_runtime_exec_main + 420
31 CashTracker 0x00173455 mono_runtime_run_main + 725
32 CashTracker 0x00067245 mono_jit_exec + 149
33 CashTracker 0x002116a5 main + 2837
34 CashTracker 0x00003095 start + 53
Created attachment 1986 [details]
Sample demonstrating the crash
I'd already be happy to know what exactly is NULL here and why?
Mmmh, okay, found it. I'm adding the .View of DatePickerController as a subview to the UIActionSheet. This allows the instance of the controller being collected.
My problem but still annoying. I think you should maybe keep a back reference from the view to the controller. Would that be possible?
René: it is a tricky subject, because we must also take great care to not prevent objects from getting garbage collected / freed when they're not used anymore, and circular references have a bad habit of doing exactly that, in particular when some of those references are from ObjC code and some from managed code.
In this case what would happen is that the View would have a managed reference to the Controller, so the Controller cannot be garbage collected unless the View is freed. Now the Controller has a native reference to the View, and the View cannot be freed unless the Controller is freed. The managed GC sees that somebody has a native reference to the VIew (but it does not know who), so it will not garbage collect the View while that native reference exists. And we end up in a situation where neither the View nor the Controller will get garbage collected.
We've spent much time trying to make this work better, but we've reached the conclusion that it's impossible to make it work perfectly (i.e. not leak nor crash), so I'll close this as WONTFIX.