This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

Question: short-read while loading .so file


I asked the following question to binutils mailing list first
and was advised to post it to libc-alpha. I misunderstood that dynamic
loading was handled by a component of linker.
Here it goes. The behavior was observed under Debian GNU/Linux.

TIA

---

Hi,

While testing how mozilla thunderbird handles "short read", i.e.,
a |read| system call that returns prematurely without returning all the
octets (subsequent |read|(s) will return the octets eventually),
I was surprized at the following.

(I simulated "short read" by preloading a hand-crafted |read|, using
LD_PRELOAD and this hand-crafted |read| subtracts some numbers from the
requested number of octets (60 and 1 depending on the requested # of
octets), and perform the real |read| and return the result.
I made sure that the repeated calls of |read| with decreasing # of
requested octets appropriately read the initial requested # of octets if
they are available in the file store.
(So a |read| for 256 octets end up with three reads of 196, 59, and 1
if the caller of |read| handles the "short read" appropriately.

BTW, such "short read" can occur with remote file system when there is a
network issue, etc. Usually, local file system does not cause "short
read", but once we go across the net, anything can happen.)

My surprise was that during the test of mozilla thunderbird when I
I injected the "short read" to a few  files, I made a mistake of
applying short tread to a few .so files and
I observed that these *.so files were dynamically loaded by such short
|read|.
That is, when the request to read these relatively small .so files by
|read| with requested # of octets being 4096, my hand-crafted prelaoded
|read| reads only 4036 (4096 - 60) octets, but
the dynamic loader did not request the remaining 60 octets, and merrily
went on running.

My question is:

Does the loader handle "short read" properly by issuing additional
|read| if it notices that it needs to read more octets which are missing
from the data structure  read partially by the first |read|?

Or was I just lucky that the last 60 octets (and presumably more octets
before the last 60 octets) were mere fillers and the real code and data
lived only the initial portion of 4096 octets, and that the failure to
read the last 60 octets did not cause any issues in this particular run?

Yes, the mozilla thunderbird did not crash or anything although no
additional read was issued to read the remaining 60 octets.

That is why I am asking this question.

Thank you in advance for your attention.

Best Regards,
Chiaki Ishikawa



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