Re: Slow debugger loading in Xcode 3.1.3
Re: Slow debugger loading in Xcode 3.1.3
- Subject: Re: Slow debugger loading in Xcode 3.1.3
- From: Jim Ingham <email@hidden>
- Date: Tue, 2 Mar 2010 11:50:16 -0800
Try running Shark or Instruments while this loading is going on, and look at what gdb & Xcode are doing. If the machine becomes unresponsive like this, it's often because some filesystem reads are hanging up. That's why I originally thought it might be the SpotLight searching. You can also use the "fs_usage" tool - there's an equivalent in Instruments that's nicer looking as well - to see what files are being accessed.
gdb has to poke at the binaries that are loaded in the executable when we're starting up, but almost all of those are local, so that shouldn't be different between a local or Network mounted home. Only the main executable is on the network drive, and that is tiny as you say.
If you make your test project in /tmp does that make any difference? If not, then this is Xcode touching some caches in the home directory for some reason.
Hope this helps,
Jim
On Mar 2, 2010, at 11:34 AM, Jason Westlake wrote:
> Hi Jim,
>
> Unfortunately, that had no effect. I did a little more testing and
> when it's waiting for the gdb to load, the machine is pretty much
> unresponsive... Activity Monitor stops updating, etc. I get a bunch
> of these messages in Console, but not sure if they're relevant:
>
> 3/2/10 2:29:09 PM [0x0-0x1c01c].com.apple.Xcode[268]
> Xcode(268,0xb0103000) malloc: free_garbage: garbage ptr = 0x341f540,
> has non-zero refcount = 1
>
> Once the program has been run the first time, subsequent runs process
> through with no delay. That makes me think that the hang is due to
> some caches being written or libraries compiling or something that
> only happens once, but still seems quite long for a program that
> simply states "int x; x=1; return 0;".
>
> Any other thoughts? Thanks for your help!
>
> Jason
>
> On Mon, Mar 1, 2010 at 3:36 PM, Jim Ingham <email@hidden> wrote:
>> On Mac OS X, gdb has a mechanism to locate the separate debug files (dSYM's) using various agents, including SpotLight. It may be that this is hanging up for some reason. To test this, you can disable this search in gdb by putting:
>>
>> set locate-dsym 0
>>
>> in the file ~/.gdbinit on one of your test accounts, and then retrying the Xcode debugger. If that makes the slowdown go away, then the SpotLight search is the problem, and you will need to figure out why a fairly simple SpotLight search takes so long.
>>
>> Jim
>>
>> On Mar 1, 2010, at 12:18 PM, Jason Westlake wrote:
>>
>>> Hi,
>>>
>>> Our CS department head has brought a weird problem to our attention.
>>> When students are building even the simplest of C++ programs, add a
>>> breakpoint and run with the debugger and console open, it will take
>>> over 1m 30s for the program to initialize gdb and get to the
>>> breakpoint. Of note, local accounts seem to load gdb after only a
>>> second or two. This interrupts the flow of class and is a pain to
>>> deal with.
>>>
>>> Our machines are iMacs, 2GHz Core 2 Duo w/ 2 GB RAM, bound to our
>>> 10.6.2 Open Directory master. The students are logged in with their
>>> OD accounts and have home folders on the server. We're running
>>> 10.5.8, Xcode 3.1.3.
>>>
>>> Why would it take so long for the program to initialize when using a
>>> network account? The test program I'm using is literally declare and
>>> initialize 2 ints and add them, but it takes seemingly forever to
>>> build and run. Does anyone have any ideas?
>>>
>>> Thanks!
>>>
>>> Jason
>>> _______________________________________________
>>> 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
>>
>>
_______________________________________________
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