From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MaI7R-0004PF-7w
	for qemu-devel@nongnu.org; Sun, 09 Aug 2009 19:48:05 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MaI7M-0004NC-D7
	for qemu-devel@nongnu.org; Sun, 09 Aug 2009 19:48:04 -0400
Received: from [199.232.76.173] (port=54377 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MaI7M-0004N5-5B
	for qemu-devel@nongnu.org; Sun, 09 Aug 2009 19:48:00 -0400
Received: from mail.gmx.net ([213.165.64.20]:44282)
	by monty-python.gnu.org with smtp (Exim 4.60)
	(envelope-from <dl9pf@gmx.de>) id 1MaI7L-0006B5-Ee
	for qemu-devel@nongnu.org; Sun, 09 Aug 2009 19:47:59 -0400
From: "Jan-Simon =?utf-8?q?M=C3=B6ller?=" <dl9pf@gmx.de>
Date: Mon, 10 Aug 2009 01:45:52 +0200
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200908100145.52476.dl9pf@gmx.de>
Subject: [Qemu-devel] qemu-arm fails on test-mmap - take #2
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>

Hi !

This is a follow-up to my tests about test-mmap failing inside an arm chroot 
when using qemu-arm in user-mode.

Here are 2 snippets running   "qemu-arm ./test-mmap"  outside and inside the 
ARM chroot env.

I turned DEBUG_MMAP on in linux-user/mmap.c .

legolas:/var/tmp/build-root # ./usr/bin/qemu-arm test-mmap
------snip-------
mmap: start=0x00000000 len=0x00001000 prot=r-- flags=MAP_ANON MAP_PRIVATE 
fd=-1 offset=00000000
ret=0x40b77000
start    end      size     prot
00008000-00081000 00079000 r-x
00088000-0008a000 00002000 rw-
0008a000-0008c000 00002000 rwx
0008c000-000af000 00023000 rw-
40000000-40080000 00080000 rw-
40080000-40081000 00001000 ---
40081000-40082000 00001000 rw-
40339000-40347000 0000e000 ---
407d6000-407d7000 00001000 ---
4096b000-40974000 00009000 ---
40b76000-40b78000 00002000 r--
40e8a000-40e8c000 00002000 ---
41dc7000-455ca000 03803000 ---
60000000-60166000 00166000 ---
60266000-6231d000 020b7000 ---
------snip-------

Note the last 2 lines !!

Now same procedure inside the chroot ...
legolas:/> chroot /var/tmp/build-root
legolas:/> ./test-mmap

------snip-------
mmap: start=0x00000000 len=0x00001000 prot=r-- flags=MAP_ANON MAP_PRIVATE 
fd=-1 offset=00000000
ret=0x40b74000
start    end      size     prot
00008000-00081000 00079000 r-x
00088000-0008a000 00002000 rw-
0008a000-0008c000 00002000 rwx
0008c000-000af000 00023000 rw-
40000000-40080000 00080000 rw-
40080000-40081000 00001000 ---
40081000-40082000 00001000 rw-
40191000-40192000 00001000 ---
40b73000-40b75000 00002000 r--
40c6c000-40c75000 00009000 ---
41105000-41106000 00001000 ---
41283000-44a95000 03812000 ---
------snip-------


The lines with 60000000-60166000 are gone ... 
Thus as soon as those pages will get allocated  it will segfault.

This is reproducible on different machines:
1)
openSUSE 11.1 64bit on Core 2 Duo  with 2GB Ram, qemu git head
The ARM chroot uses gcc4.4 and glibc 2.10.1 .

2)
openSUSE 11.0 32bit  Athlon XP 2GB RAM, same qemu, same chroot


Now my question is: how is the data of the already blocked pages 
processed/aquired ? It seems to me that the pages get "lost" somewhere.


Best,
Jan-Simon