From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvTQS-00046b-5S for qemu-devel@nongnu.org; Wed, 16 Jan 2013 08:53:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TvTQJ-0007fc-W1 for qemu-devel@nongnu.org; Wed, 16 Jan 2013 08:53:07 -0500 Received: from indium.canonical.com ([91.189.90.7]:47942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvTQJ-0007fU-Nj for qemu-devel@nongnu.org; Wed, 16 Jan 2013 08:52:59 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1TvTQH-00079f-Pb for ; Wed, 16 Jan 2013 13:52:57 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 30B132E8367 for ; Wed, 16 Jan 2013 13:45:37 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jan 2013 13:36:46 -0000 From: Jens Melzer Sender: bounces@canonical.com References: <20120811075758.14549.82954.malonedeb@chaenomeles.canonical.com> Message-Id: <20130116133646.8484.78914.launchpad@soybean.canonical.com> Errors-To: bounces@canonical.com Subject: [Qemu-devel] [Bug 1035572] Re: Bug in Qemu User Mode Reply-To: Bug 1035572 <1035572@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org *** This bug is a duplicate of bug 739785 *** https://bugs.launchpad.net/bugs/739785 ** This bug has been marked a duplicate of bug 739785 qemu-i386 user mode can't fork (bash: fork: Invalid argument) -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1035572 Title: Bug in Qemu User Mode Status in QEMU: New Bug description: Hi, I make an interesting discovery. My aim is to have a working qemu-i386 on Raspberry Pi. After long searching in the dark what goes wrong with ANY Qemu version fo= r User Mode until today, I find the following: The bug must be in at least one function, that the = program testclone from the testpackage for i386 in linux-user-test-0.3 calls. The wrong function is in the part, which enables more than one thread at = the same time, NPTL. Funny, how I find this out: All the programs from the tests in linux-user= -test-0.3 I can now run succesfull with my new builded qemu-i386 for Raspi. But the program testclone does not stop after it gives out all the right = messages. The program testclone stops on my Desktop computer with Debian Wheezy ins= talled. So, the error is not in the program testclone. So I make a look, what is going on there with strace. With strace you get= informations about all the values in the working program, here testclone. I see, that the reason, why testclone not stops is in an infinite loop be= cause of = while (waitpid(pid1, &status1, 0) !=3D pid1); while (waitpid(pid2, &status2, 0) !=3D pid2); at its end is never fullfilled. = This is the reason for the famous error message from Qemu User Mode = qemu: uncaught target signal 11 (Segmentation fault) - core dumped = Segmentation fault = stack1 =3D malloc(STACK_SIZE); pid1 =3D clone(thread1_func, stack1 + STACK_SIZE, CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello1"); stack2 =3D malloc(STACK_SIZE); pid2 =3D clone(thread2_func, stack2 + STACK_SIZE, = CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello2"); The error happens early in the program testclone. Strace says, it is beca= use no childprocess at all can be found. So, some basiccalculations in thos= e four lines must be done wrong from Qemu. I think, that the adressspace for each thread is calculated wrong, or ove= rlapps. Funny, it has nothing to do with the ARM processor. I get exact the same = errormessages, when I run the program testclone on my desktopcompi i386 wit= h a Wheezy in Qemu and then qemu-i386 testclone. This is a good message, because it means it is an error, that belongs at = least to the i386 family but I think, every processor in Qemu User Mode is = involved, so until now NPTL does not work. Today I make a hand by hand calculation with the source code from testclo= ne and compare it with the values, that Qemu User Mode give. The handcalcul= ated values should be the same which my = Desktop computer with Wheezy with tesclone produces, but who knows, Dietmar PS: I hope, that this is the right source code for testclone. Any help is welcome:-)! = Code: Select all #include #include #include #include #include #include #include #include #include int thread1_func(void *arg) { int i; char buf[512]; for(i=3D0;i<10;i++) { snprintf(buf, sizeof(buf), "thread1: %d %s\n", i, (char *)arg); write(1, buf, strlen(buf)); usleep(100 * 1000); } return 0; } int thread2_func(void *arg) { int i; char buf[512]; for(i=3D0;i<20;i++) { snprintf(buf, sizeof(buf), "thread2: %d %s\n", i, (char *)arg); write(1, buf, strlen(buf)); usleep(120 * 1000); } return 0; } #define STACK_SIZE 16384 void test_clone(void) { uint8_t *stack1, *stack2; int pid1, pid2, status1, status2; stack1 =3D malloc(STACK_SIZE); pid1 =3D clone(thread1_func, stack1 + STACK_SIZE, = CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello1"); stack2 =3D malloc(STACK_SIZE); pid2 =3D clone(thread2_func, stack2 + STACK_SIZE, = CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello2"); while (waitpid(pid1, &status1, 0) !=3D pid1); while (waitpid(pid2, &status2, 0) !=3D pid2); printf("status1=3D0x%x\n", status1); printf("status2=3D0x%x\n", status2); printf("End of clone test.\n"); } int main(int argc, char **argv) { test_clone(); return 0; } Posts: 210 Joined: 04 Sep 2011 17:43 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1035572/+subscriptions