[OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

Joshua Watt jpewhacker at gmail.com
Sat Mar 31 21:03:01 UTC 2018


On Sat, Mar 31, 2018 at 8:12 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> Just to report back, I've tried testing an earlier version of pseudo
> master with the path changes reverted and current master. With both I'm
> seeing librsvg fail during do_install with a segfault (you have to
> remove the 2> /dev/null to see it).
>
> I'm seeing multiple entries in the host's dmesg:
>
> [180364.269879] glib-compile-re[38258]: segfault at 0 ip           (null) sp 00007ffffaafbf78 error 14 in glib-compile-resources[55abc201b000+9000]
> [180376.499904] glib-compile-re[46860]: segfault at 0 ip           (null) sp 00007ffd3b10f2c8 error 14 in glib-compile-resources[55b2cb528000+9000]
> [180376.612404] glib-compile-re[46862]: segfault at 0 ip           (null) sp 00007fff612977f8 error 14 in glib-compile-resources[55ad08797000+9000]
> [180376.726317] glib-compile-re[46864]: segfault at 0 ip           (null) sp 00007ffdce018928 error 14 in glib-compile-resources[5610851ec000+9000]
> [180376.836705] glib-compile-re[46866]: segfault at 0 ip           (null) sp 00007ffc586fdda8 error 14 in glib-compile-resources[562f38dfc000+9000]
> [180603.294668] gdk-pixbuf-quer[51620]: segfault at 0 ip           (null) sp 00007ffce7947fe8 error 14 in gdk-pixbuf-query-loaders.real[55b88bb7f000+2000]
> [185206.227285] gdk-pixbuf-quer[51885]: segfault at 0 ip           (null) sp 00007ffe6393ae28 error 14 in gdk-pixbuf-query-loaders.real[556db9ae3000+2000]
> [186523.735264] gdk-pixbuf-quer[70272]: segfault at 0 ip           (null) sp 00007fff6a855808 error 14 in gdk-pixbuf-query-loaders.real[55ec4e8fd000+2000]
>
> I believe that libglib-2.0 does use syscall() for something and that
> the above programs are calling into it and faulting.
>
> Its likely possible to reproduce this outside of a build by running
> make install from librsvg under pseudo.
>
> If I take master and revert 778abd3686fb7c419e9016fdd9e93819405d52aa fr
> om pseudo, it no longer segfaults.
>
> So something is not working correctly with the intercept sadly.

I had a little time and it was easy for me to reproduce this. It looks
like real_syscall in pseudo is still NULL meaning it wasn't
initialized:

$ coredumpctl gdb -1
...
Core was generated by
`/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f1c013debfb in syscall (number=140726086677920) at
ports/linux/pseudo_wrappers.c:71
#2  0x00007f1c0071737f in g_once_init_leave ()
   from /home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libglib-2.0.so.0
#3  0x00007f1c009c615d in g_value_array_get_type ()
   from /home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0
#4  0x00007f1c009d7478 in ?? () from
/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0
#5  0x00007f1c009c41ac in ?? () from
/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0
#6  0x00007f1c01628f8a in ?? () from
/home/jwatt/Development/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
#7  0x00007f1c01629096 in ?? () from
/home/jwatt/Development/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
#8  0x00007f1c0161b06a in ?? () from
/home/jwatt/Development/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
#9  0x0000000000000002 in ?? ()
#10 0x00007ffd58684fd4 in ?? ()
#11 0x00007ffd58685069 in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb) p real_syscall
$1 = (long (*)(long, ...)) 0x0

I'm not very familiar with the internal of how pseudo works, but
adding this to the beginning of the syscall wrapper function in
ports/linux/pseudo_wrappers.c fixed it for me (no idea if this is the
"right" fix):

    if (!pseudo_check_wrappers() || !real_syscall) {
        /* rc was initialized to the "failure" value */
        pseudo_enosys("syscall");
        PROFILE_DONE;
        errno = ENOSYS;
        return -1;
    }

Looks like maybe gdk-pixbuf-query-loaders has the unlucky honour of
being one of the few programs that invokes the pseudo syscall()
wrapper before any other functions that pseudo wraps and the missing
initializer made it explode?

>
> Cheers,
>
> Richard
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



More information about the Openembedded-core mailing list