Re: WTF is happening?

[Maxthon Chan]

So, what you suggest is that build an XPC service that starts when a format 
engine is called for, loads all plugins, scan them for formats using class 
walking, handle the method using XPC, and terminate once the format engine is 
done?

> On Dec 17, 2014, at 03:38, Uli Kusterer  wrote:
> 
> On 15 Dec 2014, at 19:19, Maxthon Chan  wrote:
>> My current design is that the main code is never possible of holding strong 
>> references to plugin code for extended periods. Main code keeps an eye on a 
>> folder and whenever a new bundle is dropped in it is loaded, and whenever a 
>> bundle is removed code is unloaded. Class walking is used to detect the 
>> classes loaded. Also, SKFormat does not have any instance methods, only 
>> class methods, just to prevent any autorelease pool holding onto it.
> 
> That's not enough. For instance, any constant strings in your plug-in get 
> unloaded, whether someone outside it still has a reference to that string or 
> not. I think there's a flag to avoid constant strings when building a plugin, 
> but AFAIK there are other reasons that cause similar issues.
> 
> Have you thought about making your plug-ins separate processes that 
> communicate via pipes or Mach messages or similar mechanisms?



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Uli Kusterer]

On 15 Dec 2014, at 13:42, Jean-Daniel Dupas  wrote:
>> Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, 
>> simply has each image representation subclass add itself to an NSArray from 
>> its +initialize method. I'd think that'd be less fragile than walking the 
>> entire class list.
> 
> I fully agree on that. Relying on class iteration is generally a design flaw. 
> It is too fragile to be used in a reliable and futur proof way.
> But I don’t think you can rely on +initialize to register subclasses as 
> initialize will not be called until the someone try to use the target class 
> (or one of it’s subclass).

Doh! You're right! I mixed up +initialize and +load here.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Uli Kusterer]

On 15 Dec 2014, at 19:19, Maxthon Chan  wrote:
> My current design is that the main code is never possible of holding strong 
> references to plugin code for extended periods. Main code keeps an eye on a 
> folder and whenever a new bundle is dropped in it is loaded, and whenever a 
> bundle is removed code is unloaded. Class walking is used to detect the 
> classes loaded. Also, SKFormat does not have any instance methods, only class 
> methods, just to prevent any autorelease pool holding onto it.

 That's not enough. For instance, any constant strings in your plug-in get 
unloaded, whether someone outside it still has a reference to that string or 
not. I think there's a flag to avoid constant strings when building a plugin, 
but AFAIK there are other reasons that cause similar issues.

 Have you thought about making your plug-ins separate processes that 
communicate via pipes or Mach messages or similar mechanisms?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Britt Durbrow]

> In this case you have found that the implementation of +[_NSObjectAnimator 
> resolveInstanceMethod:] crashes. 

IMHO, this is a nasty little bug… and a simple test case should be added to the 
frameworks to check that basic runtime functionality works on all classes - 
private or publicly declared. Even if nothing else is guaranteed, if a thing 
says it’s a class, then it really kinda’ should act like one.

> In general it is not safe to look up arbitrary classes and then send messages 
> to them.

True. However, he called a C runtime function… it happens that that function 
invokes the forwarding mechanism, but it’s still a basic runtime C function, 
below the level of the NSObject abstractions… so it really *should* work...

> Checking for conformance (using the C function, not the NSObject method) to a 
> protocol you defined and then only sending messages from that protocol is the 
> safest way to go.

I would (and in my own code, do) combine that with the suggestions to 
interrogate the bundle being loaded for classes to be examined, as well as do 
registration of classes in +load… I also post some notifications of my own at 
various key points in my app startup cycle that various interested classes can 
hook to.

> On Dec 15, 2014, at 3:36 PM, Maxthon Chan  wrote:
> 
> I ended up written my own runtime-level equivalent of +[NSObject 
> isSubclassOfClass:] using only class_getSuperclass and object_getClass. This 
> class scanning code, currently used for plugin scanning, will also be used in 
> jailbreak detecting, defeating Cydia Substrate-based iAP crackers.

You need to be very careful of how you implement that so that a future OS 
update doesn’t break your app…


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

I ended up written my own runtime-level equivalent of +[NSObject 
isSubclassOfClass:] using only class_getSuperclass and object_getClass. This 
class scanning code, currently used for plugin scanning, will also be used in 
jailbreak detecting, defeating Cydia Substrate-based iAP crackers.

> On Dec 16, 2014, at 06:25, Wim Lewis  wrote:
> 
> 
> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
>> What I am doing here is scanning all loaded classes for subclasses of a 
>> certain class. Before any NSObject method can be issued I have to check if 
>> it is actually NSObject or NSProxy derivative instead of an Object 
>> derivative that does not support NSObject methods. This calls for runtime 
>> equivalent for one of the following NSObject methods:
> 
> For what it’s worth we’ve run into this same problem at Omni— we have some 
> code (that runs in debug builds, but not release builds, IIRC) that scans the 
> class hierarchy. We simply ignore a bunch of classes that we’ve had problems 
> with. This works, but it’s a little bit brittle because who knows when 
> another class will appear in the runtime that can’t handle 
> -respondsToSelector: and break your shipping application.
> 
> 
>>/* Some classes (that aren't our problem) asplode when they try to 
>> dynamically create getters/setters. */
>>const char *clsName = class_getName(cls);
>>if (CLASSNAME_HAS_PREFIX(clsName, "NS") ||
>>CLASSNAME_HAS_PREFIX(clsName, "_NS") ||
>>CLASSNAME_HAS_PREFIX(clsName, "__NS") ||
>>CLASSNAME_HAS_PREFIX(clsName, "__CF") ||
>>CLASSNAME_HAS_PREFIX(clsName, "CA") ||
>>CLASSNAME_HAS_PREFIX(clsName, "_CN") ||
>>CLASSNAME_HAS_PREFIX(clsName, "VGL") ||
>>CLASSNAME_HAS_PREFIX(clsName, "VK") ||
>>strcmp(clsName, "DRDevice") == 0) {
>>/* In particular, _NS[View]Animator chokes in this case. But we 
>> don't really need to check any _NS classes. */
>>continue;
>>}
> 
> 
> On Dec 15, 2014, at 10:23 AM, David Duncan  wrote:
>> And also, if you are loading the bundle, then again there is little need to 
>> do actual class walking as such, since you are in control of the bundle and 
>> its formatting. Require the bundles to tell you the classes that are 
>> SKFormat subclasses in the bundle’s property list and only use those.
> 
> IMHO this is the best approach to the problem.
> 
> Another approach is you could watch for the NSBundleDidLoadNotification and 
> only scan the classes in the NSLoadedClasses entry. But I think that 
> requiring the plugin to explicitly list the classes you should scan in its 
> Info.plist is a good approach.
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Wim Lewis]

On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
> What I am doing here is scanning all loaded classes for subclasses of a 
> certain class. Before any NSObject method can be issued I have to check if it 
> is actually NSObject or NSProxy derivative instead of an Object derivative 
> that does not support NSObject methods. This calls for runtime equivalent for 
> one of the following NSObject methods:

For what it’s worth we’ve run into this same problem at Omni— we have some code 
(that runs in debug builds, but not release builds, IIRC) that scans the class 
hierarchy. We simply ignore a bunch of classes that we’ve had problems with. 
This works, but it’s a little bit brittle because who knows when another class 
will appear in the runtime that can’t handle -respondsToSelector: and break 
your shipping application.


> /* Some classes (that aren't our problem) asplode when they try to 
> dynamically create getters/setters. */
> const char *clsName = class_getName(cls);
> if (CLASSNAME_HAS_PREFIX(clsName, "NS") ||
> CLASSNAME_HAS_PREFIX(clsName, "_NS") ||
> CLASSNAME_HAS_PREFIX(clsName, "__NS") ||
> CLASSNAME_HAS_PREFIX(clsName, "__CF") ||
> CLASSNAME_HAS_PREFIX(clsName, "CA") ||
> CLASSNAME_HAS_PREFIX(clsName, "_CN") ||
> CLASSNAME_HAS_PREFIX(clsName, "VGL") ||
> CLASSNAME_HAS_PREFIX(clsName, "VK") ||
> strcmp(clsName, "DRDevice") == 0) {
> /* In particular, _NS[View]Animator chokes in this case. But we 
> don't really need to check any _NS classes. */
> continue;
> }


On Dec 15, 2014, at 10:23 AM, David Duncan  wrote:
> And also, if you are loading the bundle, then again there is little need to 
> do actual class walking as such, since you are in control of the bundle and 
> its formatting. Require the bundles to tell you the classes that are SKFormat 
> subclasses in the bundle’s property list and only use those.

IMHO this is the best approach to the problem.

Another approach is you could watch for the NSBundleDidLoadNotification and 
only scan the classes in the NSLoadedClasses entry. But I think that requiring 
the plugin to explicitly list the classes you should scan in its Info.plist is 
a good approach.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Jean-Daniel Dupas]

> Le 15 déc. 2014 à 21:36, Greg Parker  a écrit :
> 
> 
>> On Dec 15, 2014, at 11:02 AM, Jean-Daniel Dupas  wrote:
>> 
>>> Le 15 déc. 2014 à 19:45, Fritz Anderson  a écrit :
>>> 
>>> - As is typical of ObjC plugins, the classes are packaged in a dynamic 
>>> library; and as is typical, the library is wrapped in a package directory, 
>>> which your application has registered with Launch Services as a package, of 
>>> a certain type and edit/view/associate relationship to your application. 
>>> I'm sure this is so in your case, as plugins typically need to carry 
>>> resource files.
>> 
>> Just for the record, typical Obj-C plugins are packaged in loadable bundle 
>> (MH_BUNDLE), which are a different binary object kind than dynamic library 
>> (MH_DYLIB).
> 
> MH_BUNDLE is no longer typical. The only advantage of MH_BUNDLE is that you 
> might be able to unload it, but you probably shouldn't try. Feel free to use 
> MH_DYLIB for all of your plugin needs.

