Re: Extremely long lag while loading libraries in gdb
Re: Extremely long lag while loading libraries in gdb
- Subject: Re: Extremely long lag while loading libraries in gdb
- From: Daniel Jalkut <email@hidden>
- Date: Sat, 05 Nov 2005 14:36:16 -0500
Thanks for the great suggestions, Dave. I think the fs_usage idea
turned out to be very illuminating.
What I notice when capturing filesystem activity during the long
pause is that the disk is getting literally hammered with physical IO
requests associated with the attempt to read data. I'm no expert with
the file system, but it seems to me that something very inefficient
is going on here. For the vast majority of the library files that
are read in by GDB, every single read system call provokes a disk I/
O. What's worse, it looks as if the same disk I/O is being repeated
over and over again at times:
14:02:16.048 RdData[async] D=0x01e5e270 B=0x1000 /dev/
disk0s5
0.000421 W gdb-powerpc-app
14:02:16.048 read F=22
B=0x1000
0.000496 W gdb-powerpc-appl
14:02:16.048 lseek F=22
O=0x000fd000
0.000001 gdb-powerpc-appl
14:02:16.048 RdData[async] D=0x01e5e268 B=0x1000 /dev/
disk0s5
0.000255 W gdb-powerpc-app
14:02:16.049 read F=22
B=0x1000
0.000624 W gdb-powerpc-appl
14:02:16.049 lseek F=22
O=0x000fe000
0.000003 gdb-powerpc-appl
14:02:16.049 RdData[async] D=0x01e5e270 B=0x1000 /dev/
disk0s5
0.000330 W gdb-powerpc-app
14:02:16.049 read F=22
B=0x1000
0.000405 W gdb-powerpc-appl
14:02:16.049 lseek F=22
O=0x000fd000
0.000004 gdb-powerpc-appl
14:02:16.049 RdData[async] D=0x01e5e268 B=0x1000 /dev/
disk0s5
0.000289 W gdb-powerpc-app
That's weird, isn't it?
As a sort of blunt test, I thought I'd compare all the read activity
for a particular library, with a control case of accessing that same
file's contents from another process. I picked CoreFoundation as my
target test. I used the "cat" tool to copy everything in the
CoreFoundation binary to another file through redirection: "cat
CoreFoundation > testoutput". I compared that with the reads that
take place in gdb for just the CoreFoundation library read, and the
results are dramatic.
Total read system calls in gdb: 1552.
Total RdData I/O calls in gdb: 1546.
Total read system calls in cat: 302.
Total RdData I/O calls in cat: 73.
I'm not sure I can expect gdb to get the same proximity benefits that
cat gets by reading straight through the file, but the sheer number
of reads from gdb and the fact that almost every one requires a
physical I/O seems alarming.
Have I done something to my machine to screw up gdb's ability to read
efficiently from the disk!?
Daniel
On Nov 5, 2005, at 12:41 PM, Dave MacLachlan wrote:
When running Shark, were you doing a Time Profile, or a System
Profile? A System Profile may give you more data on what is
happening with external IO. Your other good option is to look at
the load with fs_usage. That at least will tell you if you are I/O
bound.
Cheers,
Dave
On Nov 4, 2005, at 7:45 PM, Daniel Jalkut wrote:
Recently I've started experiencing *extremely* long (like 30
seconds or more) lags while "loading libraries" during a debug
session, either from gdb command line or through Xcode. The delay
is striking and fairly new, but I am 99% sure I started seeing it
before recently updating to Xcode 2.2. Any suggestions for how I
might proceed with debugging this problem?
As I said, I'm 99% sure I started seeing it prior to 2.2, and if
anybody is curious, I am *not* using the new feature of Xcode that
is advertised in the release notes as potentially leading to
longer debugger startup times.
I tried running Shark against gdb while the long delay was
happening, but it seemed pretty meaningless to me. In fact, it
seemed like the total seconds in gdb was much less than the total
seconds in user waiting time. I assume this means that gdb is
blocked on waiting for some external IO to happen, or something.
Any advice appreciated,
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40adobe.com
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