NSNumber> = 13将不会保留。一切都会 [英] NSNumber >= 13 won't retain. Everything else will
问题描述
我正在处理的代码需要将NSNumber对象添加到数组中。所有值为0-12的NSNumbers都被添加到正确的位置，但是在13之后导致EXC_BAD_ACCESS。我打开NSZombieEnabled，现在得到 *** - [CFNumber retain]：发送到解除分配的实例的消息0x3c78420 。
这是调用堆栈：
＃0 ___转发中的0x01eac3a7 ___
＃1 0x01e886c2 __forwarding_prep_0___
＃2 0x01e3f988在CFRetain
＃3 0x01e4b586 in _CFArrayReplaceValues
＃4 0x0002a2f9 in - [NSCFArray insertObject：atIndex：]
＃5 0x0002a274 in - [NSCFArray addObject：]
＃6 0x00010a3b in - [Faves addObject：] at Faves.m：24
＃7 0x000062ff in - ShowController.m中的[ShowController processFave]：458
＃8 0x002af405 in - [UIApplication sendAction：to：from：forEvent：]
＃9 0x00312b4e in - [UIControl sendAction：to： forEvent：]
＃10 0x00314d6f in - [UIControl（Internal）_sendActionsForEvents：withEvent：]
＃11 0x00313abb in - [UIControl touchesEnded：withEvent：]
＃12 0x002c8ddf in - [UIWindow _sendTouchesForEvent：]
＃13 0x002b27c8 in - [UIApplication sendEvent：]
＃14 0x002b9061 in _UIApplicationHandleEvent
＃15 0xE2566d59 in PurpleEventCallback
＃16 0x01e83b80在CFRunLoopRunSpecific
＃17 0x01e82c48在CFRunLoopRunInMode
＃18 0x02565615在GSEventRunModal
＃19 0xE25656da在GSEventRun中
＃20 0x002b9faf在UIApplicationMain
＃21 0x00002498 in main.m：14
如果它是' t隔离到一定范围内的NSNumbers，我会假设我用内存管理的东西，但我不知道。
任何想法？ / p>
谢谢，
Josh
数字0到12在我回答另一个问题这里时发现的是特别的。请记住，这是一个实现细节，不是一个语言规范的东西。
基本上，数字（和包括）12给你引用已经存在的NSNumber，这是可能的，因为它们是不可变的。调查显示，13岁以上的人可以单独进行实例。
所以你可能已经把你的内存管理搞完了:-)这只是数字少于13的事实可能涉及已经存在的那些在这些情况下储存培根的数字。我建议你发布更多的代码，以便我们可以跟踪具体的问题。
根据您对另一个答案的评论这里：
我在代码中添加了一条保留行，现在一切都很完美。不知道为什么我只是要滚滚谢谢！
我想你会发现，NSNumbers少于13的事实已经保留了1，自己（碰到的计数高达2）是为什么他们没有导致EXC_BAD_ACCESS。显然，你的代码正在丢失你所分配的数字 ，但是由于系统还在使用中，因此系统不会释放它们（保留计数为1或更多）。
The code I'm currently working on requires adding an NSNumber object to an array. All of the NSNumbers with value 0-12 are added fine, but 13 onward causes a EXC_BAD_ACCESS. I turned on NSZombieEnabled and am now getting *** -[CFNumber retain]: message sent to deallocated instance 0x3c78420.
Here's the call stack:
#0 0x01eac3a7 in ___forwarding___
#1 0x01e886c2 in __forwarding_prep_0___
#2 0x01e3f988 in CFRetain
#3 0x01e4b586 in _CFArrayReplaceValues
#4 0x0002a2f9 in -[NSCFArray insertObject:atIndex:]
#5 0x0002a274 in -[NSCFArray addObject:]
#6 0x00010a3b in -[Faves addObject:] at Faves.m:24
#7 0x000062ff in -[ShowController processFave] at ShowController.m:458
#8 0x002af405 in -[UIApplication sendAction:to:from:forEvent:]
#9 0x00312b4e in -[UIControl sendAction:to:forEvent:]
#10 0x00314d6f in -[UIControl(Internal) _sendActionsForEvents:withEvent:]
#11 0x00313abb in -[UIControl touchesEnded:withEvent:]
#12 0x002c8ddf in -[UIWindow _sendTouchesForEvent:]
#13 0x002b27c8 in -[UIApplication sendEvent:]
#14 0x002b9061 in _UIApplicationHandleEvent
#15 0x02566d59 in PurpleEventCallback
#16 0x01e83b80 in CFRunLoopRunSpecific
#17 0x01e82c48 in CFRunLoopRunInMode
#18 0x02565615 in GSEventRunModal
#19 0x025656da in GSEventRun
#20 0x002b9faf in UIApplicationMain
#21 0x00002498 in main at main.m:14
If it wasn't isolated to NSNumbers of a certain range, I'd assume I screwed something up with my memory management, but I've just got no idea.
Any ideas?
Thanks,
Josh
The numbers 0 through 12 are special as I discovered when answering another question here. Keep in mind that this is an implementation detail, not a language specification thing.
Basically, numbers up to (and including) 12 give you a reference to an already existing NSNumber, something which is possible due to the fact that they're immutable. Investigation showed that numbers 13 or greater gave a separate instance.
So you probably have screwed up your memory management after all :-) It's just that the fact that numbers less than 13 are likely references to numbers already in existence that's saving your bacon in those cases. I suggest you post more code so that we can track down that specific problem.
And based on your comment to another answer here:
I added a retain line into the code and everything works perfectly now. No idea why. I'm just going to roll with it. Thanks!
I think you'll find that the fact that NSNumbers less than 13 already have a retain count of 1 before you get your own (bumping the count up to 2) is why they're not causing the EXC_BAD_ACCESS. Obviously your code is losing all the numbers you allocate, but the system isn't freeing those under 13 since they're still in use (retain count of 1 or more).
这篇关于NSNumber> = 13将不会保留。一切都会的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
