qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] qemu-user issue when used with uclibc-ng


From: Dave Flogeras
Subject: [Qemu-devel] qemu-user issue when used with uclibc-ng
Date: Mon, 12 Mar 2018 19:23:22 -0300

Hi, I use qemu-user on Gentoo to form a qemu+binfmt+chroot setup to build
packages targeting an arm uclibc-ng based system.  The process is described
here:

https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot

After upgrading to uclibc-ng-1.0.26 I would get the following assert and
segfault from qemu:

qemu-x86_64:
/var/tmp/portage/app-emulation/qemu-2.11.0/work/qemu-2.11.0/accel/t
cg/translate-all.c:2078: page_set_flags: Assertion `start < end' failed.
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601c3f6b

I have tracked this down as best I could to a way to reproduce it.  First,
I don't believe it is ARM specific, because I was able to make it happen by
running qemu-x86_64 under a uclibc-ng chroot.  It has something to do with
the way uclibc-ng executes dlclose() on certain shared libraries.  If I
compile the following basic snippet:


#include <dlfcn.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>

int main() {
 void* v = dlopen( "/usr/lib/syslog-ng/libdbparser.so", RTLD_LAZY |
RTLD_GLOBAL
);
 if( ! v ) fprintf( stderr, "failed to open" );
 if( 0 != dlclose( v )) {
   fprintf( stderr, "%s\n", strerror( errno ));
 }
 return 0;
}


It segfaults under qemu-x86_64 (and ARM), with the following backtrace:


#0  0x00000000601c38b0 in raise ()
#1  0x00000000601c3e6a in abort ()
#2  0x00000000601bd9a1 in __assert_fail_base ()
#3  0x00000000601bda22 in __assert_fail ()
#4  0x0000000060036c3e in page_set_flags (start=274891239424, end=2232320,
flags
=0) at
/usr/src/debug/app-emulation/qemu-2.11.0/qemu-2.11.0/accel/tcg/translate-
all.c:2078
#5  0x000000006005f010 in target_munmap (start=274891239424,
len=184467437988205
44512) at
/usr/src/debug/app-emulation/qemu-2.11.0/qemu-2.11.0/linux-user/mmap.c
:667
#6  0x00000000600526e4 in do_syscall (cpu_env=0x62619160, num=11,
arg1=274891239
424, arg2=-274889010896, arg3=6, arg4=123096, arg5=274891109664,
arg6=2228528, a
rg7=0, arg8=0) at
/usr/src/debug/app-emulation/qemu-2.11.0/qemu-2.11.0/linux-use
r/syscall.c:9304
#7  0x000000006003ad3a in cpu_loop (env=0x62619160) at
/usr/src/debug/app-emulat
ion/qemu-2.11.0/qemu-2.11.0/linux-user/main.c:252
#8  0x000000006003cc41 in main (argc=2, argv=0x7fffffffe578,
envp=0x7fffffffe590
) at
/usr/src/debug/app-emulation/qemu-2.11.0/qemu-2.11.0/linux-user/main.c:4882


I have found that after bisecting uclibc-ng between 1.0.25 and 1.0.26, the
commit causing this behaviour is:

https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=952bb00f0b2eb576b0bf48c4f87018429a42e28d

I am completely out of my depth here, I don't know the design other either
qemu-user, or the dlopen/dlclose of a C library.  Clearly start>end, but I
don't even know what those represent.  Can anyone suggest how we can
further this and find a fix?  Right now my workaround is to revert the
above commit.

Cheers,
Dave


reply via email to

[Prev in Thread] Current Thread [Next in Thread]