steipete
message sent to deallocated instance
I'm getting message sent to deallocated instance
after scrolling the tableview (its being reused)
` [UITableView aspect_hookSelector:@selector(dequeueReusableCellWithIdentifier:forIndexPath:) withOptions:AspectPositionAfter usingBlock:^(id <AspectInfo> info) { UITableViewCell *cell;
NSIndexPath *idx = [info arguments][1];
NSInvocation *invocation = [info originalInvocation];
[invocation invoke];
[invocation getReturnValue:&cell];
// do something with table cell and index path before it is on screen
[invocation setReturnValue:&cell];
}error:nil];
` any reason this could be?
hmm, what happens if you compile the above without ARC? What object is deallocated? the cell (enable NSZombies to see)
And without ARC?
On 30 Dec 2015, at 20:10, avnerbarr [email protected] wrote:
Yes. The cell is deallocated.
― Reply to this email directly or view it on GitHub.
I have the same issue. Different use case, but the return value of the invocation is also being called after it's been deallocated. I don't even have to do anything with the value to trigger the issue. This is iOS 9.2, with ARC and zombies enabled:
SEL focusSelector = NSSelectorFromString(@"keyCommands");
[contentView aspect_hookSelector:focusSelector withOptions:AspectPositionInstead usingBlock:^(id<AspectInfo> info) {
NSArray *keyCommands;
NSInvocation *invocation = info.originalInvocation;
[invocation invoke];
[invocation getReturnValue:&keyCommands];
} error:nil];
The first time this is executed, it's fine. The next time it's triggered, some time after the hook block is executed the original array (now deallocated) is messaged.
I can get around this by hoisting the keyCommands variable out of the block like so:
SEL focusSelector = NSSelectorFromString(@"keyCommands");
__block NSArray *keyCommands;
[contentView aspect_hookSelector:focusSelector withOptions:AspectPositionInstead usingBlock:^(id<AspectInfo> info) {
NSInvocation *invocation = info.originalInvocation;
[invocation invoke];
[invocation getReturnValue:&keyCommands];
} error:nil];
There may be some downsides to this that I'm not aware of, though. These hooks are able to be executed multiple times, aren't they (I've only ever used them singly)? Would appreciate any advice!
I'm guessing that the workaround you did causes a retain cycle and its "side effect" is that the aspect doesn't cause a crash.
From poking around my case (Which I wasn't able to solve) t suspect that the aspect is being "removed" deep inside the callback block. It is hard to track (as the stack is not readable) but it looks like the aspect container of the object (or the class) is emptied out while the aspect block is being performed , or possible immediately afterwards.
Can anyone share a runnable sample that crashes? (lazy me here asking)
Can build one my self and look into that as well, might just take a bit longer.
Of course, thanks for looking into it. https://github.com/craigmarvelley/aspects-issue-78
It's not a problem of Aspects. It can be solved:
`__unsafe_unretained NSArray *keyCommands;
NSInvocation *invocation = info.originalInvocation;
[invocation invoke];
[invocation getReturnValue:&keyCommands];`
See reference https://github.com/bang590/JSPatch/wiki/JSPatch-实现原理详解#idouble-release
Its work for me by adding '__autoreleasing NSArray *keyCommands' , Hope that can help anyone else.
