Re: problems/bugs in xCode
Re: problems/bugs in xCode
- Subject: Re: problems/bugs in xCode
- From: Jonny Taylor <email@hidden>
- Date: Sat, 25 Jun 2005 11:20:53 +0100
From: Markus Hitter <email@hidden>
>> 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.
>
> Have you Preferences -> Building -> "Always save" for unsaved files
> enabled? I have myself and don't see this problem. You can use Undo
> to revert to a file state eariel than the last build/save.
From: Mark Bessey <email@hidden>
>> 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.
I have "ask before saving" set. It's not a completely reproducible problem
(and I had a quick go and couldn't reproduce it with a fresh project. It
seems to be associated with switching from Release to Debug build
configuration (or vice-versa?) when the debug build is out of date; both are
out-of-the-box settings except for altivec enabled. The hammer appears for
the file for the Debug build, but nothing is compiled. Manually toggling the
hammer sorts it out. I'll try and get more information on this.
From: Mark Bessey <email@hidden>
>> 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)?
No I'm not. 43GB hard disk available, ~9GB virtual memory, ~400MB actual RAM
listed as "free" by Activity Monitor.
>
> 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.
I haven't actually seen this problem today. I've turned logging on and will
see if it happens again...
>> 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.
Yes I certainly can. I'll file a bug when I'm off dial-up, but in the
meantime, the following surprisingly short test case reproduces it. Can't
imagine what could be causing the problem! Create a new project with the
Carbon Application template, rename "main.c" to "main.cpp" and paste in the
following code:
=====
#include <stdio.h>
class MyClass {
public:
MyClass(){}
};
void init(void)
{
MyClass op;
// MyClass *op = new MyClass;
}
int main(void)
{
fprintf(stderr, "breakpoint is here\n");
fprintf(stderr, "step over should stop here!\n");
return 0;
}
=====
Then set a breakpoint where indicated, and build & debug. Step over, and
"Debugging of <project> ended normally".
>
>
>> 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.
OK. Thanks.
>> 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.
Again, I'll file the bug when I'm off dial-up.
Oh, and while I'm at it - kudos to whoever came up with the
marks-in-the-scroll-bar that indicate where errors are in source files, and
where hotspots are in the code in Shark. A brilliant innovation that I'd
never seen before! I don't suppose there's any API allowing us to do that
easily in our code...?
Thanks for your help!
Jonny
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden