libio vtable verification failures with multiple libcs

[Mike Frysinger]

On 10 Aug 2016 16: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.)

seems like this scenario is not specific to libio ?  any struct that we
use pointer mangling on can't be shared across instances right ?  a quick
grep shows setjmp/longjmp would fail too.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160810/4bb06cb7/attachment.sig>