调配NSObject的performSelector:withObject:给出了EXC_BAD_ACCESS为什么?

时间:2014-04-01 22:49:57

标签: ios objective-c methods ios6 swizzling

我正在尝试调动NSObject的performSelector:withObject: rentzsch的调配库,这里是代码:

#import "NSObject+xxxx.h"
#import "JRSwizzle.h"

@implementation NSObject (xxxx)
+ (void)load
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        NSError *error;
        BOOL result = [[self class] jr_swizzleMethod:@selector(performSelector:withObject:) withMethod:@selector(xxxx_performSelector:withObject:) error:&error];
        if (!result || error) {
            NSLog(@"Can't swizzle methods - %@", [error description]);
        }else{
            NSLog(@"done");
        }      
    });
}

- (id)xxxx_performSelector:(SEL)aSelector withObject:(id)object{
    NSLog(@"called %@ %@",NSStringFromSelector(aSelector), [object description]);
    return [self xxxx_performSelector:aSelector withObject:object]; // when running it, Xcode stops and highlights this line
}

@end

我的问题是,为什么在我运行时它会给我EXC_BAD_ACCESS? 注意,它总是在同一点上失败。而且,我只是在追踪争论(没有其他魔法)。

以下是我在控制台中获得的内容:

2014-04-01 17:36:40.368 xxxApp debug[7322:90b] done
2014-04-01 17:36:44.704 xxxApp debug[7322:90b] called layoutSublayersOfLayer: <CALayer: 0xcd75650>
2014-04-01 17:36:45.536 xxxApp debug[7322:90b] called layoutSublayersOfLayer: <CALayer: 0xcd76240>
2014-04-01 17:36:45.955 xxxApp debug[7322:90b] called layoutSublayersOfLayer: <CALayer: 0xcd76550>
2014-04-01 17:36:46.170 xxxApp debug[7322:90b] called layoutSublayersOfLayer: <CALayer: 0xcd7bce0>
2014-04-01 17:36:46.470 xxxApp debug[7322:90b] called layoutSublayersOfLayer: <UIWindowLayer: 0xcd78140>

这是回溯:

(lldb) bt
* thread #1: tid = 0x7bd49, 0x01e81de5 libobjc.A.dylib`objc_retain + 21, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x56e58965)
    frame #0: 0x01e81de5 libobjc.A.dylib`objc_retain + 21
  * frame #1: 0x000099f0 MyApp debug`-[NSObject(self=0x0f8432a0, _cmd=0x022bd138, aSelector=0x0083aae4, object=0x0f8424f0) xxxx_performSelector:withObject:] + 256 at NSObject+xxxx.m:44
    frame #2: 0x007e745a QuartzCore`-[CALayer layoutSublayers] + 148
    frame #3: 0x007db244 QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 380
    frame #4: 0x007e73a5 QuartzCore`-[CALayer layoutIfNeeded] + 160
    frame #5: 0x00a55ae3 UIKit`-[UIViewController window:setupWithInterfaceOrientation:] + 304
    frame #6: 0x0096baa7 UIKit`-[UIWindow _setRotatableClient:toOrientation:updateStatusBar:duration:force:isRotating:] + 5212
    frame #7: 0x0096a646 UIKit`-[UIWindow _setRotatableClient:toOrientation:updateStatusBar:duration:force:] + 82
    frame #8: 0x0096a518 UIKit`-[UIWindow _setRotatableViewOrientation:updateStatusBar:duration:force:] + 117
    frame #9: 0x0096a5a0 UIKit`-[UIWindow _setRotatableViewOrientation:duration:force:] + 67
    frame #10: 0x0096963a UIKit`__57-[UIWindow _updateToInterfaceOrientation:duration:force:]_block_invoke + 120
    frame #11: 0x0096959c UIKit`-[UIWindow _updateToInterfaceOrientation:duration:force:] + 400
    frame #12: 0x0096a2f3 UIKit`-[UIWindow setAutorotates:forceUpdateInterfaceOrientation:] + 870
    frame #13: 0x0096d8e6 UIKit`-[UIWindow setDelegate:] + 449
    frame #14: 0x00a47b77 UIKit`-[UIViewController _tryBecomeRootViewControllerInWindow:] + 180
    frame #15: 0x00963474 UIKit`-[UIWindow addRootViewControllerViewIfPossible] + 591
    frame #16: 0x009635ef UIKit`-[UIWindow _setHidden:forced:] + 312
    frame #17: 0x0096386b UIKit`-[UIWindow _orderFrontWithoutMakingKey] + 49
    frame #18: 0x0096e3c8 UIKit`-[UIWindow makeKeyAndVisible] + 65
    frame #19: 0x0091ebc0 UIKit`-[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 2097
    frame #20: 0x00923667 UIKit`-[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 824
    frame #21: 0x00937f92 UIKit`-[UIApplication handleEvent:withNewEvent:] + 3517
    frame #22: 0x00938555 UIKit`-[UIApplication sendEvent:] + 85
    frame #23: 0x00925250 UIKit`_UIApplicationHandleEvent + 683
    frame #24: 0x0341af02 GraphicsServices`_PurpleEventCallback + 776
    frame #25: 0x0341aa0d GraphicsServices`PurpleEventCallback + 46
    frame #26: 0x02130ca5 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
    frame #27: 0x021309db CoreFoundation`__CFRunLoopDoSource1 + 523
    frame #28: 0x0215b68c CoreFoundation`__CFRunLoopRun + 2156
    frame #29: 0x0215a9d3 CoreFoundation`CFRunLoopRunSpecific + 467
    frame #30: 0x0215a7eb CoreFoundation`CFRunLoopRunInMode + 123
    frame #31: 0x00922d9c UIKit`-[UIApplication _run] + 840
    frame #32: 0x00924f9b UIKit`UIApplicationMain + 1225
    frame #33: 0x00002997 MyApp debug`main(argc=1, argv=0xbfffedac) + 135 at main.m:16

2 个答案:

答案 0 :(得分:3)

简短回答:

您的问题是ARC,您应该可以通过在项目配置中将-fno-objc-arc添加到此文件来修复它(构建阶段&gt;编译源代码&gt;编译器标志)同时确保设置{{1在你混战之前{}} error中的nil - 这会在ARC下自动发生。

说明:

ARC需要知道方法调用的返回类型以及返回值的所有权,以便它可以适当地管理引用。这会导致load出现问题,因为Objective-C中的选择器是无类型的,因此ARC无法知道返回类型。该方法被声明为返回performSelector:withObject,但是使用适当的选择器实际上可以返回id - ARC将尝试保留返回值,并且在没有实际返回任何内容时执行该操作不起作用在这种情况下返回值基本上是垃圾。

仅针对这一个文件关闭ARC没有重大影响,您的void不需要手动内存管理调用。

HTH

答案 1 :(得分:0)

禁用ARC确实可以快速解决您的问题,但可以通过额外关注您想要返回的值来找到更好的解决方案。

ARC倾向于保留swizzled函数的返回值,如果返回非objC实例(有时甚至是void),则会导致EXC_BAD_ACCESS。 请参阅https://blog.newrelic.com/2014/04/16/right-way-to-swizzle/的第二个脚注,它以更长的细节解释了这个问题,并为您提供了一个正确的解决方案(基本上,转换返回值以便编译器知道它不应该保留它)。