Crash happening when using removeObjectsInArray:[NSArray arrayWithArray:] [duplicate] - objective-c

This question already has answers here:
crash while removing objects from NSMutableArray
(6 answers)
Closed 8 years ago.
self.filteredProducts = [[NSMutableArray alloc] init];
//Find products
self.filteredProducts = (NSMutableArray*)[(NSMutableDictionary *)[self.CECategoriesDictionary objectForKey:category.categoryGuid] allValues];
if([self.oldfilteredProducts count] > 0 && selectedLevel==5)
{
NSMutableArray *diff = [self.filteredProducts mutableCopy];
[diff removeObjectsInArray:[NSArray arrayWithArray:self.oldfilteredProducts]];
[self.filteredProducts removeObjectsInArray:[NSArray arrayWithArray:diff]];
}
Logs :
[__NSArrayI removeObjectsInArray:]: unrecognized selector sent to instance 0x1aed19d0
2014-09-15 22:00:19.243 SAPRetailEx[10325:90b] [ERROR]:Uncaught exception: -[__NSArrayI removeObjectsInArray:]: unrecognized selector sent to instance 0x1aed19d0
2014-09-15 22:00:19.243 SAPRetailEx[10325:90b] [ERROR]:-[__NSArrayI removeObjectsInArray:]: unrecognized selector sent to instance 0x1aed19d0
2014-09-15 22:00:19.248 SAPRetailEx[10325:90b] [ERROR]:(

you cannot remove objects form NSArray; I know you think you are using an NSMutableArray but you are not. This is made quite clear from your error [__NSArrayI removeObjectsInArray:]: unrecognized selector; __NSArrayI is an immutable object (that is what the I means), if this were really a mutable array the class would be __NSArrayM.
you seem to be operating under the false impression that you can get a mutable array simply by casting an NSArray to NSMutableArray; this has never been how casting works under any C derived language. You instead need to send a mutableCopy message to the NSArray. Of course you now have a copy of the array so modifications arent reflected in the original. you also own the copy so if you arent using ARC you need to release the copy when you are done.
I'm curious to know why you are already making a mutableCopy of self.filteredProducts then also trying to remove directly from self.filteredProducts. even if this worked how you expect you are now copying the array for no reason then removing from both thee "original" and the "copy".

self.filteredProducts isn't really an NSMutableArray It's just a normal NSArray which doesn't have a "remove option".
[self.filteredProducts removeObjectsInArray:[NSArray arrayWithArray:diff]
To help in the future... set at break point in your code after you assign it, then print out the description and see what type of object it really is. either po in the debugger or right click on "Print Description". Don't believe what is says on the left panel, that's just what you told the code the object is, look at the description on the right to see what it really is.

Related

NSMutableArray removeObject: throwing an error [duplicate]

This question already has answers here:
Unrecognized selector when adding an object to NSMutableArray
(2 answers)
Closed 8 years ago.
I have an #property (nonatomic,copy) NSMutableArray* children;, and I'm adding/removing items to this array.
Here's the surprise:
- (void)addChildDocument:(PPDocument *)doc {
[_children addObject:doc];
}
- (void)removeChildDocument:(PPDocument*)doc {
[_children removeObject:doc];
}
The first one works fine. The second one doesn't.
-[__NSArrayI removeObject:]: unrecognized selector sent to instance
Can you please explain to me exactly what is going on and how the children array suddenly shows up as immutable?
UPDATE:
The issue has been resolved. However, as weird as it may strike you, the copy most of you referred to had nothing to do with the issue. Weirdly it had to do with a parent property of each PPDocument not being correctly set as weak. Once I did that (and leaving the children as it was), everything works fine - as expected. And NSMutableArrays remain mutable whatsoever.
You must be doing:
obj.children = #[ #"Some", #"immutable", #"array" ];
between those calls.
You can't remove what you're adding in the method. You need to give him an array index.
For example,
[_children removeObject:[_children lastObject]];
if you know that it's always gonna be the last one.
If its not, please provide a comment with more explanation on where the object can be.
Edit : actually you might be able to do the following, could you try too?
[_children removeObjectAtIndex:[_children indexOfObject:doc]];

Changing value of a NSString

I am having problems changing the value of an NSString.
It is declared in my class like this:
#property (strong, nonatomic)NSMutableString *votes;
When the object is created, it is set like this:
song.votes = [dict objectForKey:#"Votes"];
And finally is where the trouble occurs. Later in my code I try to modify the value like this:
song.votes =[responseArr valueForKey:#"CNT"];
This line is leading to this crash:
'NSInvalidArgumentException', reason: '-[__NSCFString setVotes]:
unrecognized selector sent to instance 0x14f84430'
I'm think my problems is caused by one of these:
1. Incorrectly setting the properties above. I've tried setting it as (copy, nonatomic) as well but it does the same thing.
2. i need to use an NSMutableString for this. I tried changing it to NSMutableString but it still crashes when it changes (admittedly I am initializing and changing it the way way when using NSMutableString, am not entirely sure how to change things when its Mutable.
I think the problem is in the way you're allocating / setting your song object. Somewhere between setting the first and the second value, you're probably deallocating song and then trying to set it's properties, or you're modifying it in such a way that it's not the same class type anymore.
unrecognized selector sent to instance 0x14f84430' pretty much sums it up for you. The second time you try to set the votes property, it tries to access the synthesized setter (setVotes) from song which is no longer the class you think it is.
From the error it looks like you may be re-allocating song as a NSString object. That's why it's trying to access a setVotes method on NSString and such a method does not exist, so it bails out and crashes.
Are you sure you're not doing something like song = [someString retain]; ?
Use -mutableCopy if you need a mutable copy of your NSString.
song.votes = [[dict objectForKey:#"Votes"] mutableCopy];
Assuming responseArr is an array, [responseArr valueForKey:#"CNT"] returns an array with the return value of each of the instances in responseArr. Your property is for a NSMutableString, but you set it to a NSArray.
(Also, do provide the actual error that you get when you crash instead of just saying 'it crashes'.)

AXUIElementRef and ARC - Deallocated instances and __bridge vs __bridge_transfer

I get this error on an NSMutableArray:
-[Not A Type release]: message sent to deallocated instance 0x1006e29c0
It happens on this line:
[_array removeAllObjects];
Now, I understand what the error means but not why it happens in this case.
I've added an NSLog right before the above line like so:
NSLog(#"%#", [_array class]);
And this executes normally and with the correct behavior, this is the log:
2013-03-13 11:19:27.366 App[66921:303] __NSArrayM
2013-03-13 11:19:27.367 App[66921:303] *** -[Not A Type release]: message sent to deallocated instance 0x1006e29c0
So right before removing it doesn't seem to be deallocated..
Even if I remove the removeAllObjects call and replace it with the below line, I still get the same error.
_array = [[NSMutableArray alloc] init];
All I'm doing elsewhere in the code is calling [_array addObject:...]
_array is a strong property:
#property (strong) NSMutableArray *array;
The array is first initialized in the init method.
EDIT: I'm adding AXUIElementRefs to this array like so:
[_array addObject:(__bridge_transfer id)elementRef];
I thought the __bridge_transfer brings it over to ARC and I wouldn't need to manage any of that?
What could be the problem?
UPDATE:
Here is a sample project: http://users.telenet.be/prullen/AXMemory.zip
This is a working project as I'm using __bridge and not __bridge_transfer.
This project contains a simple loop that does the same thing over and over again. This is to demonstrate that with just __bridge, the AXUIElementRefs never get released. They stay in memory. That's what I see in the Instruments profiler too. You can also see the memory usage increasing every few seconds via activity monitor.
The AXUIElementRefs were obtained via AXUIElementCopyMultipleAttributeValues - so I would assume that I would have ownership of them? Nevertheless, changing to __bridge_transfer results in the errors above.
If anyone could take a look at this and let me know what I'm doing wrong, that would be much appreciated.
I get an array of properties via the following statement: (line 60).
AXUIElementCopyMultipleAttributeValues(frontWindowRef, attributes,0,&attributeValues);
Line 110 I assign the AXUIElement (looping over the children array):
element = CFArrayGetValueAtIndex(childrenArrayRef, i);
Line 112 is where I add the AXUIElementRef to the array:
[_array addObject:(__bridge id)(element)];
Line 36 is where I empty it if it's over 500 elements:
if ([_array count] > 500) {
[_array removeAllObjects];
}
You can't just assume that __bridge_transfer "brings it over to ARC and [you] wouldn't need to manage any of that". You have to understand what rights and responsibilities you had for elementRef at the time (which we can't tell from what you've written).
I find it's much easier to understand the bridge casts if you use the corresponding CFBridgingRetain() and CFBridgingRelease() functions. __bridge_transfer is the same as CFBridgingRelease(). So, the question is: do you own elementRef at the time? Is it appropriate for you to release it?
Consider, would the following have been correct?
[_array addObject:(__bridge id)elementRef];
CFRelease(elementRef);
If not, then neither is __bridge_transfer.
From the nature of the error you're getting, I strongly suspect you were not entitled to release elementRef, so you were not entitled to tell ARC that it owns it and must release it. You have caused the AXUIElementRef to be over-released. You should just have used a __bridge cast – no "transfer" and no CF…Release().

Re-initialize NSMutableArray as NSMutableArray

I was having a problem with my app throwing an exception when calling removeObjectAtIndex on an NSMutableArray, saying that myLocationsArray was declared immutable. All other manipulation on that array was fine, it was most definitely declared correctly etc etc but somewhere in my app it was getting set as immutable. After investigating for a while trying to find where it was getting set immutable, I decided screw it and just redeclared the variable as such:
myLocationsArray = [[NSMutableArray alloc] initWithArray:[defaults
objectForKey:MYLOCATIONSARRAY_KEY]];
right before the removeObjectAtIndex call.
However I know this has got to be badwrong, I'm calling alloc/init twice on the same variable. However it's the only thing that has worked. Is there any way to remind this variable that it is an NSMutableArray without introducing memory leaks like I am?
NSUserDefaults returns immutable copy of your array. It doesn't matter whether you put NSArray or NSMutableArray in it, it always give you immutable copy back.
So, do this to get a mutable copy that you can work with
myLocationsArray = [[NSMutableArray alloc] initWithArray:[[[defaults objectForKey:MYLOCATIONSARRAY_KEY] mutableCopy] autorelease]];
or just this
myLocationsArray = [[defaults objectForKey:MYLOCATIONSARRAY_KEY] mutableCopy];
I would suggest to set a breakpoint on the line where your program is throwing an exception (the one containing removeObjectAtIndex) and inspect with the debugger the real type of the array. If you go with you mouse over the array name, a popup menu will display giving you all the information you need about the pointed object.
What I expect is that you find out this way that the object is an NSArray (vs. NSMutableArray) and then trace back to the point where you initialized it in the first place.
It looks like you're working with NSUserDefaults. All objects you get out of NSUserDefaults are always immutable, regardless of what you stored into it. NSUserDefaults doesn't keep a reference to the specific object you set into it, it keeps the data. It's effectively making a copy. When you get something out of NSUserDefaults, it makes a new (immutable) object from the data it has stored and gives that to you.
Unsurprisingly, you can't change what's stored in NSUserDefaults by mutating what you (think you) stored in it. You can only change what's stored by replacing what you previously stored by storing something anew.
The declaration should not matter; your error is a run-time error. It sounds like your myLocationsArray variable has been assigned an immutable array (NSArray) though whether it is being re-assigned somewhere or was always immutable is impossible to say from your code fragment.

Debugging unexpected error message - possible memory management problem?

I am trying to debug an application that is throwing up strange (to my untutored eyed) errors. When I try to simply log the count of an array...
NSLog(#"Array has %i items", [[self startingPlayers] count]);
...I sometimes get an error:
-[NSCFString count]: unrecognized selector sent to instance 0x1002af600
or other times
-[NSConcreteNotification count]: unrecognized selector sent to instance 0x1002af600
I am not sending 'count' to any NSString or NSNotification, and this line of code works fine normally.
A Theory...
Although the error varies, the crash happens at predictable times, immediately after I have run through some other code where I'm thinking I might have a memory management issue. Is it possible that the object reference is still pointing to something that is meant to be destroyed? Sorry if my terms are off, but perhaps it's expecting the array at the address it calls 'count' on, but finds another previous object that shouldn't still be there (eg an NSString)? Would this cause the problem?
If so, what is the most efficient way to debug and find out what is that address? Most of my debugging up until now involves inserting NSLogs, so this would be a good opportunity to learn how to use the debugger.
This is a sign that the memory location at which your code is expecting your array to live has either:
Been deallocated and another variable has been allocated in the same place
Been clobbered by some bad code
My bet would be on the first one. You'll want to carefully look at where you are allocating the array and make sure that you're not allowing its retain count to reach zero.
Remember that if you're allocating the array using a convenience method (basically one that starts with array) and not either retaining it or assigning it using dot notation (e.g. self.myArray = [NSArray arrayWith...]) and a property marked retain, it will be freed possibly as soon as the method in which you allocated it returns.
TL;DR is to check where you're assigning the array and make sure you're using something like this:
self.startingPlayers = [NSArray arrayWithObjects:#"first", #"second", nil];
and not like this:
startingPlayers = [NSArray arrayWithObjects:#"first", #"second", nil];
That one's bitten me countless times, including in the middle of a presentation right after I mentioned not to do it.
What does [self startingPlayers] return? Try printing that first:
NSLog("startingPlayers is %#", self.startingPlayers);
Perhaps startingPlayers contains a bad pointer (uninitialized) or a pointer to something that has already been released (and reused for something else).