将地址强制转换为(id)是否有副作用???地址0xbfffe8d0是否特殊? (已修复:_NSCallStackArray问题) [英] Does casting an address to (id) have side-effects??? Is Address 0xbfffe8d0 special? (fixed: issue was with _NSCallStackArray)

问题描述

下面的代码行使我的程序以非常奇怪的方式中断...

The following line of code causes my program to break in a very strange way...

id foo = (id)0xbfffe8d0;

但是，这没问题:

int foo = (int)(id)0xbfffe8d0;

即使这样也没问题:

int magicAddr = 0xbfffe8d0;
id foo = (id)magicAddr;

W. T. F.?

<罢工> 只是在特定的init方法中插入那行代码，就会导致我的数组迭代失败，并显示"NSGenericException:集合在枚举时发生了变异".注释掉该行不会导致异常发生.该代码是单线程的.这种行为是确定性的，并且在我注释掉该行时，一遍又一遍地重复出现，并且始终不重复出现. "foo"是一个伪造的变量，不再被引用.没有其他代码引用"foo".

Just inserting that line of code inside a particular init method causes my iteration through an array to fail with "NSGenericException: Collection was mutated while being enumerated". Commenting the line out causes the exception not to happen. This code is single-threaded. The behavior is deterministic and has consistently reproduced over and over again and consistently non-reproduced when I comment the line out. "foo" is a made-up variable and is never referenced again. No other code refers to "foo".

那条线有副作用吗?将数字强制转换为(id)是否有副作用?

Does that line have a side-effect? Does casting a number to an (id) have some side-effect?

有关我在做什么的更多详细信息:

More details on what I was doing:

• 我运行NSLog(@"self =％p，super =％p"，self，super)并打印出"self = 0xa83dc50，super = 0xbfffe8d0"，这使我问确切的代码:(已删除，无关或有趣)

  The exact code: (removed, not relevant or interesting)

  好的，所以我仍然无法解释上面的行为.我无法解释为什么堆栈上的4字节int可以，但是4字节的"id"却是crashville.但是我运行了该代码几百次，将所有的乱七八糟的东西都放进去了，并且我能够使用其他值和语句触发崩溃.始终是确定性的，但对于崩溃的事物与未崩溃的事物，没有明确或可解释的模式.令人眼花stuff乱的东西，但不是最终的问题.

  OK, so I still can't explain the behavior above. I can't explain why a 4-byte int on the stack is ok, but a 4-byte "id" is crashville. But I ran this code a few hundred times putting all manor of random crap in, and I was able to trigger crashes with other values and statements. Always deterministic, but no clear or explainable pattern for stuff that crashed vs stuff that didn't. Bizzare stuff, but not the ultimate issue.

  真正的问题?该集合来自[NSThread callStackSymbols].返回_NSCallStackArray.真正的斑马就是在那里生活的地方.该伪集合有些时髦，但我无法确切告诉您.

  The real issue? The collection was from [NSThread callStackSymbols]. That returns _NSCallStackArray. That's where the real Zebra lives. There's something funky about that pseudo-collection, but I couldn't tell you what exactly.

  解决方案?

  [NSArray arrayWithArray: [NSThread callStackSymbols]]
  

  使用此修复程序，我的代码中没有任何废话的组合将触发枚举崩溃.所以要当心.如果您打算返回调用堆栈符号并将其视为数组，请进行复制.

  With the fix, no combination of random crap in my code will trigger the enumeration crash. So beware. If you plan to return the call stack symbols and treat them as an array, MAKE A COPY.

  课程??如果您调用[NSThread callStackSymbols]并希望将结果视为数组，请进行复制并获取真实的数组.否则，....有龙"！

  The lesson? If you call [NSThread callStackSymbols] and want to treat the result like an array, MAKE A COPY and get a real array. Else, .... "there be dragons" !!

  推荐答案

  否. id是指针类型的typedef，并且分配给指针没有副作用.您在其他地方的代码中还有其他错误，如果看不到更多代码就不可能说.

  No. id is a typedef for a pointer type, and assigning to a pointer has no side effects. You have some other bug in your code somewhere else, it's impossible to say without seeing more code.

  0xbfffe8d0是指向堆栈中地址的指针.在不进行优化的情况下进行编译时，赋值确实会将值0xbffe8d0写入堆栈，但是该值永远不会在任何地方读取.因此，它的效果确实是(a)将函数的堆栈帧大小增加4个字节，并且(b)更改函数代码的大小并偏移所有后续代码.这些更改很可能导致程序其他地方的错误出现或不出现.

  0xbfffe8d0 is a pointer to an address in your stack. When compiled without optimizations, the assignment does write the value 0xbffe8d0 into your stack, but that value then never gets read anywhere. So it does have the effect of (a) increasing that function's stack frame size by 4 bytes and (b) changing the size of the function's code and offsetting all of the subsequent code. Most likely these changes are causing the bug elsewhere in your program to appear or not appear.

  这篇关于将地址强制转换为(id)是否有副作用???地址0xbfffe8d0是否特殊? (已修复:_NSCallStackArray问题)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！