It is typical in the sense that Xcode defaults to mach-o type bundle when 
creating a plugin project and most (if not all) Apple provided plugins are 
bundle (as are most third party plugins).

> (libobjc prevents unloading of any MH_DYLIB containing Objective-C metadata. 
> It does not summarily disallow unloading of MH_BUNDLE, but there's a long 
> list of caveats that make bundle unloading unusable except in rare 
> situations.)



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Greg Parker]

> On Dec 13, 2014, at 7:20 AM, Maxthon Chan  wrote:
> 
> This got me scratching my head, hard. Why would class_respondsToSelector() 
> crash? (BTW this is used in a class search loop so I cannot use [NSObject 
> respondsToSelector:] just yet.)

Your evil runtime hack is colliding with someone else's evil runtime hack.

If a class does not have an implementation for some selector then the runtime 
asks the class if it would like to add one using +resolveInstanceMethod: or 
+resolveClassMethod:. In this case you have found that the implementation of 
+[_NSObjectAnimator resolveInstanceMethod:] crashes. (It turns out that 
_NSObjectAnimator assumes the message is only sent to its subclasses, not to 
_NSObjectAnimator itself.)

In general it is not safe to look up arbitrary classes and then send messages 
to them. Checking for conformance (using the C function, not the NSObject 
method) to a protocol you defined and then only sending messages from that 
protocol is the safest way to go. Filtering out classes with base classes that 
are not NSObject sometimes works. Filtering out classes whose names start with 
"_" sometimes works.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Greg Parker]

> On Dec 15, 2014, at 11:02 AM, Jean-Daniel Dupas  wrote:
> 
>> Le 15 déc. 2014 à 19:45, Fritz Anderson  a écrit :
>> 
>> - As is typical of ObjC plugins, the classes are packaged in a dynamic 
>> library; and as is typical, the library is wrapped in a package directory, 
>> which your application has registered with Launch Services as a package, of 
>> a certain type and edit/view/associate relationship to your application. I'm 
>> sure this is so in your case, as plugins typically need to carry resource 
>> files.
> 
> Just for the record, typical Obj-C plugins are packaged in loadable bundle 
> (MH_BUNDLE), which are a different binary object kind than dynamic library 
> (MH_DYLIB).

MH_BUNDLE is no longer typical. The only advantage of MH_BUNDLE is that you 
might be able to unload it, but you probably shouldn't try. Feel free to use 
MH_DYLIB for all of your plugin needs.

(libobjc prevents unloading of any MH_DYLIB containing Objective-C metadata. It 
does not summarily disallow unloading of MH_BUNDLE, but there's a long list of 
caveats that make bundle unloading unusable except in rare situations.)


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Jean-Daniel Dupas]

> Le 15 déc. 2014 à 19:45, Fritz Anderson  a écrit :
> 
> I can be dense. Do I understand correctly that
> 
> - You have an application that ideally should run continually.
> 
> - It accepts plugins that provide one or more classes.
> 
> - Those classes must at least observe a protocol; otherwise there would be no 
> sensible way to use them.
> 
> - They must have unique names.
> 
> - As is typical of ObjC plugins, the classes are packaged in a dynamic 
> library; and as is typical, the library is wrapped in a package directory, 
> which your application has registered with Launch Services as a package, of a 
> certain type and edit/view/associate relationship to your application. I'm 
> sure this is so in your case, as plugins typically need to carry resource 
> files.

Just for the record, typical Obj-C plugins are packaged in loadable bundle 
(MH_BUNDLE), which are a different binary object kind than dynamic library 
(MH_DYLIB).

> - If a package, the plugin might carry an Info.plist file — plugins commonly 
> do.
> 
> - You mean to load and unload plugins dynamically, as they appear and 
> disappear in a designated directory, without interrupting the application.
> 
> Do I follow you so far? If so, I have some comments.
> 
> You can't unscramble the egg: Dynamically-loaded classes can be loaded any 
> time you like, but they cannot be reloaded or unloaded. Surely you know this; 
> surely I misunderstand (or am behind the times).
> 
> If you are (practically) committed to a package structure with an Info.plist, 
> why can't you add an  key listing the names of the provided classes? 
> Or for that matter, a text file containing the names? That's one of the 
> things NSBundle is for. It is a universal practice. "Just works" is a great 
> ideal, but one can expect someone who knows how to build a dynamic library to 
> understand such things.
> 
> The declared classes might not implement the required methods, but that's 
> easy and safe to detect once they are loaded. If you must reject, your duty 
> ends when you log the problem and put up an alert.
> 
> Am I missing something?
> 
>— F
> 
> 
>> On Dec 15, 2014, at 11:59 AM, Maxthon Chan  wrote:
>> 
>> What I am doing here is to determine a format handling class based on file 
>> extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect 
>> and allow one plugin to include multiple format handling classes. Also since 
>> I am creating an open system I don’t want to require other plugin writers to 
>> register their classes, instead the main code shall discover plugins on its 
>> own.
>> 
>> This means that the main code will not be able to call any plugin classes 
>> methods so +initialize never get called. Also your approach means that the 
>> main code will hold a strong reference to the plugin code which prevents 
>> plugin unloading.
>> 
>> Class walking may be fragile, but it is fragile enough to allow plugins to 
>> come and go easily without having to restart the main code.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Fritz Anderson]

I can be dense. Do I understand correctly that

- You have an application that ideally should run continually.

- It accepts plugins that provide one or more classes.

- Those classes must at least observe a protocol; otherwise there would be no 
sensible way to use them.

- They must have unique names.

- As is typical of ObjC plugins, the classes are packaged in a dynamic library; 
and as is typical, the library is wrapped in a package directory, which your 
application has registered with Launch Services as a package, of a certain type 
and edit/view/associate relationship to your application. I'm sure this is so 
in your case, as plugins typically need to carry resource files.

- If a package, the plugin might carry an Info.plist file — plugins commonly do.

- You mean to load and unload plugins dynamically, as they appear and disappear 
in a designated directory, without interrupting the application.

Do I follow you so far? If so, I have some comments.

You can't unscramble the egg: Dynamically-loaded classes can be loaded any time 
you like, but they cannot be reloaded or unloaded. Surely you know this; surely 
I misunderstand (or am behind the times).

If you are (practically) committed to a package structure with an Info.plist, 
why can't you add an  key listing the names of the provided classes? Or 
for that matter, a text file containing the names? That's one of the things 
NSBundle is for. It is a universal practice. "Just works" is a great ideal, but 
one can expect someone who knows how to build a dynamic library to understand 
such things.

The declared classes might not implement the required methods, but that's easy 
and safe to detect once they are loaded. If you must reject, your duty ends 
when you log the problem and put up an alert.

Am I missing something?

— F


> On Dec 15, 2014, at 11:59 AM, Maxthon Chan  wrote:
> 
> What I am doing here is to determine a format handling class based on file 
> extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect 
> and allow one plugin to include multiple format handling classes. Also since 
> I am creating an open system I don’t want to require other plugin writers to 
> register their classes, instead the main code shall discover plugins on its 
> own.
> 
> This means that the main code will not be able to call any plugin classes 
> methods so +initialize never get called. Also your approach means that the 
> main code will hold a strong reference to the plugin code which prevents 
> plugin unloading.
> 
> Class walking may be fragile, but it is fragile enough to allow plugins to 
> come and go easily without having to restart the main code.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[David Duncan]

And if you have a constant NSString in the binary, and that string is 
referenced anywhere in the application, then unloading the binary will crash 
the next time that constant string is referenced.

It is *really* hard to make a properly un-loadable bundle and generally 
in-advised, as the advantages tend to be non-existant compared to the effort 
required.

And also, if you are loading the bundle, then again there is little need to do 
actual class walking as such, since you are in control of the bundle and its 
formatting. Require the bundles to tell you the classes that are SKFormat 
subclasses in the bundle’s property list and only use those.

> On Dec 15, 2014, at 10:19 AM, Maxthon Chan  wrote:
> 
> My current design is that the main code is never possible of holding strong 
> references to plugin code for extended periods. Main code keeps an eye on a 
> folder and whenever a new bundle is dropped in it is loaded, and whenever a 
> bundle is removed code is unloaded. Class walking is used to detect the 
> classes loaded. Also, SKFormat does not have any instance methods, only class 
> methods, just to prevent any autorelease pool holding onto it.
> 
>> On Dec 16, 2014, at 02:09, David Duncan > > wrote:
>> 
>> 
>>> On Dec 15, 2014, at 9:59 AM, Maxthon Chan >> > wrote:
>>> 
>>> I do own the entire SubtitleKit framework but the problem is I want it 
>>> allow loading and unloading format plugins without restarting the host 
>>> application. This library only have one internal parser for basic SubRip 
>>> format and plugins are used for styled SubRip, Multi-track SubRip, 
>>> SubStation Alpha and other formats.
>> 
>> 
>> You can post a notification when a format plugin loads (aka registers 
>> itself) for those that are interested in knowing that new formats are 
>> available.
>> 
>> As for unloading, unloading Objective-C code is generally considered 
>> difficult at best, especially since it is often hard to control whom is 
>> referencing any content in the binary (and where once you’ve unloaded that 
>> bundle anyone referencing that code will crash).
>> 
>> Overall the simplest solution seems to be that your SubtitleKit framework 
>> provides a method for loading these format plugins and does the registration 
>> itself. Your users always use that method and you don’t have any of these 
>> problems.
>> --
>> David Duncan
>> 
> 

--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

