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 16:45:37 -0500
Well something has happened over the course of the day to alleviate
the problem. Go figure!
Daniel
On Nov 5, 2005, at 2:36 PM, Daniel Jalkut wrote:
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:
sweater.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