failure using RKLite under debugger

[Pat McGee]

Really strange failure here:

I call rangeOfRegex: in one place in my code. It returns the results I expect, but I can't get the debugger to break at the line after the call, and when I single step through it, the debugger ignores that line.

I call rangeOfRegex: in another place with parameters that have the same value (but are not the same objects). This time it doesn't return the expected results, and the debugger still won't break on the line after the call. When I step into rangeOfRegex:, I see that it calculates the results I expect. When I get to the "return(results)" line, results contains what I think it should contain. When I get back to the caller, that value has apparently been discarded and the variable I assign the value to has not changed.

Anyone have any hints on what I could try next?

Thanks,

Pat

[John Engelhart]

The problems you're having with the debugger, getting it to stop of the line you want, sound suspiciously like the type of problem you can run in to when you have optimization turned on.  I'll usually turn optimization off completely when the bug(s) start to become difficult.  With optimization, the code that you wrote and the code that actually got generated are not necessarily the same any more, in fact it used to be when you turned on -O you lost the ability to do source debugging at all.  Things have gotten a lot better, but you can run in to odd quirks where you're trying to set a break point on a line that literally no longer 'exists' because its been optimized away, or shuffled in to obscurity.

The next problem (results correctly calculated, but returned incorrectly) sounds like the stack got smashed, and if that's the case may be contributing to your other problems.  Since rangeOfRegex: returns an NSRange value, which in reality is a struct, it (usually) can't be passed back using a single register like an int result.  How "results bigger than an int" get returned are very machine and ABI specific, but in general the memory to hold the struct is from the stack, and a pointer to that stack location is what is returned.  Anything that stomps on the stack is likely to wreck havoc with those returned results.

I'd suggest the following:

Disable optimization completely.

If you're running on 10.5, try enabling the GCC stack protection feature.  The option flag is '-fstack-protector-all'.  If there is any kind of stack corruption, this will probably catch it.

Try running with GuardMalloc.  You can read about it at its man page: `man libgmalloc`.  You can enable it directly from Xcode using the Run > Enable Guard Malloc (at the bottom).  Be warned that this makes your program run about 100X (sic) and can consume vast amounts of memory due to the way the library works (every allocation, even a single byte, takes up 4K, which is the minimum MMU page size).  This will catch the majority of bugs that write OR READ past the size of a malloc() allocation.

Enable various debugging environment flags.  I recommend 'MallocGuardEdges=1' 'MallocScribble=1', 'MallocStackLogging=1', 'CFZombieLevel=1'.  These will cause malloc() and CoreFoundation to write 0x55 (malloc) or 0xfc (CoreFoundation) over memory that has been freed, which tends to cause anything that uses it to crash immediately.

Read through http://developer.apple.com/technotes/tn2004/tn2124.html which is quite useful.