My current design is that the main code is never possible of holding strong 
references to plugin code for extended periods. Main code keeps an eye on a 
folder and whenever a new bundle is dropped in it is loaded, and whenever a 
bundle is removed code is unloaded. Class walking is used to detect the classes 
loaded. Also, SKFormat does not have any instance methods, only class methods, 
just to prevent any autorelease pool holding onto it.

> On Dec 16, 2014, at 02:09, David Duncan  wrote:
> 
> 
>> On Dec 15, 2014, at 9:59 AM, Maxthon Chan > > wrote:
>> 
>> I do own the entire SubtitleKit framework but the problem is I want it allow 
>> loading and unloading format plugins without restarting the host 
>> application. This library only have one internal parser for basic SubRip 
>> format and plugins are used for styled SubRip, Multi-track SubRip, 
>> SubStation Alpha and other formats.
> 
> 
> You can post a notification when a format plugin loads (aka registers itself) 
> for those that are interested in knowing that new formats are available.
> 
> As for unloading, unloading Objective-C code is generally considered 
> difficult at best, especially since it is often hard to control whom is 
> referencing any content in the binary (and where once you’ve unloaded that 
> bundle anyone referencing that code will crash).
> 
> Overall the simplest solution seems to be that your SubtitleKit framework 
> provides a method for loading these format plugins and does the registration 
> itself. Your users always use that method and you don’t have any of these 
> problems.
> --
> David Duncan
> 



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[David Duncan]

> On Dec 15, 2014, at 9:59 AM, Maxthon Chan  wrote:
> 
> I do own the entire SubtitleKit framework but the problem is I want it allow 
> loading and unloading format plugins without restarting the host application. 
> This library only have one internal parser for basic SubRip format and 
> plugins are used for styled SubRip, Multi-track SubRip, SubStation Alpha and 
> other formats.


You can post a notification when a format plugin loads (aka registers itself) 
for those that are interested in knowing that new formats are available.

As for unloading, unloading Objective-C code is generally considered difficult 
at best, especially since it is often hard to control whom is referencing any 
content in the binary (and where once you’ve unloaded that bundle anyone 
referencing that code will crash).

Overall the simplest solution seems to be that your SubtitleKit framework 
provides a method for loading these format plugins and does the registration 
itself. Your users always use that method and you don’t have any of these 
problems.
--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

What I am doing here is to determine a format handling class based on file 
extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect 
and allow one plugin to include multiple format handling classes. Also since I 
am creating an open system I don’t want to require other plugin writers to 
register their classes, instead the main code shall discover plugins on its own.

This means that the main code will not be able to call any plugin classes 
methods so +initialize never get called. Also your approach means that the main 
code will hold a strong reference to the plugin code which prevents plugin 
unloading.

Class walking may be fragile, but it is fragile enough to allow plugins to come 
and go easily without having to restart the main code.

> On Dec 15, 2014, at 20:42, Jean-Daniel Dupas  wrote:
> 
> 
>> Le 15 déc. 2014 à 13:31, Uli Kusterer  a écrit 
>> :
>> 
>> On 15 Dec 2014, at 12:42, Jean-Daniel Dupas  wrote:
>>> I found only 5 classes that does not responds to isProxy and they are all 
>>> internal classes, so real code will never have to deal with instances of 
>>> such classes.
>> 
>> Maxthon is iterating over the classes in the system. Even internal classes 
>> to the OS show up in that list, so I really don't see how he would *not* 
>> have to be able to at least deal with their presence.
>> 
> 
> Fair enough, but I didn’t got any issue while dealing with theses classes. I 
> managed to query if they responds to a selector, got there superclass and 
> more.
> 
>> Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, 
>> simply has each image representation subclass add itself to an NSArray from 
>> its +initialize method. I'd think that'd be less fragile than walking the 
>> entire class list.
> 
> I fully agree on that. Relying on class iteration is generally a design flaw. 
> It is too fragile to be used in a reliable and futur proof way.
> But I don’t think you can rely on +initialize to register subclasses as 
> initialize will not be called until the someone try to use the target class 
> (or one of it’s subclass).
> 
> You can use +load but should probably be careful when doing so as there is no 
> guarantee about the class loading order AFAIK. 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[David Duncan]

> On Dec 13, 2014, at 7:20 AM, Maxthon Chan  wrote:
> 
> This got me scratching my head, hard. Why would class_respondsToSelector() 
> crash? (BTW this is used in a class search loop so I cannot use [NSObject 
> respondsToSelector:] just yet.)
> 
> /Users/technix/Developer/Subtitler 
> Pro/Frameworks/SubtitleKit/SubtitleKitTests/SKSubripParseTest.m:33: error: 
> -[SKSubripParseTest testFileFormatSearch] : failed: caught 
> "NSRangeException", "*** -[__NSCFString substringFromIndex:]: Index 18 out of 
> bounds; string length 17"
> (
>   0   CoreFoundation  0x7fff926c 
> __exceptionPreprocess + 172
>   1   libobjc.A.dylib 0x7fff8725976e 
> objc_exception_throw + 43
>   2   CoreFoundation  0x7fff9266651d 
> +[NSException raise:format:] + 205
>   3   Foundation  0x7fff8f127b2e -[NSString 
> substringFromIndex:] + 118
>   4   AppKit  0x7fff8a4e1c49 
> +[_NSObjectAnimator _targetClass] + 92
>   5   AppKit  0x7fff8a4e1b79 
> +[_NSObjectAnimator resolveInstanceMethod:] + 34
>   6   libobjc.A.dylib 0x7fff8725c954 
> _ZL28_class_resolveInstanceMethodP10objc_classP13objc_selectorP11objc_object 
> + 80

From this call stack it looks like you are tripping over an internal 
implementation detail of AppKit in a way that is not expected. In particular, 
+[_NSObjectAnimator _targetClass] (an internal class) is calling -[NSString 
substringFromIndex:] and passing an invalid index, probably due to some 
implementation detail that your code is violating. Given you are inside 
+resolveInstanceMethod:, my guess would be that by trying to dynamically look 
up the instance method, you are tripping over code that determines where to get 
that instance method from that doesn’t expect to be called on the raw 
_NSObjectAnimator.

My minimal recommendation would be to filter out all classes that begin with an 
“_” prefix from your scan. But I would be curious as to why you need to know 
the subclass information up front and not just as you encounter particular 
classes (granted this is for a test it seems, but it seems like it would be 
prudent to reduce your test to a more reasonable scope).

>   7   libobjc.A.dylib 0x7fff87262799 
> lookUpImpOrForward + 356
>   8   libobjc.A.dylib 0x7fff87262617 
> lookUpImpOrNil + 20
>   9   libobjc.A.dylib 0x7fff872545ff 
> class_respondsToSelector + 37
>   10  SubtitleKit 0x0001000d02c8 +[SKFormat 
> formatEngineForExtension:] + 184
>   11  SubtitleKitTests0x00010008551e 
> -[SKSubripParseTest testFileFormatSearch] + 142
>   12  CoreFoundation  0x7fff9253f3cc 
> __invoking___ + 140
>   13  CoreFoundation  0x7fff9253f222 
> -[NSInvocation invoke] + 290
>   14  XCTest  0x000100097919 -[XCTestCase 
> invokeTest] + 253
>   15  XCTest  0x000100097b1a -[XCTestCase 
> performTest:] + 150
>   16  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   17  XCTest  0x00010009682b 
> -[XCTestSuite performTest:] + 379
>   18  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   19  XCTest  0x00010009682b 
> -[XCTestSuite performTest:] + 379
>   20  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   21  XCTest  0x00010009682b 
> -[XCTestSuite performTest:] + 379
>   22  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   23  XCTest  0x00010009383c 
> __25-[XCTestDriver _runSuite]_block_invoke + 56
>   24  XCTest  0x00010009f36d 
> -[XCTestObservationCenter _observeTestExecutionForBlock:] + 162
>   25  XCTest  0x000100093770 
> -[XCTestDriver _runSuite] + 269
>   26  XCTest  0x000100094359 
> -[XCTestDriver _checkForTestManager] + 678
>   27  XCTest  0x0001000a35b0 
> +[XCTestProbe runTests:] + 182
>   28  xctest  0x00011256 xctest + 4694
>   29  xctest  0x000115d6 xctest + 5590
>   30  xctest  0x00010ed3 xctest + 3795
>   31  libdyld.dylib   0x7fff90e315c9 start + 1
> )
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moder

Re: WTF is happening?

[Jean-Daniel Dupas]

bool isSubclass(Class cls, Class superclass) {
if (class_respondsToSelector(object_getClass(cls), 
@selector(isSubclassOfClass:))) {
return [cls isSubclassOfClass:superclass];
}
}

> Le 15 déc. 2014 à 16:49, Maxthon Chan  a écrit :
> 
> But I still need some way to tell them from NSObject/NSProxy decedents from 
> my class walking. Any method calling will cause a crash there.
> 
>> On Dec 15, 2014, at 23:48, Clark S. Cox III  wrote:
>> 
>> That does not mean that they're using "Object" only that they're using a 
>> base class other than "NSObject" or "NSProxy". Why can't you just ignore 
>> such classes?
>> 
>> Sent from my iPhone
>> 
>> On Dec 14, 2014, at 23:31, Maxthon Chan > > wrote:
>> 
>>> My class scanning returned several OS* classes that does not conform to 
>>> NSObject protocol.
>>> 
 On Dec 15, 2014, at 00:29, Clark S. Cox III >>> > wrote:
 
> 
> On Dec 13, 2014, at 11:57, Maxthon Chan  > wrote:
> 
> NSProxy checking actually work, but throwing those classes that derive 
> from Object class (note I used capitalised O here, the old Object class 
> from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
> ports)
 
 What makes you think that Object is used in *any* of those places?
 
> into the mix means that no method can be sent before class is determined. 
> I would suggest Apple add one runtime function class_isSubclassOfClass() 
> that mirrors the functionality of NSObject and NSProxy method 
> isSubclassOfClass so that derivatives of the old Object class can be 
> detected more easily.
> 
>> On Dec 14, 2014, at 03:49, Gary L. Wade > > wrote:
>> 
>> Are you saying that Apple's well-documented approach to see if an object 
>> is derived from NSProxy does not work? If that's the case, you need to 
>> submit a bug report to Apple. That's a serious issue that only Apple can 
>> help you with.
>> 
>> If you are using objects not derived from NSObject nor NSProxy, then 
>> change your design.
>> --
>> Gary L. Wade (Sent from my iPad)
>> http://www.garywade.com/ 
>> 
>>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan >> > wrote:
>>> 
>>> Ain’t work! Will crash if an Object derivative showed up.
>>> 
>>> I am scanning ALL loaded classes and only subclasses of a certain class 
>>> is interested. But due to the nature of this class scanning before I 
>>> can make sure that the class derives from NSObject I cannot call any 
>>> method on it.
>>> 
 On Dec 14, 2014, at 03:34, Gary L. Wade >>> > wrote:
 
 If all you care about is if an object is a proxy or not, look at 
 isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/ 
 
> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  > wrote:
> 
> What I am doing here is scanning all loaded classes for subclasses of 
> a certain class. Before any NSObject method can be issued I have to 
> check if it is actually NSObject or NSProxy derivative instead of an 
> Object derivative that does not support NSObject methods. This calls 
> for runtime equivalent for one of the following NSObject methods:
> 
> - [NSObject respondsToSelector:(SEL)aSelector] = 
> class_respondsToSelector(Class, SEL) // this crashed.
> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
> class_conformsToProtocol(Class, Protocol *) // check for NSObject 
> protocol, this does not work.
> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have 
> to implement it myself
> 
> I ended up creating this:
> 
> BOOL class_isSubclassOfClass(Class cls, Class other)
> {
> for (Class c = cls; c; c = class_getSuperclass(c))
>  if (c == other)
>  return YES;
> return NO;
> }
> 
> If i remembered it right GNUstep runtime have this function. I will 
> file a bug report to Apple and ask them to add this, as it is useful 
> in class scanning and i am using this technique heavily in jailbreak 
> detection.
> 
>> On Dec 14, 2014, at 01:20, Kyle Sluder > > wrote:
>> 
>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>>> Why do you think the problem is with “respondsToSelector:”?  The 
>>> error
>>> says you’re accessing past the end of a string.
>> 
>> Because the crash happens in a call stack 

Re: WTF is happening?

[Maxthon Chan]

But I still need some way to tell them from NSObject/NSProxy decedents from my 
class walking. Any method calling will cause a crash there.

> On Dec 15, 2014, at 23:48, Clark S. Cox III  wrote:
> 
> That does not mean that they're using "Object" only that they're using a base 
> class other than "NSObject" or "NSProxy". Why can't you just ignore such 
> classes?
> 
> Sent from my iPhone
> 
> On Dec 14, 2014, at 23:31, Maxthon Chan  > wrote:
> 
>> My class scanning returned several OS* classes that does not conform to 
>> NSObject protocol.
>> 
>>> On Dec 15, 2014, at 00:29, Clark S. Cox III >> > wrote:
>>> 
 
 On Dec 13, 2014, at 11:57, Maxthon Chan >>> > wrote:
 
 NSProxy checking actually work, but throwing those classes that derive 
 from Object class (note I used capitalised O here, the old Object class 
 from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
 ports)
>>> 
>>> What makes you think that Object is used in *any* of those places?
>>> 
 into the mix means that no method can be sent before class is determined. 
 I would suggest Apple add one runtime function class_isSubclassOfClass() 
 that mirrors the functionality of NSObject and NSProxy method 
 isSubclassOfClass so that derivatives of the old Object class can be 
 detected more easily.
 
> On Dec 14, 2014, at 03:49, Gary L. Wade  > wrote:
> 
> Are you saying that Apple's well-documented approach to see if an object 
> is derived from NSProxy does not work? If that's the case, you need to 
> submit a bug report to Apple. That's a serious issue that only Apple can 
> help you with.
> 
> If you are using objects not derived from NSObject nor NSProxy, then 
> change your design.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/ 
> 
>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan > > wrote:
>> 
>> Ain’t work! Will crash if an Object derivative showed up.
>> 
>> I am scanning ALL loaded classes and only subclasses of a certain class 
>> is interested. But due to the nature of this class scanning before I can 
>> make sure that the class derives from NSObject I cannot call any method 
>> on it.
>> 
>>> On Dec 14, 2014, at 03:34, Gary L. Wade >> > wrote:
>>> 
>>> If all you care about is if an object is a proxy or not, look at 
>>> isProxy.
>>> --
>>> Gary L. Wade (Sent from my iPad)
>>> http://www.garywade.com/ 
>>> 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan >>> > wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of 
 a certain class. Before any NSObject method can be issued I have to 
 check if it is actually NSObject or NSProxy derivative instead of an 
 Object derivative that does not support NSObject methods. This calls 
 for runtime equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
   if (c == other)
   return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will 
 file a bug report to Apple and ask them to add this, as it is useful 
 in class scanning and i am using this technique heavily in jailbreak 
 detection.
 
> On Dec 14, 2014, at 01:20, Kyle Sluder  > wrote:
> 
> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>> Why do you think the problem is with “respondsToSelector:”?  The 
>> error
>> says you’re accessing past the end of a string.
> 
> Because the crash happens in a call stack that originates in
> class_respondsToSelector, and involves none of Maxthon's code.
> 
> --Kyle Sluder
>> 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
 )
 
 Please do not post admin requests or moderator comments to the list.
>>

Re: WTF is happening?

[Clark S. Cox III]

That does not mean that they're using "Object" only that they're using a base 
class other than "NSObject" or "NSProxy". Why can't you just ignore such 
classes?

Sent from my iPhone

> On Dec 14, 2014, at 23:31, Maxthon Chan  wrote:
> 
> My class scanning returned several OS* classes that does not conform to 
> NSObject protocol.
> 
>>> On Dec 15, 2014, at 00:29, Clark S. Cox III  wrote:
>>> 
>>> 
>>> On Dec 13, 2014, at 11:57, Maxthon Chan  wrote:
>>> 
>>> NSProxy checking actually work, but throwing those classes that derive from 
>>> Object class (note I used capitalised O here, the old Object class from 
>>> early NeXT times, also used heavily in OS X kernel, GCD and Mach ports)
>> 
>> What makes you think that Object is used in *any* of those places?
>> 
>>> into the mix means that no method can be sent before class is determined. I 
>>> would suggest Apple add one runtime function class_isSubclassOfClass() that 
>>> mirrors the functionality of NSObject and NSProxy method isSubclassOfClass 
>>> so that derivatives of the old Object class can be detected more easily.
>>> 
 On Dec 14, 2014, at 03:49, Gary L. Wade  
 wrote:
 
 Are you saying that Apple's well-documented approach to see if an object 
 is derived from NSProxy does not work? If that's the case, you need to 
 submit a bug report to Apple. That's a serious issue that only Apple can 
 help you with.
 
 If you are using objects not derived from NSObject nor NSProxy, then 
 change your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
> On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
> 
> Ain’t work! Will crash if an Object derivative showed up.
> 
> I am scanning ALL loaded classes and only subclasses of a certain class 
> is interested. But due to the nature of this class scanning before I can 
> make sure that the class derives from NSObject I cannot call any method 
> on it.
> 
>> On Dec 14, 2014, at 03:34, Gary L. Wade  
>> wrote:
>> 
>> If all you care about is if an object is a proxy or not, look at isProxy.
>> --
>> Gary L. Wade (Sent from my iPad)
>> http://www.garywade.com/
>> 
>>> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
>>> 
>>> What I am doing here is scanning all loaded classes for subclasses of a 
>>> certain class. Before any NSObject method can be issued I have to check 
>>> if it is actually NSObject or NSProxy derivative instead of an Object 
>>> derivative that does not support NSObject methods. This calls for 
>>> runtime equivalent for one of the following NSObject methods:
>>> 
>>> - [NSObject respondsToSelector:(SEL)aSelector] = 
>>> class_respondsToSelector(Class, SEL) // this crashed.
>>> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
>>> class_conformsToProtocol(Class, Protocol *) // check for NSObject 
>>> protocol, this does not work.
>>> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
>>> implement it myself
>>> 
>>> I ended up creating this:
>>> 
>>> BOOL class_isSubclassOfClass(Class cls, Class other)
>>> {
>>> for (Class c = cls; c; c = class_getSuperclass(c))
>>>   if (c == other)
>>>   return YES;
>>> return NO;
>>> }
>>> 
>>> If i remembered it right GNUstep runtime have this function. I will 
>>> file a bug report to Apple and ask them to add this, as it is useful in 
>>> class scanning and i am using this technique heavily in jailbreak 
>>> detection.
>>> 
 On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
 
> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
> Why do you think the problem is with “respondsToSelector:”? The error
> says you’re accessing past the end of a string.
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
>>> 
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com
>>> 
>>> This email sent to clarkc...@gmail.com
> 


smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Jean-Daniel Dupas]

> Le 15 déc. 2014 à 13:31, Uli Kusterer  a écrit :
> 
> On 15 Dec 2014, at 12:42, Jean-Daniel Dupas  wrote:
>> I found only 5 classes that does not responds to isProxy and they are all 
>> internal classes, so real code will never have to deal with instances of 
>> such classes.
> 
> Maxthon is iterating over the classes in the system. Even internal classes to 
> the OS show up in that list, so I really don't see how he would *not* have to 
> be able to at least deal with their presence.
> 

Fair enough, but I didn’t got any issue while dealing with theses classes. I 
managed to query if they responds to a selector, got there superclass and more.

> Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, 
> simply has each image representation subclass add itself to an NSArray from 
> its +initialize method. I'd think that'd be less fragile than walking the 
> entire class list.

I fully agree on that. Relying on class iteration is generally a design flaw. 
It is too fragile to be used in a reliable and futur proof way.
But I don’t think you can rely on +initialize to register subclasses as 
initialize will not be called until the someone try to use the target class (or 
one of it’s subclass).

You can use +load but should probably be careful when doing so as there is no 
guarantee about the class loading order AFAIK. 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Uli Kusterer]

On 15 Dec 2014, at 12:42, Jean-Daniel Dupas  wrote:
> I found only 5 classes that does not responds to isProxy and they are all 
> internal classes, so real code will never have to deal with instances of such 
> classes.

Maxthon is iterating over the classes in the system. Even internal classes to 
the OS show up in that list, so I really don't see how he would *not* have to 
be able to at least deal with their presence.

Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, simply 
has each image representation subclass add itself to an NSArray from its 
+initialize method. I'd think that'd be less fragile than walking the entire 
class list.

-- Uli
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Jean-Daniel Dupas]

I found only 5 classes that does not responds to isProxy and they are all 
internal classes, so real code will never have to deal with instances of such 
classes.

And all classes prefixed by « OS_ » inherits NSObject and responds to isProxy. 

I run the experiment for myself and do not doubt the result.

> Le 15 déc. 2014 à 12:12, Charles Jenkins  a écrit :
> 
> During the course of this thread, Maxthon has given us code that would enable 
> us to run the experiment for ourselves. I do not doubt him.
> 
> —
> 
> Charles Jenkins
> 
> 
> On Monday, December 15, 2014 at 2:31 AM, Maxthon Chan wrote:
> 
>> My class scanning returned several OS* classes that does not conform to 
>> NSObject protocol.
>> 
>>> On Dec 15, 2014, at 00:29, Clark S. Cox III >> (mailto:clarkc...@gmail.com)> wrote:
>>> 
 
 On Dec 13, 2014, at 11:57, Maxthon Chan >>> > wrote:
 
 NSProxy checking actually work, but throwing those classes that derive 
 from Object class (note I used capitalised O here, the old Object class 
 from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
 ports)
>>> 
>>> What makes you think that Object is used in *any* of those places?
>>> 
 into the mix means that no method can be sent before class is determined. 
 I would suggest Apple add one runtime function class_isSubclassOfClass() 
 that mirrors the functionality of NSObject and NSProxy method 
 isSubclassOfClass so that derivatives of the old Object class can be 
 detected more easily.
 
> On Dec 14, 2014, at 03:49, Gary L. Wade  (mailto:garyw...@desisoftsystems.com)> wrote:
> 
> Are you saying that Apple's well-documented approach to see if an object 
> is derived from NSProxy does not work? If that's the case, you need to 
> submit a bug report to Apple. That's a serious issue that only Apple can 
> help you with.
> 
> If you are using objects not derived from NSObject nor NSProxy, then 
> change your design.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan > (mailto:m...@maxchan.info)> wrote:
>> 
>> Ain’t work! Will crash if an Object derivative showed up.
>> 
>> I am scanning ALL loaded classes and only subclasses of a certain class 
>> is interested. But due to the nature of this class scanning before I can 
>> make sure that the class derives from NSObject I cannot call any method 
>> on it.
>> 
>>> On Dec 14, 2014, at 03:34, Gary L. Wade >> (mailto:garyw...@desisoftsystems.com)> wrote:
>>> 
>>> If all you care about is if an object is a proxy or not, look at 
>>> isProxy.
>>> --
>>> Gary L. Wade (Sent from my iPad)
>>> http://www.garywade.com/
>>> 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan >>> (mailto:m...@maxchan.info)> wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of 
 a certain class. Before any NSObject method can be issued I have to 
 check if it is actually NSObject or NSProxy derivative instead of an 
 Object derivative that does not support NSObject methods. This calls 
 for runtime equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
 if (c == other)
 return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will 
 file a bug report to Apple and ask them to add this, as it is useful 
 in class scanning and i am using this technique heavily in jailbreak 
 detection.
 
> On Dec 14, 2014, at 01:20, Kyle Sluder  (mailto:k...@ksluder.com)> wrote:
> 
> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>> Why do you think the problem is with “respondsToSelector:”? The error
>> says you’re accessing past the end of a string.
>> 
> 
> 
> Because the crash happens in a call stack that originates in
> class_respondsToSelector, and involves none of Maxthon's code.
> 
> --Kyle Sluder
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
 )
 

Re: WTF is happening?

[Charles Jenkins]

During the course of this thread, Maxthon has given us code that would enable 
us to run the experiment for ourselves. I do not doubt him.

—

Charles Jenkins


On Monday, December 15, 2014 at 2:31 AM, Maxthon Chan wrote:

> My class scanning returned several OS* classes that does not conform to 
> NSObject protocol.
>  
> > On Dec 15, 2014, at 00:29, Clark S. Cox III  > (mailto:clarkc...@gmail.com)> wrote:
> >  
> > >  
> > > On Dec 13, 2014, at 11:57, Maxthon Chan  > > > wrote:
> > >  
> > > NSProxy checking actually work, but throwing those classes that derive 
> > > from Object class (note I used capitalised O here, the old Object class 
> > > from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
> > > ports)
> >  
> > What makes you think that Object is used in *any* of those places?
> >  
> > > into the mix means that no method can be sent before class is determined. 
> > > I would suggest Apple add one runtime function class_isSubclassOfClass() 
> > > that mirrors the functionality of NSObject and NSProxy method 
> > > isSubclassOfClass so that derivatives of the old Object class can be 
> > > detected more easily.
> > >  
> > > > On Dec 14, 2014, at 03:49, Gary L. Wade  > > > (mailto:garyw...@desisoftsystems.com)> wrote:
> > > >  
> > > > Are you saying that Apple's well-documented approach to see if an 
> > > > object is derived from NSProxy does not work? If that's the case, you 
> > > > need to submit a bug report to Apple. That's a serious issue that only 
> > > > Apple can help you with.
> > > >  
> > > > If you are using objects not derived from NSObject nor NSProxy, then 
> > > > change your design.
> > > > --
> > > > Gary L. Wade (Sent from my iPad)
> > > > http://www.garywade.com/
> > > >  
> > > > > On Dec 13, 2014, at 11:40 AM, Maxthon Chan  > > > > (mailto:m...@maxchan.info)> wrote:
> > > > >  
> > > > > Ain’t work! Will crash if an Object derivative showed up.
> > > > >  
> > > > > I am scanning ALL loaded classes and only subclasses of a certain 
> > > > > class is interested. But due to the nature of this class scanning 
> > > > > before I can make sure that the class derives from NSObject I cannot 
> > > > > call any method on it.
> > > > >  
> > > > > > On Dec 14, 2014, at 03:34, Gary L. Wade 
> > > > > >  > > > > > (mailto:garyw...@desisoftsystems.com)> wrote:
> > > > > >  
> > > > > > If all you care about is if an object is a proxy or not, look at 
> > > > > > isProxy.
> > > > > > --
> > > > > > Gary L. Wade (Sent from my iPad)
> > > > > > http://www.garywade.com/
> > > > > >  
> > > > > > > On Dec 13, 2014, at 11:06 AM, Maxthon Chan  > > > > > > (mailto:m...@maxchan.info)> wrote:
> > > > > > >  
> > > > > > > What I am doing here is scanning all loaded classes for 
> > > > > > > subclasses of a certain class. Before any NSObject method can be 
> > > > > > > issued I have to check if it is actually NSObject or NSProxy 
> > > > > > > derivative instead of an Object derivative that does not support 
> > > > > > > NSObject methods. This calls for runtime equivalent for one of 
> > > > > > > the following NSObject methods:
> > > > > > >  
> > > > > > > - [NSObject respondsToSelector:(SEL)aSelector] = 
> > > > > > > class_respondsToSelector(Class, SEL) // this crashed.
> > > > > > > + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
> > > > > > > class_conformsToProtocol(Class, Protocol *) // check for NSObject 
> > > > > > > protocol, this does not work.
> > > > > > > + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, 
> > > > > > > have to implement it myself
> > > > > > >  
> > > > > > > I ended up creating this:
> > > > > > >  
> > > > > > > BOOL class_isSubclassOfClass(Class cls, Class other)
> > > > > > > {
> > > > > > > for (Class c = cls; c; c = class_getSuperclass(c))
> > > > > > > if (c == other)
> > > > > > > return YES;
> > > > > > > return NO;
> > > > > > > }
> > > > > > >  
> > > > > > > If i remembered it right GNUstep runtime have this function. I 
> > > > > > > will file a bug report to Apple and ask them to add this, as it 
> > > > > > > is useful in class scanning and i am using this technique heavily 
> > > > > > > in jailbreak detection.
> > > > > > >  
> > > > > > > > On Dec 14, 2014, at 01:20, Kyle Sluder  > > > > > > > (mailto:k...@ksluder.com)> wrote:
> > > > > > > >  
> > > > > > > > On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
> > > > > > > > > Why do you think the problem is with “respondsToSelector:”? 
> > > > > > > > > The error
> > > > > > > > > says you’re accessing past the end of a string.
> > > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > > > Because the crash happens in a call stack that originates in
> > > > > > > > class_respondsToSelector, and involves none of Maxthon's code.
> > > > > > > >  
> > > > > > > > --Kyle Sluder
> > >  
> > > ___
> > >  
> > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> > > 

Re: WTF is happening?

[Maxthon Chan]

My class scanning returned several OS* classes that does not conform to 
NSObject protocol.

> On Dec 15, 2014, at 00:29, Clark S. Cox III  wrote:
> 
>> 
>> On Dec 13, 2014, at 11:57, Maxthon Chan > > wrote:
>> 
>> NSProxy checking actually work, but throwing those classes that derive from 
>> Object class (note I used capitalised O here, the old Object class from 
>> early NeXT times, also used heavily in OS X kernel, GCD and Mach ports)
> 
> What makes you think that Object is used in *any* of those places?
> 
>> into the mix means that no method can be sent before class is determined. I 
>> would suggest Apple add one runtime function class_isSubclassOfClass() that 
>> mirrors the functionality of NSObject and NSProxy method isSubclassOfClass 
>> so that derivatives of the old Object class can be detected more easily.
>> 
>>> On Dec 14, 2014, at 03:49, Gary L. Wade  
>>> wrote:
>>> 
>>> Are you saying that Apple's well-documented approach to see if an object is 
>>> derived from NSProxy does not work? If that's the case, you need to submit 
>>> a bug report to Apple. That's a serious issue that only Apple can help you 
>>> with.
>>> 
>>> If you are using objects not derived from NSObject nor NSProxy, then change 
>>> your design.
>>> --
>>> Gary L. Wade (Sent from my iPad)
>>> http://www.garywade.com/
>>> 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class is 
 interested. But due to the nature of this class scanning before I can make 
 sure that the class derives from NSObject I cannot call any method on it.
 
> On Dec 14, 2014, at 03:34, Gary L. Wade  
> wrote:
> 
> If all you care about is if an object is a proxy or not, look at isProxy.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
>> 
>> What I am doing here is scanning all loaded classes for subclasses of a 
>> certain class. Before any NSObject method can be issued I have to check 
>> if it is actually NSObject or NSProxy derivative instead of an Object 
>> derivative that does not support NSObject methods. This calls for 
>> runtime equivalent for one of the following NSObject methods:
>> 
>> - [NSObject respondsToSelector:(SEL)aSelector] = 
>> class_respondsToSelector(Class, SEL) // this crashed.
>> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
>> class_conformsToProtocol(Class, Protocol *) // check for NSObject 
>> protocol, this does not work.
>> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
>> implement it myself
>> 
>> I ended up creating this:
>> 
>> BOOL class_isSubclassOfClass(Class cls, Class other)
>> {
>> for (Class c = cls; c; c = class_getSuperclass(c))
>>   if (c == other)
>>   return YES;
>> return NO;
>> }
>> 
>> If i remembered it right GNUstep runtime have this function. I will file 
>> a bug report to Apple and ask them to add this, as it is useful in class 
>> scanning and i am using this technique heavily in jailbreak detection.
>> 
>>> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
>>> 
>>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The error
 says you’re accessing past the end of a string.
>>> 
>>> Because the crash happens in a call stack that originates in
>>> class_respondsToSelector, and involves none of Maxthon's code.
>>> 
>>> --Kyle Sluder
 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>> )
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
>> 
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com 
>> 
>> 
>> This email sent to clarkc...@gmail.com 


smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Clark S. Cox III]

> On Dec 13, 2014, at 11:57, Maxthon Chan  wrote:
> 
> NSProxy checking actually work, but throwing those classes that derive from 
> Object class (note I used capitalised O here, the old Object class from early 
> NeXT times, also used heavily in OS X kernel, GCD and Mach ports)

What makes you think that Object is used in *any* of those places?

> into the mix means that no method can be sent before class is determined. I 
> would suggest Apple add one runtime function class_isSubclassOfClass() that 
> mirrors the functionality of NSObject and NSProxy method isSubclassOfClass so 
> that derivatives of the old Object class can be detected more easily.
> 
>> On Dec 14, 2014, at 03:49, Gary L. Wade  wrote:
>> 
>> Are you saying that Apple's well-documented approach to see if an object is 
>> derived from NSProxy does not work? If that's the case, you need to submit a 
>> bug report to Apple. That's a serious issue that only Apple can help you 
>> with.
>> 
>> If you are using objects not derived from NSObject nor NSProxy, then change 
>> your design.
>> --
>> Gary L. Wade (Sent from my iPad)
>> http://www.garywade.com/
>> 
>>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
>>> 
>>> Ain’t work! Will crash if an Object derivative showed up.
>>> 
>>> I am scanning ALL loaded classes and only subclasses of a certain class is 
>>> interested. But due to the nature of this class scanning before I can make 
>>> sure that the class derives from NSObject I cannot call any method on it.
>>> 
 On Dec 14, 2014, at 03:34, Gary L. Wade  
 wrote:
 
 If all you care about is if an object is a proxy or not, look at isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
> 
> What I am doing here is scanning all loaded classes for subclasses of a 
> certain class. Before any NSObject method can be issued I have to check 
> if it is actually NSObject or NSProxy derivative instead of an Object 
> derivative that does not support NSObject methods. This calls for runtime 
> equivalent for one of the following NSObject methods:
> 
> - [NSObject respondsToSelector:(SEL)aSelector] = 
> class_respondsToSelector(Class, SEL) // this crashed.
> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
> class_conformsToProtocol(Class, Protocol *) // check for NSObject 
> protocol, this does not work.
> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
> implement it myself
> 
> I ended up creating this:
> 
> BOOL class_isSubclassOfClass(Class cls, Class other)
> {
> for (Class c = cls; c; c = class_getSuperclass(c))
>if (c == other)
>return YES;
> return NO;
> }
> 
> If i remembered it right GNUstep runtime have this function. I will file 
> a bug report to Apple and ask them to add this, as it is useful in class 
> scanning and i am using this technique heavily in jailbreak detection.
> 
>> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
>> 
>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>>> Why do you think the problem is with “respondsToSelector:”?  The error
>>> says you’re accessing past the end of a string.
>> 
>> Because the crash happens in a call stack that originates in
>> class_respondsToSelector, and involves none of Maxthon's code.
>> 
>> --Kyle Sluder
>>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com
> 
> This email sent to clarkc...@gmail.com



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

I called objc_copyClassList() to get all loaded classes so that I can scan all 
loaded classes for decedents of a certain class, and Object is part of this.

I am using this as the basis of a plugin mechanism, once the plugin bundle is 
loaded it should be detected by the app itself, and the app should not retain 
references to classes of the plugin in long term state to allow seamless plugin 
unloading.

> On Dec 14, 2014, at 08:17, Jean-Daniel Dupas  wrote:
> 
> The Object class is not used anywhere is OS X. It is deprecated and should 
> have been removed from the runtime long time ago. 
> 
> The OS X kernel does not even include obj runtime, so it can’t possibly use 
> the Object class. Mach port are integer that represent kernel object and not 
> classes.
> 
> The root class for all OS Object (XPC, GCD, …) is NSObject (which live in the 
> runtime too).
> 
> If you find subclasses of Object, you are obviously doing something wrong.
> 
>> Le 13 déc. 2014 à 20:57, Maxthon Chan > > a écrit :
>> 
>> NSProxy checking actually work, but throwing those classes that derive from 
>> Object class (note I used capitalised O here, the old Object class from 
>> early NeXT times, also used heavily in OS X kernel, GCD and Mach ports) into 
>> the mix means that no method can be sent before class is determined. I would 
>> suggest Apple add one runtime function class_isSubclassOfClass() that 
>> mirrors the functionality of NSObject and NSProxy method isSubclassOfClass 
>> so that derivatives of the old Object class can be detected more easily.
>> 
>>> On Dec 14, 2014, at 03:49, Gary L. Wade  
>>> wrote:
>>> 
>>> Are you saying that Apple's well-documented approach to see if an object is 
>>> derived from NSProxy does not work? If that's the case, you need to submit 
>>> a bug report to Apple. That's a serious issue that only Apple can help you 
>>> with.
>>> 
>>> If you are using objects not derived from NSObject nor NSProxy, then change 
>>> your design.
>>> --
>>> Gary L. Wade (Sent from my iPad)
>>> http://www.garywade.com/
>>> 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class is 
 interested. But due to the nature of this class scanning before I can make 
 sure that the class derives from NSObject I cannot call any method on it.
 
> On Dec 14, 2014, at 03:34, Gary L. Wade  
> wrote:
> 
> If all you care about is if an object is a proxy or not, look at isProxy.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
>> 
>> What I am doing here is scanning all loaded classes for subclasses of a 
>> certain class. Before any NSObject method can be issued I have to check 
>> if it is actually NSObject or NSProxy derivative instead of an Object 
>> derivative that does not support NSObject methods. This calls for 
>> runtime equivalent for one of the following NSObject methods:
>> 
>> - [NSObject respondsToSelector:(SEL)aSelector] = 
>> class_respondsToSelector(Class, SEL) // this crashed.
>> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
>> class_conformsToProtocol(Class, Protocol *) // check for NSObject 
>> protocol, this does not work.
>> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
>> implement it myself
>> 
>> I ended up creating this:
>> 
>> BOOL class_isSubclassOfClass(Class cls, Class other)
>> {
>> for (Class c = cls; c; c = class_getSuperclass(c))
>>   if (c == other)
>>   return YES;
>> return NO;
>> }
>> 
>> If i remembered it right GNUstep runtime have this function. I will file 
>> a bug report to Apple and ask them to add this, as it is useful in class 
>> scanning and i am using this technique heavily in jailbreak detection.
>> 
>>> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
>>> 
>>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The error
 says you’re accessing past the end of a string.
>>> 
>>> Because the crash happens in a call stack that originates in
>>> class_respondsToSelector, and involves none of Maxthon's code.
>>> 
>>> --Kyle Sluder
 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com 
>> 
>> 
>> This email sent to mail

Re: WTF is happening?

[Jean-Daniel Dupas]

The Object class is not used anywhere is OS X. It is deprecated and should have 
been removed from the runtime long time ago. 

The OS X kernel does not even include obj runtime, so it can’t possibly use the 
Object class. Mach port are integer that represent kernel object and not 
classes.

The root class for all OS Object (XPC, GCD, …) is NSObject (which live in the 
runtime too).

If you find subclasses of Object, you are obviously doing something wrong.

> Le 13 déc. 2014 à 20:57, Maxthon Chan  a écrit :
> 
> NSProxy checking actually work, but throwing those classes that derive from 
> Object class (note I used capitalised O here, the old Object class from early 
> NeXT times, also used heavily in OS X kernel, GCD and Mach ports) into the 
> mix means that no method can be sent before class is determined. I would 
> suggest Apple add one runtime function class_isSubclassOfClass() that mirrors 
> the functionality of NSObject and NSProxy method isSubclassOfClass so that 
> derivatives of the old Object class can be detected more easily.
> 
>> On Dec 14, 2014, at 03:49, Gary L. Wade  wrote:
>> 
>> Are you saying that Apple's well-documented approach to see if an object is 
>> derived from NSProxy does not work? If that's the case, you need to submit a 
>> bug report to Apple. That's a serious issue that only Apple can help you 
>> with.
>> 
>> If you are using objects not derived from NSObject nor NSProxy, then change 
>> your design.
>> --
>> Gary L. Wade (Sent from my iPad)
>> http://www.garywade.com/
>> 
>>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
>>> 
>>> Ain’t work! Will crash if an Object derivative showed up.
>>> 
>>> I am scanning ALL loaded classes and only subclasses of a certain class is 
>>> interested. But due to the nature of this class scanning before I can make 
>>> sure that the class derives from NSObject I cannot call any method on it.
>>> 
 On Dec 14, 2014, at 03:34, Gary L. Wade  
 wrote:
 
 If all you care about is if an object is a proxy or not, look at isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
> 
> What I am doing here is scanning all loaded classes for subclasses of a 
> certain class. Before any NSObject method can be issued I have to check 
> if it is actually NSObject or NSProxy derivative instead of an Object 
> derivative that does not support NSObject methods. This calls for runtime 
> equivalent for one of the following NSObject methods:
> 
> - [NSObject respondsToSelector:(SEL)aSelector] = 
> class_respondsToSelector(Class, SEL) // this crashed.
> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
> class_conformsToProtocol(Class, Protocol *) // check for NSObject 
> protocol, this does not work.
> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
> implement it myself
> 
> I ended up creating this:
> 
> BOOL class_isSubclassOfClass(Class cls, Class other)
> {
> for (Class c = cls; c; c = class_getSuperclass(c))
>if (c == other)
>return YES;
> return NO;
> }
> 
> If i remembered it right GNUstep runtime have this function. I will file 
> a bug report to Apple and ask them to add this, as it is useful in class 
> scanning and i am using this technique heavily in jailbreak detection.
> 
>> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
>> 
>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>>> Why do you think the problem is with “respondsToSelector:”?  The error
>>> says you’re accessing past the end of a string.
>> 
>> Because the crash happens in a call stack that originates in
>> class_respondsToSelector, and involves none of Maxthon's code.
>> 
>> --Kyle Sluder
>>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

NSProxy checking actually work, but throwing those classes that derive from 
Object class (note I used capitalised O here, the old Object class from early 
NeXT times, also used heavily in OS X kernel, GCD and Mach ports) into the mix 
means that no method can be sent before class is determined. I would suggest 
Apple add one runtime function class_isSubclassOfClass() that mirrors the 
functionality of NSObject and NSProxy method isSubclassOfClass so that 
derivatives of the old Object class can be detected more easily.

> On Dec 14, 2014, at 03:49, Gary L. Wade  wrote:
> 
> Are you saying that Apple's well-documented approach to see if an object is 
> derived from NSProxy does not work? If that's the case, you need to submit a 
> bug report to Apple. That's a serious issue that only Apple can help you with.
> 
> If you are using objects not derived from NSObject nor NSProxy, then change 
> your design.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
>> 
>> Ain’t work! Will crash if an Object derivative showed up.
>> 
>> I am scanning ALL loaded classes and only subclasses of a certain class is 
>> interested. But due to the nature of this class scanning before I can make 
>> sure that the class derives from NSObject I cannot call any method on it.
>> 
>>> On Dec 14, 2014, at 03:34, Gary L. Wade  
>>> wrote:
>>> 
>>> If all you care about is if an object is a proxy or not, look at isProxy.
>>> --
>>> Gary L. Wade (Sent from my iPad)
>>> http://www.garywade.com/
>>> 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of a 
 certain class. Before any NSObject method can be issued I have to check if 
 it is actually NSObject or NSProxy derivative instead of an Object 
 derivative that does not support NSObject methods. This calls for runtime 
 equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
 if (c == other)
 return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will file a 
 bug report to Apple and ask them to add this, as it is useful in class 
 scanning and i am using this technique heavily in jailbreak detection.
 
> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
> 
> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>> Why do you think the problem is with “respondsToSelector:”?  The error
>> says you’re accessing past the end of a string.
> 
> Because the crash happens in a call stack that originates in
> class_respondsToSelector, and involves none of Maxthon's code.
> 
> --Kyle Sluder
>> 



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Gary L. Wade]

Are you saying that Apple's well-documented approach to see if an object is 
derived from NSProxy does not work? If that's the case, you need to submit a 
bug report to Apple. That's a serious issue that only Apple can help you with.

If you are using objects not derived from NSObject nor NSProxy, then change 
your design.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Dec 13, 2014, at 11:40 AM, Maxthon Chan  wrote:
> 
> Ain’t work! Will crash if an Object derivative showed up.
> 
> I am scanning ALL loaded classes and only subclasses of a certain class is 
> interested. But due to the nature of this class scanning before I can make 
> sure that the class derives from NSObject I cannot call any method on it.
> 
>> On Dec 14, 2014, at 03:34, Gary L. Wade  wrote:
>> 
>> If all you care about is if an object is a proxy or not, look at isProxy.
>> --
>> Gary L. Wade (Sent from my iPad)
>> http://www.garywade.com/
>> 
>>> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
>>> 
>>> What I am doing here is scanning all loaded classes for subclasses of a 
>>> certain class. Before any NSObject method can be issued I have to check if 
>>> it is actually NSObject or NSProxy derivative instead of an Object 
>>> derivative that does not support NSObject methods. This calls for runtime 
>>> equivalent for one of the following NSObject methods:
>>> 
>>> - [NSObject respondsToSelector:(SEL)aSelector] = 
>>> class_respondsToSelector(Class, SEL) // this crashed.
>>> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
>>> class_conformsToProtocol(Class, Protocol *) // check for NSObject protocol, 
>>> this does not work.
>>> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
>>> implement it myself
>>> 
>>> I ended up creating this:
>>> 
>>> BOOL class_isSubclassOfClass(Class cls, Class other)
>>> {
>>>  for (Class c = cls; c; c = class_getSuperclass(c))
>>>  if (c == other)
>>>  return YES;
>>>  return NO;
>>> }
>>> 
>>> If i remembered it right GNUstep runtime have this function. I will file a 
>>> bug report to Apple and ask them to add this, as it is useful in class 
>>> scanning and i am using this technique heavily in jailbreak detection.
>>> 
 On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
> Why do you think the problem is with “respondsToSelector:”?  The error
> says you’re accessing past the end of a string.
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

Ain’t work! Will crash if an Object derivative showed up.

I am scanning ALL loaded classes and only subclasses of a certain class is 
interested. But due to the nature of this class scanning before I can make sure 
that the class derives from NSObject I cannot call any method on it.

> On Dec 14, 2014, at 03:34, Gary L. Wade  wrote:
> 
> If all you care about is if an object is a proxy or not, look at isProxy.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
>> 
>> What I am doing here is scanning all loaded classes for subclasses of a 
>> certain class. Before any NSObject method can be issued I have to check if 
>> it is actually NSObject or NSProxy derivative instead of an Object 
>> derivative that does not support NSObject methods. This calls for runtime 
>> equivalent for one of the following NSObject methods:
>> 
>> - [NSObject respondsToSelector:(SEL)aSelector] = 
>> class_respondsToSelector(Class, SEL) // this crashed.
>> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
>> class_conformsToProtocol(Class, Protocol *) // check for NSObject protocol, 
>> this does not work.
>> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
>> implement it myself
>> 
>> I ended up creating this:
>> 
>> BOOL class_isSubclassOfClass(Class cls, Class other)
>> {
>>   for (Class c = cls; c; c = class_getSuperclass(c))
>>   if (c == other)
>>   return YES;
>>   return NO;
>> }
>> 
>> If i remembered it right GNUstep runtime have this function. I will file a 
>> bug report to Apple and ask them to add this, as it is useful in class 
>> scanning and i am using this technique heavily in jailbreak detection.
>> 
>>> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
>>> 
>>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The error
 says you’re accessing past the end of a string.
>>> 
>>> Because the crash happens in a call stack that originates in
>>> class_respondsToSelector, and involves none of Maxthon's code.
>>> 
>>> --Kyle Sluder



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Gary L. Wade]

