3

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

id foo = (id)0xbfffe8d0;

Yet, this is no problem:

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

And even this is no problem:

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

W. T. F. ?

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".

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:

  • I ran NSLog(@"self=%p, super=%p", self, super) and it printed out "self=0xa83dc50, super=0xbfffe8d0", leading me to ask this question
  • I have _NO_IDEA_ what that 0xbfffe8d0 value is or means.
  • The line I pasted is inside a method init2 for a class that has a reference to the NSEnumerator over the collection which throws the Exception. The class does NOT mutate the collection or even have a reference to the collection.

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

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.

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.

The fix?

[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.

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" !!

Community
  • 1
  • 1
Dave Dopson
  • 41,600
  • 19
  • 95
  • 85

1 Answers1

3

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 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.

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589