On Jun 24, 2005, at 8:17 AM, Jonny Taylor wrote:
The most serious is that when debugging, the debugger has a habit of
aborting when I click around in the call stack. This seems to be connected
with a 200MB array I have defined as a global; if I halve its size I don't
see any problems.
I don't seem to get a crash in a simple test, but the debugger does get awfully slow. If you can file a bug with a (hopefully minimal) reproducible case, that'd be helpful. Are you perhaps really low on virtual memory (boot disk nearly full)?
When you do file a bug, it's helpful to include a debugger/gdb interaction log. You enable this by executing the following command in Terminal (after quitting Xcode):
defaults write com.apple.Xcode PBXGDBDebuggerLogToFile YES
The debugger log file ends up in /private/var/tmp/<your userid>/Temporary Items. See the "Expert Preferences" help in Xcode for details on how to change the name & location of this file, if you want to.
Some other gripes:
When debugging, if you step over a fprintf(stderr, ...), xCode behaves as
if you pressed "Continue" instead of "Step Over".
This shouldn't happen, in general. I have occasionally seen similar things happen when debugging optimized code, but all bets are off in that case, anyway. Again, if you can make it happen on demand, filing a bug with a debugger log would be very helpful.
Build often doesn't recompile dirty source files - I almost always need to
alter, not save, explicitly compile and then build before my changes are
picked up.
The only case where I've seen this happen is when your source files are on a network file system and your object files are local, or vice-versa. In that case, differing timestamps on the two filesystems can confuse the build system. If you're not doing something unusual, then dependency analysis should work automatically. If you modify a file, the checkbox in the "needs to be built" column in the detail view should be checked - that's the column with the hammer icon in the header. If it's not set, clicking in the cell should turn on the checkmark, forcing the file to be rebuilt.
When I choose "Show Assembly Code" for my 1-file project several times over
the course of a session, it compiles 1 more source file every time (i.e. the
third time I do it it claims to be "compiling 3 source files", and does
indeed take 3 times as long to do its stuff). Quitting xCode (and I think
closing the project) resets this.
This is a known bug in Xcode 2.1. Closing and re-opening the project will work around the problem.
Use arrow keys to navigate debugger call stack and the code displayed below
doesn't update like it does if you click somewhere else in the call stack.
You're right, it doesn't. Please file a bug. In the meantime, take note that hitting "Return" after selecting a stack frame with the arrow keys does update the display.
I hoe this helps,
-Mark