qemu-devel
[Top][All Lists]
Advanced

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

Re: tst-arm-mte bug: PSTATE.TCO is cleared on exceptions


From: Szabolcs Nagy
Subject: Re: tst-arm-mte bug: PSTATE.TCO is cleared on exceptions
Date: Thu, 7 May 2020 10:59:03 +0100
User-agent: Mutt/1.9.4 (2018-02-28)

The 05/06/2020 13:57, Szabolcs Nagy wrote:
> However later on during testing malloc with PROT_MTE
> i got a qemu assert failure:
> 
> Bail out! ERROR:/S/target/arm/mte_helper.c:97:allocation_tag_mem: assertion 
> failed: (tag_size <= in_page)
> 
> i can reproduce it, but i don't know how to debug it
> further, i don't know what the application is doing
> when this happens, nor what the kernel is doing.

actually i know what the application is doing,
it's in an mmap when qemu aborts:

...
23:15:17.379227 munmap(0x100ffff9675a000, 8192) = 0
23:15:17.428456 mmap(NULL, 8192, PROT_READ|PROT_WRITE|0x20, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff9675a000
23:15:17.502543 mmap(NULL, 36864, PROT_READ|PROT_WRITE|0x20, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff96707000
23:15:17.572469 munmap(0x100ffff96707000, 36864) = 0
23:15:17.645050 munmap(0x100ffff9675a000, 8192) = 0
23:15:17.721526 mmap(NULL, 8192, PROT_READ|PROT_WRITE|0x20, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff9675a000
23:15:17.779768 mmap(NULL, 36864, PROT_READ|PROT_WRITE|0x20, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff96707000
23:15:17.840278 newfstatat(3, "usr/lib", {st_mode=S_IFDIR|0755, st_size=4096, 
...}, AT_SYMLINK_NOFOLLOW) = 0
23:15:18.164292 unlinkat(3, 
"usr/lib/.apk.1e1bebb420b720c23f29fc2cacd5581b598339805fd12c00", 0) = 0
23:15:18.357742 symlinkat("libXau.so.6.0.0", 3, 
"usr/lib/.apk.1e1bebb420b720c23f29fc2cacd5581b598339805fd12c00") = 0
23:15:18.469921 fchownat(3, 
"usr/lib/.apk.1e1bebb420b720c23f29fc2cacd5581b598339805fd12c00", 0, 0, 
AT_SYMLINK_NOFOLLOW) = 0
23:15:18.638698 unlinkat(3, 
"usr/lib/.apk.93d31976aebb056b6e2d9577dc8a2f112e28756d03f736a4", 0) = 0
23:15:18.760374 openat(3, 
"usr/lib/.apk.93d31976aebb056b6e2d9577dc8a2f112e28756d03f736a4", 
O_RDWR|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0755) = 8
23:15:18.916049 write(8, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\300\r\0\0\0\0\0\0@\0\0\0\0\0\0\0\3700\0\0\0\0\0\0\0\0\0\0@\08\0\6\0@\0\26\0\25\0\1\0\0\0\5\0"...,
 13944) = 13944
23:15:18.961239 close(8)                = 0
23:15:20.137627 fchownat(3, 
"usr/lib/.apk.93d31976aebb056b6e2d9577dc8a2f112e28756d03f736a4", 0, 0, 0) = 0
23:15:20.289924 utimensat(3, 
"usr/lib/.apk.93d31976aebb056b6e2d9577dc8a2f112e28756d03f736a4", 
[{tv_sec=1579395233, tv_nsec=0} /* 2020-01-19T00:53:53+0000 */, 
{tv_sec=1579395233, tv_nsec=0} /* 2020-01-19T00:53:53+0000 */], 0) = 0
23:15:20.467212 munmap(0x100ffff96707000, 36864) = 0
23:15:20.503631 munmap(0x100ffff9675a000, 8192) = 0
23:15:20.550130 mmap(NULL, 8192, PROT_READ|PROT_WRITE|0x20, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0Connection to localhost closed by remote host.

(this allocator does a lot of small mmap and munmap)

but i cant tell what happens on the kernel side.

is there some recommended way to turn some form
of tracing on in qemu before i execute the
problematic application?

or is it better if i try to extract a reproducer?
(that does not use the network)

> 
> i rebuilt qemu with --enable-debug but now it's very
> slow (still booting into linux 3h later).

this is too slow, things time out.



reply via email to

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