Making a test case is not easy.  And this may actually be a SnowLeopard only
issue.  But I think I found the cause.  I have a bunch of these:
        public NSString Name
        {
            [ObjectiveCMessage("name")]
            get
            {
                return new NSString("name");
            }

And I had a few of these:
        public NSString Field
        {
            [ObjectiveCMessage("field")]
            get
            {
                return "field";
            }

I'm guessing the issue is autorelease/retain.  The implicit operator for
string to NSString does an autorelease.  Where new NSString(string) does
not.  So I changed the 2nd to also call new NSString() and the frequency of
the issue is reduced.  I am going through the code to make sure I do not
have other instances.  But the source object of the dealloc is very hard to
track down.

I still have the modified ObjectiveCRuntime.GetInstance, otherwise the app
will crash.

Now does this theory make sense?  And any suggestions on how to track down
the object that is being dealloced?

Thanks,
Duane


On Thu, Nov 26, 2009 at 2:51 AM, Laurent Etiemble <
laurent.etiem...@monobjc.net> wrote:

> Hello,
>
> Can you post a small test-case so we can investigate the issue ?
>
> Regards, Laurent Etiemble.
>
> 2009/11/18 Duane Wandless <du...@wandless.net>:
> > I am getting the full call stack below when running, on SL and Leopard.
> > Using 2.4.2.3 and Monobjc 2.0.413.0.  Now I'm pretty confident this is a
> > terrible solution I found.  Any suggestions on how I can address this
> > correctly would be greatly appreciated.
> >
> > I traced the workaround to NSProxy.Dealloc().  I added:
> > if (this == null)
> >   return;
> > And adding the check (see below) on cls.Name == "Proxy" to
> > ObjectiveCRuntime.GetInstance(IntPtr, bool).
> >
> > Then the crash no longer occurs.  But this does not resolve why 'this' is
> > null when Dealloc is being called nor why an object of NSProxy is being
> > referenced in GetInstance.
> >
> > I added logging to ObjectiveCRuntime.GetInstance(IntPtr, bool) as well as
> > the return null if class name is "NSProxy".
> >
> >                             // If no match, try to see if there is an
> > inheritance relationship
> >                             if (result == default(TClass))
> >                             {
> >                                 Class cls = Class.GetClassFromType(typeof
> > (TClass));
> >                                 Console.WriteLine("Monobjc class name:
> {0}
> > ip {1:X} {2}", cls.Name, value, canFail);
> >                                 if (cls.Name == "NSProxy")
> >                                     return null;
> >
> > I also added logging to Dealloc to print out what object is being
> > deallocated.  I see lots of this:
> >             Console.WriteLine("nativeptr {0:X} {1}", this.NativePointer,
> > this.Class.Name);
> >
> > nativeptr 398951232 _IKIRLMainProxy
> > nativeptr 402144384 _IKIRLMainProxy
> > nativeptr 402144400 _IKIRLMainProxy
> > nativeptr 402167744 _IKIRLMainProxy
> > nativeptr 398909232 _IKIRLMainProxy
> > nativeptr 398940800 _IKIRLMainProxy
> >
> > Whenever I alt-tab away from my window and come back this output streams
> for
> > hundreds of lines with every once in a while a reference to Dealloc
> having a
> > this pointer that is null.
> >
> > So some questions.  Should an NSProxy class ever be checked in
> GetInstance?
> > Is the constant Dealloc-ing of _IKIRLMainProxy expected?  Any ideas on
> how
> > this becomes null and then dealloc is called?
> >
> > thanks!
> > Duane
> >
> > Here is the call stack from C#.
> >
> > (gdb) p (char *)mono_pmip (0x058db27e)
> > $6 = 0x18128d90 " (wrapper managed-to-native)
> > Monobjc.ObjectiveCRuntime:isKindOfClass (intptr,intptr,intptr) + 0x2e
> > (0x58db250 0x58db2a4) [0x20bde58 - MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x03f0ef22)
> > $7 = 0x17196eb0 " Monobjc.ObjectiveCRuntime:GetInstance<object>
> > (intptr,bool) + 0x152 (0x3f0edd0 0x3f0f431) [0x20bde58 -
> MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x03f0edbf)
> > $8 = 0x1717f690 " Monobjc.ObjectiveCRuntime:GetInstance<object> (intptr)
> +
> > 0x27 (0x3f0ed98 0x3f0edc4) [0x20bde58 - MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x180c4eee)
> > $9 = 0x1812ccd0 " Monobjc.Dynamic.Proxies.Monobjc.Cocoa.NSProxy:Dealloc
> > (intptr,intptr) + 0x16 (0x180c4ed8 0x180c4eff) [0x20bde58 -
> > MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x03f017e6)
> > $10 = 0x1812c770 " (wrapper native-to-managed)
> > Monobjc.Dynamic.Proxies.Monobjc.Cocoa.NSProxy:Dealloc (intptr,intptr) +
> 0x2e
> > (0x3f017b8 0x3f017f2) [0x20bde58 - MacMonoClient.exe]"
> >
> > Monobjc class name: NSProxy ip 401881888 False
> > 2009-11-17 18:35:45.576 PIXFiles[11651:980b] An uncaught exception was
> > raised
> > 2009-11-17 18:35:45.577 PIXFiles[11651:980b] *** -[NSProxy
> > doesNotRecognizeSelector:isKindOfClass:] called!
> > 2009-11-17 18:35:45.579 PIXFiles[11651:980b] *** Terminating app due to
> > uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSProxy
> > doesNotRecognizeSelector:isKindOfClass:] called!'
> > *** Call stack at first throw:
> > (gdb) where
> > #0  0x9264fb07 in ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ ()
> > #1  0x94e1cf49 in objc_exception_throw ()
> > #2  0x926052b8 in +[NSException raise:format:arguments:] ()
> > #3  0x9260522a in +[NSException raise:format:] ()
> > #4  0x96a42b51 in -[NSProxy doesNotRecognizeSelector:] ()
> > #5  0x925ad026 in ___forwarding___ ()
> > #6  0x925acbf2 in __forwarding_prep_0___ ()
> > #7  0x96a43040 in -[NSProxy isKindOfClass:] ()
> > #8  0x058db27e in ?? ()
> > #9  0x03f0ef22 in ?? ()
> > #10 0x03f0edbf in ?? ()
> > #11 0x180c4eee in ?? ()
> > #12 0x03f017e6 in ?? ()
> > #13 0x90014f2e in -[_IKIRLMainProxy dealloc] ()
> > #14 0x9253f9d8 in CFRelease ()
> > #15 0x9256c5bd in _CFAutoreleasePoolPop ()
> > #16 0x9690be62 in NSPopAutoreleasePool ()
> > #17 0x9690bd8a in -[NSAutoreleasePool drain] ()
> > #18 0x900cbdea in -[IKTaskManager taskLoop] ()
> > #19 0x9691e964 in -[NSThread main] ()
> > #20 0x9691e914 in __NSThread__main__ ()
> > #21 0x90468f39 in _pthread_start ()
> > #22 0x90468dbe in thread_start ()
> >
>

Reply via email to