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]

Re: libio vtable verification failures with multiple libcs


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

Attachment: signature.asc
Description: Digital signature


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