This is the mail archive of the
mailing list for the binutils project.
Question: short-read while loading .so file
- From: "ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>
- To: Binutils <binutils at sourceware dot org>
- Cc: ishikawa <chiaki dot ishikawa at ubin dot jp>
- Date: Sat, 06 Jun 2015 00:51:43 +0900
- Subject: Question: short-read while loading .so file
- Authentication-results: sourceware.org; auth=none
- Authentication-results: access01.SiriusCloud.jp; dkim=none (no signature) header.i=unknown; x-dkim-adsp=none (insecure policy)
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
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.