This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA/cache.c] large fread fails on NetApp share...


Hello,

This is on Windows.

One of our customers was having problems debugging his application,
because GDB was unable to read the contents of the debug_info section.
After some investigation, we found that the reason for the failure is
that his .debug_info section was pretty large (>100MB). Normally,
this isn't a problem, but it turned out that his executable was also
sitting on a NetApp share. Apparently, large reads fail for no valid
reason.  The workaround is to copy the executable to a local disk
first, and then debug that. Another option that seems to work, although
I'm not sure why, is to turn oplocks on - but that's not recommended
apparently when using ClearCase.

The customer is pursuing solutions with both NetApp and ClearCase to
see if they can get to the bottom of this, but they also noticed that
splitting the read into smaller chunks does seem to work.

Here is a patch that does just that.  This is the only place that
I could find that does a fread or a read of a possibly large block.
So I implemented the idea there only.

2008-04-29  Joel Brobecker  <brobecker@adacore.com>

        * cache.c (cache_bread_1): Renames cache_bread.
        (cache_bread): New function.

Tested with the GDB testsuite using two values for max_chunk_size:
0x100 and 0x800000.  The first run was to make sure that we would
iterate in the loop more than once even with the smallish executables
that we produce in the GDB testsuite. Note that one section of our
testsuite does the testing by debugging GDB itself, which has a
resonable size (total size is about 16MB, and .debug_info size is
0x00af4747).

I think it would be a useful addition, as it could help others who
are in the same situation. But it is a work around what I consider
a bug in the filesystem. So we may not want to complexify the code
to handle this case...

Opinions?

-- 
Joel

Attachment: cache.c.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]