Re: Question: short-read while loading .so file

["ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>]

On 2015/06/06 1:07, Szabolcs Nagy wrote:
> 
> 
> On 05/06/15 16:51, ISHIKAWA,chiaki wrote:
>> 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|.
> 
> dynamic linker is a libc issue so send the report
> to libc-alpha instead of binutils mailing list.
> (assuming you use glibc).
> 

I should have known. I was under the impression that linking (and
loading implicitly was handled by binutils package.)

I will ask libc-alpha mailing list.

>> 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?
>>
> 
> sounds like a bug, but libc-alpha will know better
> 
Thank you for your pointer again.

Chiaki

>> 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
>>
>>
>>
>>
>>
>>
> 
> 
>