Re: “EXC_BAD_ACCESS” object is not nil but not accessible
Re: “EXC_BAD_ACCESS” object is not nil but not accessible
- Subject: Re: “EXC_BAD_ACCESS” object is not nil but not accessible
- From: Marco Frisan <email@hidden>
- Date: Mon, 17 Jan 2011 05:37:48 +0100
Il giorno 17/gen/2011, alle ore 03.02, William Squires ha scritto:
> I'd have a look at your object allocations/deallocations with Instruments - this sort of cr*p usually means you over-released something, or you forgot to retain it. Remember that containers have no way of knowing if you over-release an object stored in them from somewhere else. i.e.
>
> NSString *myBoobooString = [NSString stringWithFormat:@"%@ - %@", @"foo", @"bar"];
> NSString *myGoodString = @"bas"
> NSArray *myOopsieArray = [NSArray arrayWithObjects:myBoobooString, myGoodString, nil];
> [myBoobooString release];
> [myGoodString release];
> ... <- something else happens here
> [myBoobooString release]; <- Instant kablooey when you release the NSArray, or try to enumerate and traverse it!
I verified with Instruments - Leaks the version available on the provided link (since I modified my local copy) and the result is that I have no memory leak.
The surprise is that the first execution, using Instruments and Breakpoint button activated (even if there is no breakpoint placed in code), did not block.
The second did not block too. But it displayed 28 leaks, that could be the number of attributes * 2 (keys and values).
I controlled and controlled again the code 10...50 times and I have not been able to find if I actually release something I should not.
Though, the point is that the program, if launched without Instruments, crashes exactly when I click over a volume to display the detailed attributes in the right table. If I activate Breakpoints button (and so, debugger) Xcode blocks at line 20 of VLDiskItemRecord.m, where there is this code:
@synthesize attributes = _attributes;
If I select the previous call (from the right pop up menu, over the editor view, while debugger is still active) Xcode points to line 57 of VLVolumeDetailsViewController.m, inside the implementation of method numberOfRowsInTableView:. So, the code that actually causes the error (as I already explained) is:
NSDictionary * attributes = _record.attributes;
We can exclude that the cause could be "NSDictionary * attributes = " ;-)
So the problem is "_record" or ".attributes". Based on the Xcode behavior, I am inclined to think it is ".attributes".
Then, what I did is to place a breakpoint the line before where I test for _record nullity. Launched the program. Press continue once, since the first time the method is called there is no volume selected. And then, I selected a volume. Application stopped at that line and I passed the mouse over _record to see its state (yellow pop-up views, with expansions arrows, the same info you can get from debugger window).
And, surprise! _attributes points to a NSEvent instance!!!
Though _attributes was obtained calling attributesOfItemAtPath:error:, no error was produced, and I retained it... to be honest I did not, though I corrected it and retained _attributes but result does not change. I get the EXC_BAD_ACCESS error even if i do [[_attributes retain] retain].
And now, after retaining _attributes, if I verify the state of _record at the nullity test line, _attributes points correctly to a NSDictionary.
So, my conclusions are: ?????????????
There is no possible control over dictionaries returned by convenience methods? I have to make copies of them every time I need one?
For now I resolved with initWithDictionary:copyItems:.
Thanks
P.S. I just made some changes to initAttributes method in VLDiskItemRecord.m:
- (void)initAttributes {
NSLog(@"%s", __FUNCTION__);
NSError * error = nil;
NSFileManager * fm = [NSFileManager defaultManager];
NSDictionary * attr = [fm attributesOfItemAtPath:_mountPoint error:&error];
if (error != nil || attr == nil) {
NSLog(@"Impossible to get attributes for path \"%@\". Reason: %@",
_mountPoint,
[error localizedDescription]);
_attributes = nil;
return;
}
_attributes = [attr retain];
}
Using the debugger I discovered that attributesOfItemAtPath:error: does not return a simple NSDictionary, but an instance of NSFileAttributes, a private class that is probably a subclass of NSDictionary. I am inclined to think that the cause of this unpredictable behavior could be the way NSFileAttributes is implemented.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden