Hi Rolf,
thanks for your reply.
Unfortunately none of these exceptions can be reproduced easily. There is
absolutely no consistency. All I can say: they only ever happen on the
device.
I have now added the ctor just to see where it is crashing next. That way
I'm hoping to find out what it is trying to call.
Meanwhile I received the crash logs. It is getting a memory warning, that I
understand. But why would that do something on a view controller of a
UIPageViewController? It obviously cannot be the one that is currently
visible.
There are two places where I'm adding controllers to the
UIPageViewController. When initializing (and there I even hold a
reference!):
PdfSinglePageController oInitController = new
PdfSinglePageController(this.oPdfViewerController,
oPage);
this.SetViewControllers( new UIViewController[] { oInitController},
eDirection, bAnimate, this.HandlePageTurnCompleted );
this.oCurrentSinglePageController = oInitController;
And when getting the next or previous one in my
UIPageViewControllerDataSource:
public override UIViewController GetPreviousViewController
(UIPageViewController pageViewController, UIViewController
referenceViewController)
{
int iCurrentPage = this.oCurrentSinglePageController.Page.PageNumber;
if( iCurrentPage >= this.oPdfViewerController.oPdfDoc.Pages)
{
return null;
}
iCurrentPage++;
CGPDFPage oNextPage = this.oPdfViewerController.oPdfDoc.GetPage(
iCurrentPage );
PdfSinglePageController oNextController = new
PdfSinglePageController(this.oPdfViewerController,
oNextPage);
return oNextController;
}
Could the UIPageViewControllerDataSource be the problem? If the managed
controller leaves the scope of the method, there is no reference anymore? I
will try to get rid of the ObjC delegates and use the Monotouch C# delegate
methods instead.
Here's the crash:
0 libsystem_kernel.dylib 0x377cf32c __pthread_kill + 8
1 libsystem_c.dylib 0x33de4208 pthread_kill + 48
2 libsystem_c.dylib 0x33ddd298 abort + 88
3 MobileTestApp 0x00dfaffe 0x1000 + 14655486
4 MobileTestApp 0x00e13ab6 0x1000 + 14756534
5 MobileTestApp 0x0000445e 0x1000 + 13406
6 libsystem_c.dylib 0x33dee7e6 _sigtramp + 42
7 libsystem_c.dylib 0x33de4208 pthread_kill + 48
8 libsystem_c.dylib 0x33ddd298 abort + 88
9 MobileTestApp 0x00eb720a 0x1000 + 15426058
10 MobileTestApp 0x00eb722c 0x1000 + 15426092
11 MobileTestApp 0x00de6866 0x1000 + 14571622
12 MobileTestApp 0x00dfab8c 0x1000 + 14654348
13 MobileTestApp 0x00dfac5a 0x1000 + 14654554
14 MobileTestApp 0x00e12d7a 0x1000 + 14753146
15 MobileTestApp 0x0048e2bc 0x1000 + 4772540
16 MobileTestApp 0x0079b86c 0x1000 + 7972972
17 MobileTestApp 0x0079b8ec 0x1000 + 7973100
18 MobileTestApp 0x007f5ec8 0x1000 + 8343240
19 MobileTestApp 0x00ebc49c 0x1000 + 15447196
20 MobileTestApp 0x00ebfeac 0x1000 + 15462060
21 UIKit 0x37309b34 -[UIViewController
unloadViewForced:] + 80
22 UIKit 0x37451492 -[UIViewController
purgeMemoryForReason:] + 58
23 Foundation 0x35ed24f8 __57-[NSNotificationCenter
addObserver:selector:name:object:]_block_invoke_0 + 12
24 CoreFoundation 0x36fbd540
___CFXNotificationPost_block_invoke_0 + 64
25 CoreFoundation 0x36f49090 _CFXNotificationPost + 1400
26 Foundation 0x35e463e4 -[NSNotificationCenter
postNotificationName:object:userInfo:] + 60
27 Foundation 0x35e47c14 -[NSNotificationCenter
postNotificationName:object:] + 24
28 UIKit 0x3741c26a -[UIApplication
_performMemoryWarning] + 74
29 UIKit 0x3741c364 -[UIApplication
_receivedMemoryNotification] + 168
30 libdispatch.dylib 0x319cf2da _dispatch_source_invoke + 510
31 libdispatch.dylib 0x319ccb7a
_dispatch_queue_invoke$VARIANT$mp + 46
32 libdispatch.dylib 0x319cceba
_dispatch_main_queue_callback_4CF$VARIANT$mp + 150
33 CoreFoundation 0x36fc42a6 __CFRunLoopRun + 1262
34 CoreFoundation 0x36f4749e CFRunLoopRunSpecific + 294
35 CoreFoundation 0x36f47366 CFRunLoopRunInMode + 98
36 GraphicsServices 0x31029432 GSEventRunModal + 130
37 UIKit 0x37298e76 UIApplicationMain + 1074
38 MobileTestApp 0x007f5520 0x1000 + 8340768
René
Am 19. April 2012 13:28 schrieb Rolf Bjarne Kvinge <[email protected]>:
> Hi,
>
> On Thu, Apr 19, 2012 at 7:40 AM, René Ruppert <[email protected]
> > wrote:
>
>> Hi,
>>
>> We had this discussion before but even after refactoring all of my code
>> I'm still facing exceptions that tell me that there is no IntPtr
>> constructor for certain view controllers, but it was tried to be called on
>> a garbage collected object.
>>
>> The outcome of the last discussion was:
>> - One should not implement them
>> - but you can implement them
>> - implementing them will hide the true problem
>> - implementing them might lead to crashes in other places
>> - some developers however *always* implement them and never face any
>> problems
>
>
>> Currently I'm seeing the exceptions of the missing constructor totlally
>> random for the controllers that are shown as the pages of a
>> UiPageViewController, so really nothing fancy.
>>
>> Xamarin's opinion is (please correct if I'm wrong):
>> - I should face these issues mainly (if not even only) in the Simulator
>> because of constant GC
>> - The cause for the problems is the developer who is not holding
>> references.
>>
>
> Correct.
>
>
>> In my case I'm seeing the problems *only* on the device (Arm7, iPad 2 and
>> 3, Release or Debug, SGen) and never on the Simulator, even if I trigger
>> simulated memory warnings like crazy.
>> In the case of the UIPageViewController: what else can I do but return
>> the next or previous controller? Am I really supposed to keep an additional
>> referenced list of controllers?
>>
>
> The fact that it's only happening on devices changes things a (little)
> bit. Are these crashes easily reproducible? In that case I can have a look
> to see if I find out something.
>
>
>>
>> The UIPageViewController was only an example. There are other controllers
>> with similar problems (stupid UITableViewControllers that are not on screen
>> at all cause this exception minutes after being removed!). To some I added
>> the missing constructor and the issues a gone but I would really like to
>> understand more about this problem.
>>
>
> What happens when you add the "missing" ctor is that MonoTouch creates a
> new instance of the managed class when one is needed (and doesn't already
> exist). This means that any state you had in the GC'd instance, is lost.
> For instance:
>
> class CustomUITableViewController : UITableViewController {
> string someValue;
> public CustomUITablewViewController (IntPtr ptr) : base (ptr) {}
> }
>
> What you will experience is that the someValue field will randomly get
> nulled out (when one instance of the class is GC'ed and another one created
> in its place). "Randomly" here means between any function calls (such as
> between ViewWillAppear and ViewDidAppear).
>
> If you do not have class-level fields in your classes (or you do not care
> if those fields are randomly cleared out), it's safe to add the ctor.
>
> Rolf
>
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch
