Hello,
I have found a case that looks close to what you have reported: when a
NSDistantObject instance gets deallocated, the bridge's lookup fails because
the instance does not responds to "isKindOfClass:" selector. I have
encountered it while working on the Growl Framework integration.
I have been able to produce a work-around, so I will keep you posted on it.
Regards, Laurent Etiemble.
2009/12/10 Duane Wandless <du...@wandless.net>
> 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 ()
>> >
>>
>
>
