Re: libio vtable verification failures with multiple libcs

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 10/08/2016 11:19, Florian Weimer wrote:
> This is just a heads-up that the Ruby test suite loads libc.so.6 with an absolute path, bypassing AT_PLATFORM directories.  This can lead to multiple libc.so.6 copies within the same process:
> 
>   <https://bugzilla.redhat.com/show_bug.cgi?id=1361037#c17>
> 
> There is a test case which creates a FILE * object using one libc and passes it to fprintf in another libc, which fails vtable verification because the vtable is not known to fprintf.  The dlmopen bypass for verification does not kick in because dlmopen is not used.
> 
> I don't think there is anything we should change on the glibc side as far as libio is concerned.  Fortunately, this is just a Ruby test case for the Fiddle FFI module.  Correct Fiddle use should be unaffected.
> 
> (But I do wonder if we should detect that the libc.so.6 soname is loaded a second time and fail.)
> 
> Florian

I would say libio vtable is working as intended and I will not bother 
adding a check for multiple libc.so.6 loading (since it is triggered by 
issuing with an absolute path explicit).

The only thing that bothers me reading the bug report is the random error 
messages it triggered and the time it took to actually found the culprit.
Maybe we could help debugging with better warnings.