[Qemu-devel] [Bug 1711316] Re: fbsd strip(1) segfaults on aarch64
*** This bug is a duplicate of bug 1713066 ***
https://bugs.launchpad.net/bugs/1713066
** This bug has been marked a duplicate of bug 1713066
Incorrect handling of aarch64 ldp in some cases
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1711316
Title:
fbsd strip(1) segfaults on aarch64
Status in QEMU:
New
Bug description:
Hello,
During port builds ld.lld(devel/boost-libs, www/node), and strip
(textproc/libxml2 on xmlcatalog) are segfaulting. On physical boxes
these things do work, as they should:
root@build-aarch64:~ # strip xmlcatalog
Segmentation fault (core dumped)
All the cores fail at the same assembly instruction, here's strip's backtrace:
# lldb -c strip.core strip
(lldb) target create "strip" --core "strip.core"
Core file '/root/strip.core' (aarch64) was loaded.
(lldb) t 1
* thread #1, name = 'strip', stop reason = signal SIGSEGV
frame #0: 0x40312f40 libc.so.7`memcpy + 192
libc.so.7`memcpy:
-> 0x40312f40 <+192>: ldpx4, x3, [x4, #-0x10]
0x40312f44 <+196>: stpx6, x7, [x0]
0x40312f48 <+200>: stpx8, x9, [x0, #0x10]
0x40312f4c <+204>: stpx10, x11, [x0, #0x20]
(lldb) bt
* thread #1, name = 'strip', stop reason = signal SIGSEGV
* frame #0: 0x40312f40 libc.so.7`memcpy + 192
frame #1: 0x4017ac70
libelf.so.2`_libelf_cvt_HALF_tom(dst=, dsz=,
src=, count=, byteswap=) at
libelf_convert.c:794
frame #2: 0x40177b34
libelf.so.2`elf_getdata(s=0x40f355a0, ed=) at
elf_data.c:155
frame #3: 0x000283d4 strip`copy_data(s=0x40f36a40) at
sections.c:1176
frame #4: 0x00027ea4 strip`copy_content(ecp=) at
sections.c:594
frame #5: 0x00023ff4 strip`create_elf(ecp=0x40ed6000) at
main.c:381
frame #6: 0x0002558c strip`create_file(ecp=,
src=, dst=) at main.c:705
frame #7: 0x00024e20 strip`main [inlined]
strip_main(argc=, argv=) at main.c:1192
frame #8: 0x00024cc8 strip`main(argc=,
argv=) at main.c:1590
frame #9: 0x00020190 strip`__start + 376
frame #10: 0x40050018 ld-elf.so.1`.rtld_start at rtld_start.S:41
Host system information:
# uname -a
FreeBSD marvin.harmless.hu 11.0-STABLE FreeBSD 11.0-STABLE #0 r311927: Wed
Jan 11 14:53:55 CET 2017
t...@marvin.harmless.hu:/usr/obj/usr/src/sys/MARVIN amd64
# qemu-system-aarch64 --version
QEMU emulator version 2.9.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
# pkg info | grep qemu
qemu-2.9.0 QEMU CPU Emulator
I also had this happening with 2.8.0 and 2.8.1
Guest information:
# uname -a
FreeBSD build-aarch64.marvin.harmless.hu 12.0-CURRENT FreeBSD 12.0-CURRENT #0
r322578: Wed Aug 16 18:08:43 CEST 2017
t...@marvin.harmless.hu:/tank/rpi3/obj/arm64.aarch64/tank/rpi3/src/sys/GENERIC-NODEBUG
arm64
Startup:
zdev=/dev/zvol/tank/rpi3/qemu-image
qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \
-accel tcg,thread=single \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=${image},id=hd0,format=raw \
-device virtio-blk-device,drive=hd0 \
-device e1000,netdev=net0 \
-netdev
tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh
Tested with cortex A53 as well, does the same.
I've attached a test image to reproduce with (340MB), if it's too big for an
attachment, it can be downloaded from here:
http://czg.harmless.hu/qemu-bug-stripsigsegv/image.gz
Reproduction steps:
1) log in as root, no password
2) strip xmlcatalog, it will segfault
For a full reproduction with ld.lld as well, you need a ports tree, it's
suggested to attach a bigger volume to /usr/ports over NFS first (it might need
more space than the image has). Steps for it:
1) portsnap fetch extract
2) make -C /usr/ports/devel/boost-libs package-recursive
3) make -C /usr/ports/textproc/libxml2 package-recursive
4) make -C /usr/ports/www/node package-recursive
Boost and node can take a day or more in a qemu VM. The build-time
options I've be set already, /var/db/ports is populated, so you
shouldn't have questions asked during the builds.
I've saved the core dumps, those can be found at /root/cores/ in the
image.
I hope I've submitted all the required information. If anything else
is needed, please let me know.
Best regards,
Gergely
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1711316/+subscriptions
[Qemu-devel] [Bug 1713066] Re: Incorrect handling of aarch64 ldp in some cases
This might be the cause for my bugreport: https://bugs.launchpad.net/qemu/+bug/1711316 Marked mine as a duplicate of this, please correct me if I'm wrong. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1713066 Title: Incorrect handling of aarch64 ldp in some cases Status in QEMU: New Bug description: In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. Given the following instruction: ldp x0, x1, [x0] This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. I've observed this on: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard And checked I still get the same behaviour on: QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1713066/+subscriptions
[Qemu-devel] [Bug 1711316] [NEW] fbsd strip(1) segfaults on aarch64
Public bug reported:
Hello,
During port builds ld.lld(devel/boost-libs, www/node), and strip
(textproc/libxml2 on xmlcatalog) are segfaulting. On physical boxes
these things do work, as they should:
root@build-aarch64:~ # strip xmlcatalog
Segmentation fault (core dumped)
All the cores fail at the same assembly instruction, here's strip's backtrace:
# lldb -c strip.core strip
(lldb) target create "strip" --core "strip.core"
Core file '/root/strip.core' (aarch64) was loaded.
(lldb) t 1
* thread #1, name = 'strip', stop reason = signal SIGSEGV
frame #0: 0x40312f40 libc.so.7`memcpy + 192
libc.so.7`memcpy:
-> 0x40312f40 <+192>: ldpx4, x3, [x4, #-0x10]
0x40312f44 <+196>: stpx6, x7, [x0]
0x40312f48 <+200>: stpx8, x9, [x0, #0x10]
0x40312f4c <+204>: stpx10, x11, [x0, #0x20]
(lldb) bt
* thread #1, name = 'strip', stop reason = signal SIGSEGV
* frame #0: 0x40312f40 libc.so.7`memcpy + 192
frame #1: 0x4017ac70
libelf.so.2`_libelf_cvt_HALF_tom(dst=, dsz=,
src=, count=, byteswap=) at
libelf_convert.c:794
frame #2: 0x40177b34 libelf.so.2`elf_getdata(s=0x40f355a0,
ed=) at elf_data.c:155
frame #3: 0x000283d4 strip`copy_data(s=0x40f36a40) at
sections.c:1176
frame #4: 0x00027ea4 strip`copy_content(ecp=) at
sections.c:594
frame #5: 0x00023ff4 strip`create_elf(ecp=0x40ed6000) at
main.c:381
frame #6: 0x0002558c strip`create_file(ecp=,
src=, dst=) at main.c:705
frame #7: 0x00024e20 strip`main [inlined]
strip_main(argc=, argv=) at main.c:1192
frame #8: 0x00024cc8 strip`main(argc=,
argv=) at main.c:1590
frame #9: 0x00020190 strip`__start + 376
frame #10: 0x40050018 ld-elf.so.1`.rtld_start at rtld_start.S:41
Host system information:
# uname -a
FreeBSD marvin.harmless.hu 11.0-STABLE FreeBSD 11.0-STABLE #0 r311927: Wed Jan
11 14:53:55 CET 2017 t...@marvin.harmless.hu:/usr/obj/usr/src/sys/MARVIN
amd64
# qemu-system-aarch64 --version
QEMU emulator version 2.9.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
# pkg info | grep qemu
qemu-2.9.0 QEMU CPU Emulator
I also had this happening with 2.8.0 and 2.8.1
Guest information:
# uname -a
FreeBSD build-aarch64.marvin.harmless.hu 12.0-CURRENT FreeBSD 12.0-CURRENT #0
r322578: Wed Aug 16 18:08:43 CEST 2017
t...@marvin.harmless.hu:/tank/rpi3/obj/arm64.aarch64/tank/rpi3/src/sys/GENERIC-NODEBUG
arm64
Startup:
zdev=/dev/zvol/tank/rpi3/qemu-image
qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \
-accel tcg,thread=single \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=${image},id=hd0,format=raw \
-device virtio-blk-device,drive=hd0 \
-device e1000,netdev=net0 \
-netdev
tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh
Tested with cortex A53 as well, does the same.
I've attached a test image to reproduce with (340MB), if it's too big for an
attachment, it can be downloaded from here:
http://czg.harmless.hu/qemu-bug-stripsigsegv/image.gz
Reproduction steps:
1) log in as root, no password
2) strip xmlcatalog, it will segfault
For a full reproduction with ld.lld as well, you need a ports tree, it's
suggested to attach a bigger volume to /usr/ports over NFS first (it might need
more space than the image has). Steps for it:
1) portsnap fetch extract
2) make -C /usr/ports/devel/boost-libs package-recursive
3) make -C /usr/ports/textproc/libxml2 package-recursive
4) make -C /usr/ports/www/node package-recursive
Boost and node can take a day or more in a qemu VM. The build-time
options I've be set already, /var/db/ports is populated, so you
shouldn't have questions asked during the builds.
I've saved the core dumps, those can be found at /root/cores/ in the
image.
I hope I've submitted all the required information. If anything else is
needed, please let me know.
Best regards,
Gergely
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1711316
Title:
fbsd strip(1) segfaults on aarch64
Status in QEMU:
New
Bug description:
Hello,
During port builds ld.lld(devel/boost-libs, www/node), and strip
(textproc/libxml2 on xmlcatalog) are segfaulting. On physical boxes
these things do work, as they should:
root@build-aarch64:~ # strip xmlcatalog
Segmentation fault (core dumped)
All the cores fail at the same assembly instruction, here's strip's backtrace:
# lldb -c strip.core strip
(lldb) target create "strip" --core "strip.core"
Core file '/root/strip.core' (aarch64) was loaded.
(lldb) t 1
* thread #1, name = 'strip', stop reason = signal SIGSEGV
frame #0: 0x40312f40