If all you care about is if an object is a proxy or not, look at isProxy.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Dec 13, 2014, at 11:06 AM, Maxthon Chan  wrote:
> 
> What I am doing here is scanning all loaded classes for subclasses of a 
> certain class. Before any NSObject method can be issued I have to check if it 
> is actually NSObject or NSProxy derivative instead of an Object derivative 
> that does not support NSObject methods. This calls for runtime equivalent for 
> one of the following NSObject methods:
> 
> - [NSObject respondsToSelector:(SEL)aSelector] = 
> class_respondsToSelector(Class, SEL) // this crashed.
> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
> class_conformsToProtocol(Class, Protocol *) // check for NSObject protocol, 
> this does not work.
> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
> implement it myself
> 
> I ended up creating this:
> 
> BOOL class_isSubclassOfClass(Class cls, Class other)
> {
>for (Class c = cls; c; c = class_getSuperclass(c))
>if (c == other)
>return YES;
>return NO;
> }
> 
> If i remembered it right GNUstep runtime have this function. I will file a 
> bug report to Apple and ask them to add this, as it is useful in class 
> scanning and i am using this technique heavily in jailbreak detection.
> 
>> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
>> 
>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>>> Why do you think the problem is with “respondsToSelector:”?  The error
>>> says you’re accessing past the end of a string.
>> 
>> Because the crash happens in a call stack that originates in
>> class_respondsToSelector, and involves none of Maxthon's code.
>> 
>> --Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Maxthon Chan]

What I am doing here is scanning all loaded classes for subclasses of a certain 
class. Before any NSObject method can be issued I have to check if it is 
actually NSObject or NSProxy derivative instead of an Object derivative that 
does not support NSObject methods. This calls for runtime equivalent for one of 
the following NSObject methods:

- [NSObject respondsToSelector:(SEL)aSelector] = 
class_respondsToSelector(Class, SEL) // this crashed.
+ [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
class_conformsToProtocol(Class, Protocol *) // check for NSObject protocol, 
this does not work.
+ [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
implement it myself

I ended up creating this:

BOOL class_isSubclassOfClass(Class cls, Class other)
{
for (Class c = cls; c; c = class_getSuperclass(c))
if (c == other)
return YES;
return NO;
}

If i remembered it right GNUstep runtime have this function. I will file a bug 
report to Apple and ask them to add this, as it is useful in class scanning and 
i am using this technique heavily in jailbreak detection.

> On Dec 14, 2014, at 01:20, Kyle Sluder  wrote:
> 
> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
>> Why do you think the problem is with “respondsToSelector:”?  The error
>> says you’re accessing past the end of a string.
> 
> Because the crash happens in a call stack that originates in
> class_respondsToSelector, and involves none of Maxthon's code.
> 
> --Kyle Sluder
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Kyle Sluder]

On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
> Why do you think the problem is with “respondsToSelector:”?  The error
> says you’re accessing past the end of a string.

Because the crash happens in a call stack that originates in
class_respondsToSelector, and involves none of Maxthon's code.

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WTF is happening?

[Phillip Mills]

Why do you think the problem is with “respondsToSelector:”?  The error says 
you’re accessing past the end of a string.

On Dec 13, 2014, at 10:20 AM, Maxthon Chan  wrote:

> This got me scratching my head, hard. Why would class_respondsToSelector() 
> crash? (BTW this is used in a class search loop so I cannot use [NSObject 
> respondsToSelector:] just yet.)
> 
> /Users/technix/Developer/Subtitler 
> Pro/Frameworks/SubtitleKit/SubtitleKitTests/SKSubripParseTest.m:33: error: 
> -[SKSubripParseTest testFileFormatSearch] : failed: caught 
> "NSRangeException", "*** -[__NSCFString substringFromIndex:]: Index 18 out of 
> bounds; string length 17"
> (
>   0   CoreFoundation  0x7fff926c 
> __exceptionPreprocess + 172
>   1   libobjc.A.dylib 0x7fff8725976e 
> objc_exception_throw + 43
>   2   CoreFoundation  0x7fff9266651d 
> +[NSException raise:format:] + 205
>   3   Foundation  0x7fff8f127b2e -[NSString 
> substringFromIndex:] + 118
>   4   AppKit  0x7fff8a4e1c49 
> +[_NSObjectAnimator _targetClass] + 92
>   5   AppKit  0x7fff8a4e1b79 
> +[_NSObjectAnimator resolveInstanceMethod:] + 34
>   6   libobjc.A.dylib 0x7fff8725c954 
> _ZL28_class_resolveInstanceMethodP10objc_classP13objc_selectorP11objc_object 
> + 80
>   7   libobjc.A.dylib 0x7fff87262799 
> lookUpImpOrForward + 356
>   8   libobjc.A.dylib 0x7fff87262617 
> lookUpImpOrNil + 20
>   9   libobjc.A.dylib 0x7fff872545ff 
> class_respondsToSelector + 37
>   10  SubtitleKit 0x0001000d02c8 +[SKFormat 
> formatEngineForExtension:] + 184
>   11  SubtitleKitTests0x00010008551e 
> -[SKSubripParseTest testFileFormatSearch] + 142
>   12  CoreFoundation  0x7fff9253f3cc 
> __invoking___ + 140
>   13  CoreFoundation  0x7fff9253f222 
> -[NSInvocation invoke] + 290
>   14  XCTest  0x000100097919 -[XCTestCase 
> invokeTest] + 253
>   15  XCTest  0x000100097b1a -[XCTestCase 
> performTest:] + 150
>   16  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   17  XCTest  0x00010009682b 
> -[XCTestSuite performTest:] + 379
>   18  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   19  XCTest  0x00010009682b 
> -[XCTestSuite performTest:] + 379
>   20  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   21  XCTest  0x00010009682b 
> -[XCTestSuite performTest:] + 379
>   22  XCTest  0x0001000a0700 -[XCTest 
> run] + 257
>   23  XCTest  0x00010009383c 
> __25-[XCTestDriver _runSuite]_block_invoke + 56
>   24  XCTest  0x00010009f36d 
> -[XCTestObservationCenter _observeTestExecutionForBlock:] + 162
>   25  XCTest  0x000100093770 
> -[XCTestDriver _runSuite] + 269
>   26  XCTest  0x000100094359 
> -[XCTestDriver _checkForTestManager] + 678
>   27  XCTest  0x0001000a35b0 
> +[XCTestProbe runTests:] + 182
>   28  xctest  0x00011256 xctest + 4694
>   29  xctest  0x000115d6 xctest + 5590
>   30  xctest  0x00010ed3 xctest + 3795
>   31  libdyld.dylib   0x7fff90e315c9 start + 1
> )
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/phillip.mills1%40acm.org
> 
> This email sent to phillip.mil...@acm.org


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

WTF is happening?

[Maxthon Chan]

This got me scratching my head, hard. Why would class_respondsToSelector() 
crash? (BTW this is used in a class search loop so I cannot use [NSObject 
respondsToSelector:] just yet.)

/Users/technix/Developer/Subtitler 
Pro/Frameworks/SubtitleKit/SubtitleKitTests/SKSubripParseTest.m:33: error: 
-[SKSubripParseTest testFileFormatSearch] : failed: caught "NSRangeException", 
"*** -[__NSCFString substringFromIndex:]: Index 18 out of bounds; string length 
17"
(
0   CoreFoundation  0x7fff926c 
__exceptionPreprocess + 172
1   libobjc.A.dylib 0x7fff8725976e 
objc_exception_throw + 43
2   CoreFoundation  0x7fff9266651d 
+[NSException raise:format:] + 205
3   Foundation  0x7fff8f127b2e -[NSString 
substringFromIndex:] + 118
4   AppKit  0x7fff8a4e1c49 
+[_NSObjectAnimator _targetClass] + 92
5   AppKit  0x7fff8a4e1b79 
+[_NSObjectAnimator resolveInstanceMethod:] + 34
6   libobjc.A.dylib 0x7fff8725c954 
_ZL28_class_resolveInstanceMethodP10objc_classP13objc_selectorP11objc_object + 
80
7   libobjc.A.dylib 0x7fff87262799 
lookUpImpOrForward + 356
8   libobjc.A.dylib 0x7fff87262617 
lookUpImpOrNil + 20
9   libobjc.A.dylib 0x7fff872545ff 
class_respondsToSelector + 37
10  SubtitleKit 0x0001000d02c8 +[SKFormat 
formatEngineForExtension:] + 184
11  SubtitleKitTests0x00010008551e 
-[SKSubripParseTest testFileFormatSearch] + 142
12  CoreFoundation  0x7fff9253f3cc 
__invoking___ + 140
13  CoreFoundation  0x7fff9253f222 
-[NSInvocation invoke] + 290
14  XCTest  0x000100097919 -[XCTestCase 
invokeTest] + 253
15  XCTest  0x000100097b1a -[XCTestCase 
performTest:] + 150
16  XCTest  0x0001000a0700 -[XCTest 
run] + 257
17  XCTest  0x00010009682b 
-[XCTestSuite performTest:] + 379
18  XCTest  0x0001000a0700 -[XCTest 
run] + 257
19  XCTest  0x00010009682b 
-[XCTestSuite performTest:] + 379
20  XCTest  0x0001000a0700 -[XCTest 
run] + 257
21  XCTest  0x00010009682b 
-[XCTestSuite performTest:] + 379
22  XCTest  0x0001000a0700 -[XCTest 
run] + 257
23  XCTest  0x00010009383c 
__25-[XCTestDriver _runSuite]_block_invoke + 56
24  XCTest  0x00010009f36d 
-[XCTestObservationCenter _observeTestExecutionForBlock:] + 162
25  XCTest  0x000100093770 
-[XCTestDriver _runSuite] + 269
26  XCTest  0x000100094359 
-[XCTestDriver _checkForTestManager] + 678
27  XCTest  0x0001000a35b0 
+[XCTestProbe runTests:] + 182
28  xctest  0x00011256 xctest + 4694
29  xctest  0x000115d6 xctest + 5590
30  xctest  0x00010ed3 xctest + 3795
31  libdyld.dylib   0x7fff90e315c9 start + 1
)



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com