Bugzilla – Bug 1084812
[aarch64] IPv4 DNS leading to segfaults
Last modified: 2020-12-09 11:17:09 UTC
After a zypper dup to latest 20180305 on aarch64 based Raspberry Pi 3, commands such as zypper or ping segfault. Observed both on 4.15.4 and 4.16-rc4. Same observation on other aarch64 devices (e.g., Odroid-C2). # ping google.com Segmentation fault (core dumped) # ping6 google.com PING google.com(fra15s28-in-x0e.1e100.net (2a00:1450:4001:80b::200e)) 56 data bytes 64 bytes from fra15s28-in-x0e.1e100.net (2a00:1450:4001:80b::200e): icmp_seq=1 ttl=57 time=14.0 ms ... This issue is prohibiting further zypper dup's. On armv7hl, Tumbleweed is already at 20180309 and no such symptoms are observed.
20180305: https://lists.opensuse.org/opensuse-factory/2018-03/msg00095.html 20180306: https://lists.opensuse.org/opensuse-factory/2018-03/msg00131.html 20180307: https://lists.opensuse.org/opensuse-factory/2018-03/msg00145.html 20180308: https://lists.opensuse.org/opensuse-factory/2018-03/msg00164.html 20180309: https://lists.opensuse.org/opensuse-factory/2018-03/msg00242.html Nothing immediately stands out as related...
(In reply to Andreas Färber from comment #0) > ... > This issue is prohibiting further zypper dup's. Workaround: add "195.135.221.134 download.opensuse.org" to /etc/hosts
crash is in glibc: Program received signal SIGSEGV, Segmentation fault. gaih_getanswer_slice (answer=answer@entry=0xaaaaaab0a620, anslen=anslen@entry=58, patp=0xffffffffeac0, patp@entry=0xffffffffeb30, bufferp=0xffffffffeac8, bufferp@entry=0xffffffffeb38, buflenp=0xffffffffead0, buflenp@entry=0xffffffffeb40, errnop=errnop@entry=0xffffbf1aa720, h_errnop=h_errnop@entry=0xffffbf1aa784, ttlp=ttlp@entry=0x0, firstp=0xffffffffeaac, firstp@entry=0xffffffffeb1c, qname=0x3a <error: Cannot access memory at address 0x3a>) at nss_dns/dns-host.c:992 992 gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname, (gdb) bt #0 gaih_getanswer_slice (answer=answer@entry=0xaaaaaab0a620, anslen=anslen@entry=58, patp=0xffffffffeac0, patp@entry=0xffffffffeb30, bufferp=0xffffffffeac8, bufferp@entry=0xffffffffeb38, buflenp=0xffffffffead0, buflenp@entry=0xffffffffeb40, errnop=errnop@entry=0xffffbf1aa720, h_errnop=h_errnop@entry=0xffffbf1aa784, ttlp=ttlp@entry=0x0, firstp=0xffffffffeaac, firstp@entry=0xffffffffeb1c, qname=0x3a <error: Cannot access memory at address 0x3a>) at nss_dns/dns-host.c:992 #1 0x0000ffffbf1099dc in gaih_getanswer (qname=0x3a <error: Cannot access memory at address 0x3a>, ttlp=0x0, h_errnop=0xffffbf1aa784, errnop=0xffffbf1aa720, buflen=<optimized out>, buffer=<optimized out>, pat=0xffffffffec30, anslen2=58, answer2=0xaaaaaab0a620, anslen1=<optimized out>, answer1=<optimized out>) at nss_dns/dns-host.c:1352 #2 _nss_dns_gethostbyname4_r (name=name@entry=0xfffffffff861 "www.heise.de", pat=pat@entry=0xffffffffec30, buffer=<optimized out>, buflen=<optimized out>, errnop=errnop@entry=0xffffbf1aa720, herrnop=herrnop@entry=0xffffbf1aa784, ttlp=ttlp@entry=0x0) at nss_dns/dns-host.c:356 One thing is strange - according to nss_dns/dns-host.c:992, the function signature is: static enum nss_status gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname, struct gaih_addrtuple ***patp, char **bufferp, size_t *buflenp, int *errnop, int *h_errnop, int32_t *ttlp, int *firstp)
There seems to be a problem with static functions with a large number of arguments. I removed the "static" from gaih_answer{,_slice} for testing purposes, and it no longer crashes. Also the backtrace for gaih_answer_slice looks sane again: #0 gaih_getanswer_slice (answer=0xffffffffe220, anslen=46, qname=qname@entry=0xfffffffff861 "www.heise.de", patp=0xffffffffe1e8, patp@entry=0xffffffffe228, bufferp=0xffffffffe1e0, bufferp@entry=0xffffffffe220, buflenp=0xffffffffe1d8, buflenp@entry=0xffffffffe218, errnop=errnop@entry=0xffffbf1aa720, h_errnop=h_errnop@entry=0xffffbf1aa784, ttlp=ttlp@entry=0x0, firstp=0xffffffffe1f4, firstp@entry=0xffffffffe234) at nss_dns/dns-host.c:996 #1 0x0000ffffbf109d84 in gaih_getanswer (answer1=<optimized out>, anslen1=<optimized out>, answer2=0xaaaaaab0a600, anslen2=58, qname=qname@entry=0xfffffffff861 "www.heise.de", pat=<optimized out>, pat@entry=0xffffffffec30, buffer=<optimized out>, buffer@entry=0xffffffffeeb0 "\377\002", buflen=<optimized out>, buflen@entry=1024, errnop=errnop@entry=0xffffbf1aa720, h_errnop=h_errnop@entry=0xffffbf1aa784, ttlp=ttlp@entry=0x0) at nss_dns/dns-host.c:1336 For testing, the patched glibc is available here: https://build.opensuse.org/package/show/home:StefanBruens:branches:openSUSE:Factory:ARM/glibc
Hi Grabbed the binaries via osc on a local machine since osc isn't working on the target machine.. copied over to target machine and installed via zypper; osc getbinaries home:StefanBruens:branches:openSUSE:Factory:ARM openSUSE_Factory_ARM aarch64 zypper in glibc-2.27-482.1.aarch64.rpm glibc-devel-2.27-482.1.aarch64.rpm glibc-extra-2.27-482.1.aarch64.rpm glibc-locale-2.27-482.1.aarch64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following 4 packages are going to be upgraded: glibc glibc-devel glibc-extra glibc-locale The following 4 packages are going to change vendor: glibc openSUSE -> obs://build.opensuse.org/home:StefanBruens glibc-devel openSUSE -> obs://build.opensuse.org/home:StefanBruens glibc-extra openSUSE -> obs://build.opensuse.org/home:StefanBruens glibc-locale openSUSE -> obs://build.opensuse.org/home:StefanBruens Then removed temporary host names/ip addresses from /etc/hosts and /etc/ntpd.conf and rebooted. Time is now correct, zypper, ping etc commands working as expected.
Most likely a compiler bug, try reducing the opt level for this file.
Also, please try building with gcc8.
*** Bug 1084419 has been marked as a duplicate of this bug. ***
*** Bug 1084796 has been marked as a duplicate of this bug. ***
Also after installation of python2-pip giving the command "pip > /dev/null" gives an error; illegal instruction.
Created attachment 764072 [details] coredump of pip giving "pip > /dev/null" coredump core.pip.0.7ab8585d52fa4b8bac8f8b48cd6458e9.5302.1521446537000000.lz4
Program terminated with signal SIGILL, Illegal instruction. #0 0x0000ffffaf7b0f88 in ?? () from /tmp/aarchp/usr/lib64/libpython2.7.so.1.0 (gdb) up #1 0x0000ffffaf7a86f4 in ?? () from /tmp/aarchp/usr/lib64/libpython2.7.so.1.0 (gdb) disassemble No function contains program counter for selected frame. (gdb) up #2 0x0000ffffaf827638 in _PyEval_SliceIndexNotNone () from /tmp/aarchp/usr/lib64/libpython2.7.so.1.0 (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x0000ffffaf70ad00 0x0000ffffaf846570 Yes (*) /tmp/aarchp/usr/lib64/libpython2.7.so.1.0 0x0000ffffaf697660 0x0000ffffaf6a5e24 Yes (*) /tmp/aarchp/lib64/libpthread.so.0 0x0000ffffaf52b7a8 0x0000ffffaf6203d0 Yes (*) /tmp/aarchp/lib64/libc.so.6 0x0000ffffaf4ebf10 0x0000ffffaf4ecc5c Yes (*) /tmp/aarchp/lib64/libdl.so.2 0x0000ffffaf4cb020 0x0000ffffaf4cb928 Yes (*) /tmp/aarchp/lib64/libutil.so.1 0x0000ffffaf40ece0 0x0000ffffaf463460 Yes (*) /tmp/aarchp/lib64/libm.so.6 No /lib/ld-linux-aarch64.so.1 0x0000ffffaf2a8db0 0x0000ffffaf2aa4ec Yes (*) /tmp/aarchp/usr/lib64/python2.7/lib-dynload/_locale.so (*): Shared library is missing debugging information. note I can't find the exact binary rpms for python/glibc matching the core file. (gdb) disassemble 0x0000ffffaf7b0f80,0x0000ffffaf7b0f90 Dump of assembler code from 0xffffaf7b0f80 to 0xffffaf7b0f90: 0x0000ffffaf7b0f80: str xzr, [x20, #32] 0x0000ffffaf7b0f84: ldr x17, [x0] 0x0000ffffaf7b0f88: sub x18, x17, #0x1 0x0000ffffaf7b0f8c: str x18, [x0] so that's not helpful. Can you please provide at least the python2.rpm that matches the core file?
Not reproducable on mudan1.
Created attachment 764165 [details] python-2.7.14-6.1.aarch64.rpm from http://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/suse/aarch64/ The requested rpm of python(2)
Maybe you need python-base-2.7.14-6.1.aarch64.rpm also.
@Freek/Andreas/Richard: A plain `pip > /dev/null` does not fail on my system. But `pip list` > /dev/null` fails: ``` jeroenp@donald:/tmp> pip > /dev/null jeroenp@donald:/tmp> pip list > /dev/null DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning. Segmentation fault (core dumped) jeroenp@donald:/tmp> pip --version pip 9.0.1 from /usr/lib/python3.6/site-packages (python 3.6) jeroenp@donald:/tmp> python --version Python 2.7.14 jeroenp@donald:/tmp> rpm -qa | grep libpython libpython3_6m1_0-3.6.4-5.1.aarch64 libpython2_7-1_0-2.7.14-6.1.aarch64 jeroenp@donald:/tmp> rpm -qa | grep python | grep base python-base-2.7.14-6.1.aarch64 python3-base-3.6.4-5.1.aarch64 jeroenp@donald:/tmp> ``` I'm not proficient at Linux programming, but a quick search indicated the `LD_PRELOAD=libSegFault.so` trick ensures there is a stack trace, so below is the output (also revealing that pip uses python 3.6, not 2.7). I like learning, so let me know how I can help pin this down further. ``` jeroenp@donald:/tmp> LD_PRELOAD=libSegFault.so pip list > /dev/null DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning. *** Segmentation fault Backtrace: /lib64/libnss_dns.so.2(+0x200c)[0xffff9dd0c00c] /lib64/libnss_dns.so.2(_nss_dns_gethostbyname4_r+0x1fc)[0xffff9dd0c9dc] /lib64/libc.so.6(+0xc0780)[0xffff9fdc4780] /lib64/libc.so.6(getaddrinfo+0xd8)[0xffff9fdc5330] /usr/lib64/python3.6/lib-dynload/_socket.cpython-36m-aarch64-linux-gnu.so(+0x5dd4)[0xffff9efb4dd4] /usr/lib64/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x174)[0xffff9ff93c84] /usr/lib64/libpython3.6m.so.1.0(+0x13b2a8)[0xffff9fffa2a8] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(+0x13ba0c)[0xffff9fffaa0c] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x2c0)[0xffff9fff0660] /usr/lib64/libpython3.6m.so.1.0(+0xadeec)[0xffff9ff6ceec] /usr/lib64/libpython3.6m.so.1.0(PyObject_Call+0x54)[0xffff9ff50f0c] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1ad0)[0xffff9fff2cd8] /usr/lib64/libpython3.6m.so.1.0(+0x13b730)[0xffff9fffa730] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(+0x13b730)[0xffff9fffa730] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(+0x13ba0c)[0xffff9fffaa0c] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(+0x13ba0c)[0xffff9fffaa0c] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1220)[0xffff9fff2428] /usr/lib64/libpython3.6m.so.1.0(+0x13ba0c)[0xffff9fffaa0c] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1220)[0xffff9fff2428] /usr/lib64/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x44c)[0xffff9fffc59c] /usr/lib64/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x140)[0xffff9ff509e8] /usr/lib64/libpython3.6m.so.1.0(_PyObject_Call_Prepend+0x78)[0xffff9ff51760] /usr/lib64/libpython3.6m.so.1.0(PyObject_Call+0x54)[0xffff9ff50f0c] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1ad0)[0xffff9fff2cd8] /usr/lib64/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x44c)[0xffff9fffc59c] /usr/lib64/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x140)[0xffff9ff509e8] /usr/lib64/libpython3.6m.so.1.0(_PyObject_Call_Prepend+0x78)[0xffff9ff51760] /usr/lib64/libpython3.6m.so.1.0(PyObject_Call+0x54)[0xffff9ff50f0c] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1ad0)[0xffff9fff2cd8] /usr/lib64/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x44c)[0xffff9fffc59c] /usr/lib64/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x140)[0xffff9ff509e8] /usr/lib64/libpython3.6m.so.1.0(_PyObject_Call_Prepend+0x78)[0xffff9ff51760] /usr/lib64/libpython3.6m.so.1.0(PyObject_Call+0x54)[0xffff9ff50f0c] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1ad0)[0xffff9fff2cd8] /usr/lib64/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x44c)[0xffff9fffc59c] /usr/lib64/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x140)[0xffff9ff509e8] /usr/lib64/libpython3.6m.so.1.0(_PyObject_Call_Prepend+0x78)[0xffff9ff51760] /usr/lib64/libpython3.6m.so.1.0(PyObject_Call+0x54)[0xffff9ff50f0c] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1ad0)[0xffff9fff2cd8] /usr/lib64/libpython3.6m.so.1.0(_PyFunction_FastCallDict+0x44c)[0xffff9fffc59c] /usr/lib64/libpython3.6m.so.1.0(_PyObject_FastCallDict+0x140)[0xffff9ff509e8] /usr/lib64/libpython3.6m.so.1.0(_PyObject_Call_Prepend+0x78)[0xffff9ff51760] /usr/lib64/libpython3.6m.so.1.0(PyObject_Call+0x54)[0xffff9ff50f0c] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1ad0)[0xffff9fff2cd8] /usr/lib64/libpython3.6m.so.1.0(+0x13ba0c)[0xffff9fffaa0c] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x1220)[0xffff9fff2428] /usr/lib64/libpython3.6m.so.1.0(+0x13b730)[0xffff9fffa730] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(+0x13ba0c)[0xffff9fffaa0c] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(+0x1da7ac)[0xffffa00997ac] /usr/lib64/libpython3.6m.so.1.0(+0x13b3c0)[0xffff9fffa3c0] /usr/lib64/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x44c)[0xffff9fff1654] /usr/lib64/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x2c0)[0xffff9fff0660] /usr/lib64/libpython3.6m.so.1.0(PyEval_EvalCode+0x2c)[0xffff9fff0394] /usr/lib64/libpython3.6m.so.1.0(+0x1e7348)[0xffffa00a6348] /usr/lib64/libpython3.6m.so.1.0(PyRun_FileExFlags+0xa8)[0xffffa00a6ab8] /usr/lib64/libpython3.6m.so.1.0(PyRun_SimpleFileExFlags+0x198)[0xffffa00a65c0] /usr/lib64/libpython3.6m.so.1.0(Py_Main+0x868)[0xffffa00b1668] /usr/bin/python3(main+0x1dc)[0xaaaab8278e0c] /lib64/libc.so.6(__libc_start_main+0xe0)[0xffff9fd246e0] /usr/bin/python3(+0x1070)[0xaaaab8279070] Memory map: aaaab8278000-aaaab827a000 r-xp 00000000 b3:02 77059 /usr/bin/python3.6 aaaab8297000-aaaab8298000 r--p 0000f000 b3:02 77059 /usr/bin/python3.6 aaaab8298000-aaaab8299000 rw-p 00010000 b3:02 77059 /usr/bin/python3.6 aaaaed6e7000-aaaaedd4a000 rw-p 00000000 00:00 0 [heap] ffff9dca6000-ffff9dcba000 r-xp 00000000 b3:02 6705 /lib64/libgcc_s.so.1 ffff9dcba000-ffff9dcd5000 ---p 00014000 b3:02 6705 /lib64/libgcc_s.so.1 ffff9dcd5000-ffff9dcd6000 r--p 0001f000 b3:02 6705 /lib64/libgcc_s.so.1 ffff9dcd6000-ffff9dcd7000 rw-p 00020000 b3:02 6705 /lib64/libgcc_s.so.1 ffff9dcd7000-ffff9dcea000 r-xp 00000000 b3:02 65507 /lib64/libresolv-2.27.so ffff9dcea000-ffff9dd06000 ---p 00013000 b3:02 65507 /lib64/libresolv-2.27.so ffff9dd06000-ffff9dd07000 r--p 0001f000 b3:02 65507 /lib64/libresolv-2.27.so ffff9dd07000-ffff9dd08000 rw-p 00020000 b3:02 65507 /lib64/libresolv-2.27.so ffff9dd08000-ffff9dd0a000 rw-p 00000000 00:00 0 ffff9dd0a000-ffff9dd0f000 r-xp 00000000 b3:02 7613 /lib64/libnss_dns-2.27.so ffff9dd0f000-ffff9dd29000 ---p 00005000 b3:02 7613 /lib64/libnss_dns-2.27.so ffff9dd29000-ffff9dd2a000 r--p 0000f000 b3:02 7613 /lib64/libnss_dns-2.27.so ffff9dd2a000-ffff9dd2b000 rw-p 00010000 b3:02 7613 /lib64/libnss_dns-2.27.so ffff9dd2b000-ffff9dd2d000 r-xp 00000000 b3:02 7621 /lib64/libnss_mdns_minimal.so.2 ffff9dd2d000-ffff9dd4a000 ---p 00002000 b3:02 7621 /lib64/libnss_mdns_minimal.so.2 ffff9dd4a000-ffff9dd4b000 r--p 0000f000 b3:02 7621 /lib64/libnss_mdns_minimal.so.2 ffff9dd4b000-ffff9dd4c000 rw-p 00010000 b3:02 7621 /lib64/libnss_mdns_minimal.so.2 ffff9dd4c000-ffff9dd58000 r-xp 00000000 b3:02 65501 /lib64/libnss_files-2.27.so ffff9dd58000-ffff9dd6b000 ---p 0000c000 b3:02 65501 /lib64/libnss_files-2.27.so ffff9dd6b000-ffff9dd6c000 r--p 0000f000 b3:02 65501 /lib64/libnss_files-2.27.so ffff9dd6c000-ffff9dd6d000 rw-p 00010000 b3:02 65501 /lib64/libnss_files-2.27.so ffff9dd6d000-ffff9dd73000 rw-p 00000000 00:00 0 ffff9dd73000-ffff9dda8000 r--s 00000000 00:17 6320151 /run/nscd/db8Ob1pl (deleted) ffff9dda8000-ffff9de69000 r-xp 00000000 b3:02 16867 /usr/lib64/python3.6/lib-dynload/unicodedata.cpython-36m-aarch64-linux-gnu.so ffff9de69000-ffff9de87000 ---p 000c1000 b3:02 16867 /usr/lib64/python3.6/lib-dynload/unicodedata.cpython-36m-aarch64-linux-gnu.so ffff9de87000-ffff9de88000 r--p 000cf000 b3:02 16867 /usr/lib64/python3.6/lib-dynload/unicodedata.cpython-36m-aarch64-linux-gnu.so ffff9de88000-ffff9dea3000 rw-p 000d0000 b3:02 16867 /usr/lib64/python3.6/lib-dynload/unicodedata.cpython-36m-aarch64-linux-gnu.so ffff9dea3000-ffff9e063000 rw-p 00000000 00:00 0 ffff9e063000-ffff9e066000 r-xp 00000000 b3:02 16853 /usr/lib64/python3.6/lib-dynload/fcntl.cpython-36m-aarch64-linux-gnu.so ffff9e066000-ffff9e082000 ---p 00003000 b3:02 16853 /usr/lib64/python3.6/lib-dynload/fcntl.cpython-36m-aarch64-linux-gnu.so ffff9e082000-ffff9e083000 r--p 0000f000 b3:02 16853 /usr/lib64/python3.6/lib-dynload/fcntl.cpython-36m-aarch64-linux-gnu.so ffff9e083000-ffff9e085000 rw-p 00010000 b3:02 16853 /usr/lib64/python3.6/lib-dynload/fcntl.cpython-36m-aarch64-linux-gnu.so ffff9e085000-ffff9e105000 rw-p 00000000 00:00 0 ffff9e105000-ffff9e115000 r-xp 00000000 b3:02 16828 /usr/lib64/python3.6/lib-dynload/_elementtree.cpython-36m-aarch64-linux-gnu.so ffff9e115000-ffff9e124000 ---p 00010000 b3:02 16828 /usr/lib64/python3.6/lib-dynload/_elementtree.cpython-36m-aarch64-linux-gnu.so ffff9e124000-ffff9e125000 r--p 0000f000 b3:02 16828 /usr/lib64/python3.6/lib-dynload/_elementtree.cpython-36m-aarch64-linux-gnu.so ffff9e125000-ffff9e127000 rw-p 00010000 b3:02 16828 /usr/lib64/python3.6/lib-dynload/_elementtree.cpython-36m-aarch64-linux-gnu.so ffff9e127000-ffff9e227000 rw-p 00000000 00:00 0 ffff9e227000-ffff9e22e000 r-xp 00000000 b3:02 16824 /usr/lib64/python3.6/lib-dynload/_csv.cpython-36m-aarch64-linux-gnu.so ffff9e22e000-ffff9e246000 ---p 00007000 b3:02 16824 /usr/lib64/python3.6/lib-dynload/_csv.cpython-36m-aarch64-linux-gnu.so ffff9e246000-ffff9e247000 r--p 0000f000 b3:02 16824 /usr/lib64/python3.6/lib-dynload/_csv.cpython-36m-aarch64-linux-gnu.so ffff9e247000-ffff9e249000 rw-p 00010000 b3:02 16824 /usr/lib64/python3.6/lib-dynload/_csv.cpython-36m-aarch64-linux-gnu.so ffff9e249000-ffff9e24c000 r-xp 00000000 b3:02 16836 /usr/lib64/python3.6/lib-dynload/_multiprocessing.cpython-36m-aarch64-linux-gnu.so ffff9e24c000-ffff9e268000 ---p 00003000 b3:02 16836 /usr/lib64/python3.6/lib-dynload/_multiprocessing.cpython-36m-aarch64-linux-gnu.so ffff9e268000-ffff9e269000 r--p 0000f000 b3:02 16836 /usr/lib64/python3.6/lib-dynload/_multiprocessing.cpython-36m-aarch64-linux-gnu.so ffff9e269000-ffff9e26a000 rw-p 00010000 b3:02 16836 /usr/lib64/python3.6/lib-dynload/_multiprocessing.cpython-36m-aarch64-linux-gnu.so ffff9e26a000-ffff9e277000 r-xp 00000000 b3:02 16849 /usr/lib64/python3.6/lib-dynload/array.cpython-36m-aarch64-linux-gnu.so ffff9e277000-ffff9e289000 ---p 0000d000 b3:02 16849 /usr/lib64/python3.6/lib-dynload/array.cpython-36m-aarch64-linux-gnu.so ffff9e289000-ffff9e28a000 r--p 0000f000 b3:02 16849 /usr/lib64/python3.6/lib-dynload/array.cpython-36m-aarch64-linux-gnu.so ffff9e28a000-ffff9e28d000 rw-p 00010000 b3:02 16849 /usr/lib64/python3.6/lib-dynload/array.cpython-36m-aarch64-linux-gnu.so ffff9e28d000-ffff9e2cd000 rw-p 00000000 00:00 0 ffff9e2cd000-ffff9e320000 r-xp 00000000 b3:02 16827 /usr/lib64/python3.6/lib-dynload/_decimal.cpython-36m-aarch64-linux-gnu.so ffff9e320000-ffff9e33c000 ---p 00053000 b3:02 16827 /usr/lib64/python3.6/lib-dynload/_decimal.cpython-36m-aarch64-linux-gnu.so ffff9e33c000-ffff9e33d000 r--p 0005f000 b3:02 16827 /usr/lib64/python3.6/lib-dynload/_decimal.cpython-36m-aarch64-linux-gnu.so ffff9e33d000-ffff9e345000 rw-p 00060000 b3:02 16827 /usr/lib64/python3.6/lib-dynload/_decimal.cpython-36m-aarch64-linux-gnu.so ffff9e345000-ffff9e34a000 r-xp 00000000 b3:02 16866 /usr/lib64/python3.6/lib-dynload/termios.cpython-36m-aarch64-linux-gnu.so ffff9e34a000-ffff9e364000 ---p 00005000 b3:02 16866 /usr/lib64/python3.6/lib-dynload/termios.cpython-36m-aarch64-linux-gnu.so ffff9e364000-ffff9e365000 r--p 0000f000 b3:02 16866 /usr/lib64/python3.6/lib-dynload/termios.cpython-36m-aarch64-linux-gnu.so ffff9e365000-ffff9e367000 rw-p 00010000 b3:02 16866 /usr/lib64/python3.6/lib-dynload/termios.cpython-36m-aarch64-linux-gnu.so ffff9e367000-ffff9e7a7000 rw-p 00000000 00:00 0 ffff9e7a7000-ffff9e7c0000 r-xp 00000000 b3:02 16838 /usr/lib64/python3.6/lib-dynload/_pickle.cpython-36m-aarch64-linux-gnu.so ffff9e7c0000-ffff9e7d6000 ---p 00019000 b3:02 16838 /usr/lib64/python3.6/lib-dynload/_pickle.cpython-36m-aarch64-linux-gnu.so ffff9e7d6000-ffff9e7d7000 r--p 0001f000 b3:02 16838 /usr/lib64/python3.6/lib-dynload/_pickle.cpython-36m-aarch64-linux-gnu.so ffff9e7d7000-ffff9e7db000 rw-p 00020000 b3:02 16838 /usr/lib64/python3.6/lib-dynload/_pickle.cpython-36m-aarch64-linux-gnu.so ffff9e7db000-ffff9e91b000 rw-p 00000000 00:00 0 ffff9e91b000-ffff9e92a000 r-xp 00000000 b3:02 77055 /usr/lib64/python3.6/lib-dynload/_json.cpython-36m-aarch64-linux-gnu.so ffff9e92a000-ffff9e93a000 ---p 0000f000 b3:02 77055 /usr/lib64/python3.6/lib-dynload/_json.cpython-36m-aarch64-linux-gnu.so ffff9e93a000-ffff9e93b000 r--p 0000f000 b3:02 77055 /usr/lib64/python3.6/lib-dynload/_json.cpython-36m-aarch64-linux-gnu.so ffff9e93b000-ffff9e93c000 rw-p 00010000 b3:02 77055 /usr/lib64/python3.6/lib-dynload/_json.cpython-36m-aarch64-linux-gnu.so ffff9e93c000-ffff9e9bc000 rw-p 00000000 00:00 0 ffff9e9bc000-ffff9e9c2000 r-xp 00000000 b3:02 11105 /usr/lib64/libuuid.so.1.3.0 ffff9e9c2000-ffff9e9db000 ---p 00006000 b3:02 11105 /usr/lib64/libuuid.so.1.3.0 ffff9e9db000-ffff9e9dc000 r--p 0000f000 b3:02 11105 /usr/lib64/libuuid.so.1.3.0 ffff9e9dc000-ffff9e9dd000 rw-p 00010000 b3:02 11105 /usr/lib64/libuuid.so.1.3.0 ffff9e9dd000-ffff9ea1d000 rw-p 00000000 00:00 0 ffff9ea1d000-ffff9ea3b000 r-xp 00000000 b3:02 16825 /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-aarch64-linux-gnu.so ffff9ea3b000-ffff9ea4c000 ---p 0001e000 b3:02 16825 /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-aarch64-linux-gnu.so ffff9ea4c000-ffff9ea4d000 r--p 0001f000 b3:02 16825 /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-aarch64-linux-gnu.so ffff9ea4d000-ffff9ea51000 rw-p 00020000 b3:02 16825 /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-aarch64-linux-gnu.so ffff9ea51000-ffff9ead1000 rw-p 00000000 00:00 0 ffff9ead1000-ffff9eb31000 r-xp 00000000 b3:02 65680 /usr/lib64/libssl.so.1.1 ffff9eb31000-ffff9eb4c000 ---p 00060000 b3:02 65680 /usr/lib64/libssl.so.1.1 ffff9eb4c000-ffff9eb51000 r--p 0006b000 b3:02 65680 /usr/lib64/libssl.so.1.1 ffff9eb51000-ffff9eb56000 rw-p 00070000 b3:02 65680 /usr/lib64/libssl.so.1.1 ffff9eb56000-ffff9eb71000 r-xp 00000000 b3:02 16846 /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-aarch64-linux-gnu.so ffff9eb71000-ffff9eb85000 ---p 0001b000 b3:02 16846 /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-aarch64-linux-gnu.so ffff9eb85000-ffff9eb86000 r--p 0001f000 b3:02 16846 /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-aarch64-linux-gnu.so ffff9eb86000-ffff9eb8b000 rw-p 00020000 b3:02 16846 /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-aarch64-linux-gnu.so ffff9eb8b000-ffff9ee1c000 rw-p 00000000 00:00 0 ffff9ee2d000-ffff9ee35000 r-xp 00000000 b3:02 70637 /usr/lib64/libffi.so.7.1.0 ffff9ee35000-ffff9ee4c000 ---p 00008000 b3:02 70637 /usr/lib64/libffi.so.7.1.0 ffff9ee4c000-ffff9ee4d000 r--p 0000f000 b3:02 70637 /usr/lib64/libffi.so.7.1.0 ffff9ee4d000-ffff9ee4e000 rw-p 00010000 b3:02 70637 /usr/lib64/libffi.so.7.1.0 ffff9ee4e000-ffff9eece000 rw-p 00000000 00:00 0 ffff9eece000-ffff9eecf000 r-xp 00000000 b3:02 16837 /usr/lib64/python3.6/lib-dynload/_opcode.cpython-36m-aarch64-linux-gnu.so ffff9eecf000-ffff9eeed000 ---p 00001000 b3:02 16837 /usr/lib64/python3.6/lib-dynload/_opcode.cpython-36m-aarch64-linux-gnu.so ffff9eeed000-ffff9eeee000 r--p 0000f000 b3:02 16837 /usr/lib64/python3.6/lib-dynload/_opcode.cpython-36m-aarch64-linux-gnu.so ffff9eeee000-ffff9eeef000 rw-p 00010000 b3:02 16837 /usr/lib64/python3.6/lib-dynload/_opcode.cpython-36m-aarch64-linux-gnu.so ffff9eeef000-ffff9efaf000 rw-p 00000000 00:00 0 ffff9efaf000-ffff9efc5000 r-xp 00000000 b3:02 16845 /usr/lib64/python3.6/lib-dynload/_socket.cpython-36m-aarch64-linux-gnu.so ffff9efc5000-ffff9efde000 ---p 00016000 b3:02 16845 /usr/lib64/python3.6/lib-dynload/_socket.cpython-36m-aarch64-linux-gnu.so ffff9efde000-ffff9efdf000 r--p 0001f000 b3:02 16845 /usr/lib64/python3.6/lib-dynload/_socket.cpython-36m-aarch64-linux-gnu.so ffff9efdf000-ffff9efe4000 rw-p 00020000 b3:02 16845 /usr/lib64/python3.6/lib-dynload/_socket.cpython-36m-aarch64-linux-gnu.so ffff9efe4000-ffff9efe8000 r-xp 00000000 b3:02 16840 /usr/lib64/python3.6/lib-dynload/_random.cpython-36m-aarch64-linux-gnu.so ffff9efe8000-ffff9f003000 ---p 00004000 b3:02 16840 /usr/lib64/python3.6/lib-dynload/_random.cpython-36m-aarch64-linux-gnu.so ffff9f003000-ffff9f004000 r--p 0000f000 b3:02 16840 /usr/lib64/python3.6/lib-dynload/_random.cpython-36m-aarch64-linux-gnu.so ffff9f004000-ffff9f005000 rw-p 00010000 b3:02 16840 /usr/lib64/python3.6/lib-dynload/_random.cpython-36m-aarch64-linux-gnu.so ffff9f005000-ffff9f007000 r-xp 00000000 b3:02 15385 /usr/lib64/python3.6/lib-dynload/_bisect.cpython-36m-aarch64-linux-gnu.so ffff9f007000-ffff9f024000 ---p 00002000 b3:02 15385 /usr/lib64/python3.6/lib-dynload/_bisect.cpython-36m-aarch64-linux-gnu.so ffff9f024000-ffff9f025000 r--p 0000f000 b3:02 15385 /usr/lib64/python3.6/lib-dynload/_bisect.cpython-36m-aarch64-linux-gnu.so ffff9f025000-ffff9f026000 rw-p 00010000 b3:02 15385 /usr/lib64/python3.6/lib-dynload/_bisect.cpython-36m-aarch64-linux-gnu.so ffff9f026000-ffff9f038000 r-xp 00000000 b3:02 16843 /usr/lib64/python3.6/lib-dynload/_sha3.cpython-36m-aarch64-linux-gnu.so ffff9f038000-ffff9f055000 ---p 00012000 b3:02 16843 /usr/lib64/python3.6/lib-dynload/_sha3.cpython-36m-aarch64-linux-gnu.so ffff9f055000-ffff9f056000 r--p 0001f000 b3:02 16843 /usr/lib64/python3.6/lib-dynload/_sha3.cpython-36m-aarch64-linux-gnu.so ffff9f056000-ffff9f058000 rw-p 00020000 b3:02 16843 /usr/lib64/python3.6/lib-dynload/_sha3.cpython-36m-aarch64-linux-gnu.so ffff9f058000-ffff9f064000 r-xp 00000000 b3:02 16775 /usr/lib64/python3.6/lib-dynload/_blake2.cpython-36m-aarch64-linux-gnu.so ffff9f064000-ffff9f077000 ---p 0000c000 b3:02 16775 /usr/lib64/python3.6/lib-dynload/_blake2.cpython-36m-aarch64-linux-gnu.so ffff9f077000-ffff9f078000 r--p 0000f000 b3:02 16775 /usr/lib64/python3.6/lib-dynload/_blake2.cpython-36m-aarch64-linux-gnu.so ffff9f078000-ffff9f079000 rw-p 00010000 b3:02 16775 /usr/lib64/python3.6/lib-dynload/_blake2.cpython-36m-aarch64-linux-gnu.so ffff9f079000-ffff9f2ac000 r-xp 00000000 b3:02 11645 /usr/lib64/libcrypto.so.1.1 ffff9f2ac000-ffff9f2bd000 ---p 00233000 b3:02 11645 /usr/lib64/libcrypto.so.1.1 ffff9f2bd000-ffff9f2d9000 r--p 00234000 b3:02 11645 /usr/lib64/libcrypto.so.1.1 ffff9f2d9000-ffff9f2e4000 rw-p 00250000 b3:02 11645 /usr/lib64/libcrypto.so.1.1 ffff9f2e4000-ffff9f2e8000 rw-p 00000000 00:00 0 ffff9f2e8000-ffff9f2ee000 r-xp 00000000 b3:02 16829 /usr/lib64/python3.6/lib-dynload/_hashlib.cpython-36m-aarch64-linux-gnu.so ffff9f2ee000-ffff9f307000 ---p 00006000 b3:02 16829 /usr/lib64/python3.6/lib-dynload/_hashlib.cpython-36m-aarch64-linux-gnu.so ffff9f307000-ffff9f308000 r--p 0000f000 b3:02 16829 /usr/lib64/python3.6/lib-dynload/_hashlib.cpython-36m-aarch64-linux-gnu.so ffff9f308000-ffff9f309000 rw-p 00010000 b3:02 16829 /usr/lib64/python3.6/lib-dynload/_hashlib.cpython-36m-aarch64-linux-gnu.so ffff9f309000-ffff9f389000 rw-p 00000000 00:00 0 ffff9f389000-ffff9f3b6000 r-xp 00000000 b3:02 9561 /usr/lib64/libexpat.so.1.6.7 ffff9f3b6000-ffff9f3c7000 ---p 0002d000 b3:02 9561 /usr/lib64/libexpat.so.1.6.7 ffff9f3c7000-ffff9f3c9000 r--p 0002e000 b3:02 9561 /usr/lib64/libexpat.so.1.6.7 ffff9f3c9000-ffff9f3ca000 rw-p 00030000 b3:02 9561 /usr/lib64/libexpat.so.1.6.7 ffff9f3ca000-ffff9f3db000 r-xp 00000000 b3:02 16860 /usr/lib64/python3.6/lib-dynload/pyexpat.cpython-36m-aarch64-linux-gnu.so ffff9f3db000-ffff9f3f9000 ---p 00011000 b3:02 16860 /usr/lib64/python3.6/lib-dynload/pyexpat.cpython-36m-aarch64-linux-gnu.so ffff9f3f9000-ffff9f3fa000 r--p 0001f000 b3:02 16860 /usr/lib64/python3.6/lib-dynload/pyexpat.cpython-36m-aarch64-linux-gnu.so ffff9f3fa000-ffff9f3fc000 rw-p 00020000 b3:02 16860 /usr/lib64/python3.6/lib-dynload/pyexpat.cpython-36m-aarch64-linux-gnu.so ffff9f3fc000-ffff9f415000 r-xp 00000000 b3:02 16826 /usr/lib64/python3.6/lib-dynload/_datetime.cpython-36m-aarch64-linux-gnu.so ffff9f415000-ffff9f42b000 ---p 00019000 b3:02 16826 /usr/lib64/python3.6/lib-dynload/_datetime.cpython-36m-aarch64-linux-gnu.so ffff9f42b000-ffff9f42c000 r--p 0001f000 b3:02 16826 /usr/lib64/python3.6/lib-dynload/_datetime.cpython-36m-aarch64-linux-gnu.so ffff9f42c000-ffff9f42e000 rw-p 00020000 b3:02 16826 /usr/lib64/python3.6/lib-dynload/_datetime.cpython-36m-aarch64-linux-gnu.so ffff9f42e000-ffff9f46e000 rw-p 00000000 00:00 0 ffff9f46e000-ffff9f477000 r-xp 00000000 b3:02 16855 /usr/lib64/python3.6/lib-dynload/math.cpython-36m-aarch64-linux-gnu.so ffff9f477000-ffff9f48d000 ---p 00009000 b3:02 16855 /usr/lib64/python3.6/lib-dynload/math.cpython-36m-aarch64-linux-gnu.so ffff9f48d000-ffff9f48e000 r--p 0000f000 b3:02 16855 /usr/lib64/python3.6/lib-dynload/math.cpython-36m-aarch64-linux-gnu.so ffff9f48e000-ffff9f490000 rw-p 00010000 b3:02 16855 /usr/lib64/python3.6/lib-dynload/math.cpython-36m-aarch64-linux-gnu.so ffff9f490000-ffff9f497000 r-xp 00000000 b3:02 77058 /usr/lib64/python3.6/lib-dynload/select.cpython-36m-aarch64-linux-gnu.so ffff9f497000-ffff9f4af000 ---p 00007000 b3:02 77058 /usr/lib64/python3.6/lib-dynload/select.cpython-36m-aarch64-linux-gnu.so ffff9f4af000-ffff9f4b0000 r--p 0000f000 b3:02 77058 /usr/lib64/python3.6/lib-dynload/select.cpython-36m-aarch64-linux-gnu.so ffff9f4b0000-ffff9f4b2000 rw-p 00010000 b3:02 77058 /usr/lib64/python3.6/lib-dynload/select.cpython-36m-aarch64-linux-gnu.so ffff9f4b2000-ffff9f4b5000 r-xp 00000000 b3:02 16839 /usr/lib64/python3.6/lib-dynload/_posixsubprocess.cpython-36m-aarch64-linux-gnu.so ffff9f4b5000-ffff9f4d1000 ---p 00003000 b3:02 16839 /usr/lib64/python3.6/lib-dynload/_posixsubprocess.cpython-36m-aarch64-linux-gnu.so ffff9f4d1000-ffff9f4d2000 r--p 0000f000 b3:02 16839 /usr/lib64/python3.6/lib-dynload/_posixsubprocess.cpython-36m-aarch64-linux-gnu.so ffff9f4d2000-ffff9f4d3000 rw-p 00010000 b3:02 16839 /usr/lib64/python3.6/lib-dynload/_posixsubprocess.cpython-36m-aarch64-linux-gnu.so ffff9f4d3000-ffff9f513000 rw-p 00000000 00:00 0 ffff9f513000-ffff9f519000 r-xp 00000000 b3:02 16851 /usr/lib64/python3.6/lib-dynload/binascii.cpython-36m-aarch64-linux-gnu.so ffff9f519000-ffff9f532000 ---p 00006000 b3:02 16851 /usr/lib64/python3.6/lib-dynload/binascii.cpython-36m-aarch64-linux-gnu.so ffff9f532000-ffff9f533000 r--p 0000f000 b3:02 16851 /usr/lib64/python3.6/lib-dynload/binascii.cpython-36m-aarch64-linux-gnu.so ffff9f533000-ffff9f534000 rw-p 00010000 b3:02 16851 /usr/lib64/python3.6/lib-dynload/binascii.cpython-36m-aarch64-linux-gnu.so ffff9f534000-ffff9f53e000 r-xp 00000000 b3:02 16847 /usr/lib64/python3.6/lib-dynload/_struct.cpython-36m-aarch64-linux-gnu.so ffff9f53e000-ffff9f553000 ---p 0000a000 b3:02 16847 /usr/lib64/python3.6/lib-dynload/_struct.cpython-36m-aarch64-linux-gnu.so ffff9f553000-ffff9f554000 r--p 0000f000 b3:02 16847 /usr/lib64/python3.6/lib-dynload/_struct.cpython-36m-aarch64-linux-gnu.so ffff9f554000-ffff9f556000 rw-p 00010000 b3:02 16847 /usr/lib64/python3.6/lib-dynload/_struct.cpython-36m-aarch64-linux-gnu.so ffff9f556000-ffff9f558000 r-xp 00000000 b3:02 16854 /usr/lib64/python3.6/lib-dynload/grp.cpython-36m-aarch64-linux-gnu.so ffff9f558000-ffff9f575000 ---p 00002000 b3:02 16854 /usr/lib64/python3.6/lib-dynload/grp.cpython-36m-aarch64-linux-gnu.so ffff9f575000-ffff9f576000 r--p 0000f000 b3:02 16854 /usr/lib64/python3.6/lib-dynload/grp.cpython-36m-aarch64-linux-gnu.so ffff9f576000-ffff9f577000 rw-p 00010000 b3:02 16854 /usr/lib64/python3.6/lib-dynload/grp.cpython-36m-aarch64-linux-gnu.so ffff9f577000-ffff9f5ad000 r-xp 00000000 b3:02 9754 /usr/lib64/liblzma.so.5.2.3 ffff9f5ad000-ffff9f5c6000 ---p 00036000 b3:02 9754 /usr/lib64/liblzma.so.5.2.3 ffff9f5c6000-ffff9f5c7000 r--p 0003f000 b3:02 9754 /usr/lib64/liblzma.so.5.2.3 ffff9f5c7000-ffff9f5c8000 rw-p 00040000 b3:02 9754 /usr/lib64/liblzma.so.5.2.3 ffff9f5c8000-ffff9f5cf000 r-xp 00000000 b3:02 74884 /usr/lib64/python3.6/lib-dynload/_lzma.cpython-36m-aarch64-linux-gnu.so ffff9f5cf000-ffff9f5e7000 ---p 00007000 b3:02 74884 /usr/lib64/python3.6/lib-dynload/_lzma.cpython-36m-aarch64-linux-gnu.so ffff9f5e7000-ffff9f5e8000 r--p 0000f000 b3:02 74884 /usr/lib64/python3.6/lib-dynload/_lzma.cpython-36m-aarch64-linux-gnu.so ffff9f5e8000-ffff9f5ea000 rw-p 00010000 b3:02 74884 /usr/lib64/python3.6/lib-dynload/_lzma.cpython-36m-aarch64-linux-gnu.so ffff9f5ea000-ffff9f601000 r-xp 00000000 b3:02 9456 /usr/lib64/libbz2.so.1.0.6 ffff9f601000-ffff9f619000 ---p 00017000 b3:02 9456 /usr/lib64/libbz2.so.1.0.6 ffff9f619000-ffff9f61a000 r--p 0001f000 b3:02 9456 /usr/lib64/libbz2.so.1.0.6 ffff9f61a000-ffff9f61b000 rw-p 00020000 b3:02 9456 /usr/lib64/libbz2.so.1.0.6 ffff9f61b000-ffff9f61f000 r-xp 00000000 b3:02 16780 /usr/lib64/python3.6/lib-dynload/_bz2.cpython-36m-aarch64-linux-gnu.so ffff9f61f000-ffff9f63a000 ---p 00004000 b3:02 16780 /usr/lib64/python3.6/lib-dynload/_bz2.cpython-36m-aarch64-linux-gnu.so ffff9f63a000-ffff9f63b000 r--p 0000f000 b3:02 16780 /usr/lib64/python3.6/lib-dynload/_bz2.cpython-36m-aarch64-linux-gnu.so ffff9f63b000-ffff9f63c000 rw-p 00010000 b3:02 16780 /usr/lib64/python3.6/lib-dynload/_bz2.cpython-36m-aarch64-linux-gnu.so ffff9f63c000-ffff9f67c000 rw-p 00000000 00:00 0 ffff9f67c000-ffff9f692000 r-xp 00000000 b3:02 6734 /lib64/libz.so.1.2.11 ffff9f692000-ffff9f6ab000 ---p 00016000 b3:02 6734 /lib64/libz.so.1.2.11 ffff9f6ab000-ffff9f6ac000 r--p 0001f000 b3:02 6734 /lib64/libz.so.1.2.11 ffff9f6ac000-ffff9f6ad000 rw-p 00020000 b3:02 6734 /lib64/libz.so.1.2.11 ffff9f6c8000-ffff9f829000 rw-p 00000000 00:00 0 ffff9f829000-ffff9f82c000 r-xp 00000000 b3:02 16830 /usr/lib64/python3.6/lib-dynload/_heapq.cpython-36m-aarch64-linux-gnu.so ffff9f82c000-ffff9f848000 ---p 00003000 b3:02 16830 /usr/lib64/python3.6/lib-dynload/_heapq.cpython-36m-aarch64-linux-gnu.so ffff9f848000-ffff9f849000 r--p 0000f000 b3:02 16830 /usr/lib64/python3.6/lib-dynload/_heapq.cpython-36m-aarch64-linux-gnu.so ffff9f849000-ffff9f84b000 rw-p 00010000 b3:02 16830 /usr/lib64/python3.6/lib-dynload/_heapq.cpython-36m-aarch64-linux-gnu.so ffff9f84b000-ffff9f90b000 rw-p 00000000 00:00 0 ffff9f90e000-ffff9f914000 r-xp 00000000 b3:02 16868 /usr/lib64/python3.6/lib-dynload/zlib.cpython-36m-aarch64-linux-gnu.so ffff9f914000-ffff9f92d000 ---p 00006000 b3:02 16868 /usr/lib64/python3.6/lib-dynload/zlib.cpython-36m-aarch64-linux-gnu.so ffff9f92d000-ffff9f92e000 r--p 0000f000 b3:02 16868 /usr/lib64/python3.6/lib-dynload/zlib.cpython-36m-aarch64-linux-gnu.so ffff9f92e000-ffff9f930000 rw-p 00010000 b3:02 16868 /usr/lib64/python3.6/lib-dynload/zlib.cpython-36m-aarch64-linux-gnu.so ffff9f930000-ffff9fa70000 rw-p 00000000 00:00 0 ffff9fa70000-ffff9fac1000 r--p 00000000 b3:02 134700 /usr/lib/locale/en_US.utf8/LC_CTYPE ffff9fac1000-ffff9fbf1000 r--p 00000000 b3:02 131380 /usr/lib/locale/en_US.utf8/LC_COLLATE ffff9fbf1000-ffff9fca5000 r-xp 00000000 b3:02 65493 /lib64/libm-2.27.so ffff9fca5000-ffff9fcc0000 ---p 000b4000 b3:02 65493 /lib64/libm-2.27.so ffff9fcc0000-ffff9fcc1000 r--p 000bf000 b3:02 65493 /lib64/libm-2.27.so ffff9fcc1000-ffff9fcc2000 rw-p 000c0000 b3:02 65493 /lib64/libm-2.27.so ffff9fcc2000-ffff9fcc4000 r-xp 00000000 b3:02 7635 /lib64/libutil-2.27.so ffff9fcc4000-ffff9fce1000 ---p 00002000 b3:02 7635 /lib64/libutil-2.27.so ffff9fce1000-ffff9fce2000 r--p 0000f000 b3:02 7635 /lib64/libutil-2.27.so ffff9fce2000-ffff9fce3000 rw-p 00010000 b3:02 7635 /lib64/libutil-2.27.so ffff9fce3000-ffff9fce6000 r-xp 00000000 b3:02 65491 /lib64/libdl-2.27.so ffff9fce6000-ffff9fd02000 ---p 00003000 b3:02 65491 /lib64/libdl-2.27.so ffff9fd02000-ffff9fd03000 r--p 0000f000 b3:02 65491 /lib64/libdl-2.27.so ffff9fd03000-ffff9fd04000 rw-p 00010000 b3:02 65491 /lib64/libdl-2.27.so ffff9fd04000-ffff9fe68000 r-xp 00000000 b3:02 65486 /lib64/libc-2.27.so ffff9fe68000-ffff9fe80000 ---p 00164000 b3:02 65486 /lib64/libc-2.27.so ffff9fe80000-ffff9fe84000 r--p 0016c000 b3:02 65486 /lib64/libc-2.27.so ffff9fe84000-ffff9fe86000 rw-p 00170000 b3:02 65486 /lib64/libc-2.27.so ffff9fe86000-ffff9fe8a000 rw-p 00000000 00:00 0 ffff9fe8a000-ffff9fea3000 r-xp 00000000 b3:02 7624 /lib64/libpthread-2.27.so ffff9fea3000-ffff9feb9000 ---p 00019000 b3:02 7624 /lib64/libpthread-2.27.so ffff9feb9000-ffff9feba000 r--p 0001f000 b3:02 7624 /lib64/libpthread-2.27.so ffff9feba000-ffff9febb000 rw-p 00020000 b3:02 7624 /lib64/libpthread-2.27.so ffff9febb000-ffff9febf000 rw-p 00000000 00:00 0 ffff9febf000-ffffa0178000 r-xp 00000000 b3:02 9884 /usr/lib64/libpython3.6m.so.1.0 ffffa0178000-ffffa018c000 ---p 002b9000 b3:02 9884 /usr/lib64/libpython3.6m.so.1.0 ffffa018c000-ffffa018f000 r--p 002bd000 b3:02 9884 /usr/lib64/libpython3.6m.so.1.0 ffffa018f000-ffffa01f2000 rw-p 002c0000 b3:02 9884 /usr/lib64/libpython3.6m.so.1.0 ffffa01f2000-ffffa0223000 rw-p 00000000 00:00 0 ffffa0223000-ffffa0225000 r-xp 00000000 b3:02 7589 /lib64/libSegFault.so ffffa0225000-ffffa0242000 ---p 00002000 b3:02 7589 /lib64/libSegFault.so ffffa0242000-ffffa0243000 r--p 0000f000 b3:02 7589 /lib64/libSegFault.so ffffa0243000-ffffa0244000 rw-p 00010000 b3:02 7589 /lib64/libSegFault.so ffffa024b000-ffffa024c000 rwxp 00000000 00:00 0 ffffa024c000-ffffa024d000 r--p 00000000 b3:02 131411 /usr/lib/locale/en_US.utf8/LC_NUMERIC ffffa024d000-ffffa024e000 r--p 00000000 b3:02 138903 /usr/lib/locale/en_US.utf8/LC_TIME ffffa024e000-ffffa024f000 r--p 00000000 b3:02 131963 /usr/lib/locale/en_US.utf8/LC_MONETARY ffffa024f000-ffffa0256000 r--s 00000000 b3:02 65636 /usr/lib64/gconv/gconv-modules.cache ffffa0256000-ffffa0276000 r-xp 00000000 b3:02 53019 /lib64/ld-2.27.so ffffa0276000-ffffa0277000 r--p 00000000 b3:02 132244 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES ffffa0277000-ffffa0278000 r--p 00000000 b3:02 132519 /usr/lib/locale/en_US.utf8/LC_PAPER ffffa0278000-ffffa0279000 r--p 00000000 b3:02 131804 /usr/lib/locale/en_US.utf8/LC_NAME ffffa0279000-ffffa027a000 r--p 00000000 b3:02 132428 /usr/lib/locale/en_US.utf8/LC_ADDRESS ffffa027a000-ffffa027b000 r--p 00000000 b3:02 132998 /usr/lib/locale/en_US.utf8/LC_TELEPHONE ffffa027b000-ffffa027c000 r--p 00000000 b3:02 131962 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT ffffa027c000-ffffa027d000 r--p 00000000 b3:02 138900 /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION ffffa027d000-ffffa0283000 rw-p 00000000 00:00 0 ffffa0283000-ffffa0284000 r--p 00000000 00:00 0 [vvar] ffffa0284000-ffffa0285000 r-xp 00000000 00:00 0 [vdso] ffffa0285000-ffffa0286000 r--p 0001f000 b3:02 53019 /lib64/ld-2.27.so ffffa0286000-ffffa0287000 rw-p 00020000 b3:02 53019 /lib64/ld-2.27.so ffffa0287000-ffffa0288000 rw-p 00000000 00:00 0 ffffd20eb000-ffffd210c000 rw-p 00000000 00:00 0 [stack] Segmentation fault (core dumped) ```
The workaround of comment #4 does not solve all problems. Using Tumbleweed on a Raspberry Pi 3 is impossible. All applications have a dependency on the new version of glibc. Any progress?
I thought gcc8 fixed it? If so, we only need to make sure the current tree gets published, no?
(In reply to Alexander Graf from comment #18) > I thought gcc8 fixed it? If so, we only need to make sure the current tree > gets published, no? gcc8 isn't used yet for package building.
this bug is quite inconvenient.. could somebody explain what is the root cause of this problem? Just to know how likely it is to occur again in the future. For now, I stay on the 20180202 build but I guess that's suboptimal (I don't get any security updates?)
(In reply to matthias sweertvaegher from comment #20) > could somebody explain what is the root cause of this problem? No, the root cause is yet unknown.
are you able to reproduce? Do you need more input? in my case, reproducing was very easy: install jeos img (20180202), zypper dup, reboot. then perform zypper ref, or zypper up. It typically crashes right after launch during the first minutes of system uptime and might start working after that, you're never sure. (only tested zypper command) But even then, the zypper command could still crash during operation.
Hm, I tried a few things, but it seems this is not a miscompilation. First, if I got the right executables corresponding to the provided pip core, then it failed here: Dump of assembler code from 0xffffaf7b0f80 to 0xffffaf7b0f90: 0x0000ffffaf7b0f80: b 0xffffaf7b04e4 0x0000ffffaf7b0f84: nop => 0x0000ffffaf7b0f88: stp x29, x30, [sp, #-80]! 0x0000ffffaf7b0f8c: mov x29, sp Second, I tried installing the faulty glibc in a chroot environment on SLES12 SP3, and this combination did not crash ping...
Ah, OK, when I mount the complete distribution and chroot to it, I _can_ reproduce the issue: (gdb) r Starting program: /usr/bin/ping google.com [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x0000ffffb78d800c in gaih_getanswer_slice.isra () from /lib64/libnss_dns.so.2 (gdb) x/i $pc => 0xffffb78d800c <gaih_getanswer_slice.isra.0+44>: ldr x5, [x3] (gdb) p/x $x3 $1 = 0x41564952505f4342
There's something weird going on here. Have a look at the generated code: Dump of assembler code for function gaih_getanswer_slice.isra.0: 0x0000ffffb78d7fe0 <+0>: sub sp, sp, #0x5e0 0x0000ffffb78d7fe4 <+4>: mov x9, x2 // 0xffffffffea00 0x0000ffffb78d7fe8 <+8>: mov x8, x3 // 0xffffffffea08 0x0000ffffb78d7fec <+12>: stp x29, x30, [sp] 0x0000ffffb78d7ff0 <+16>: mov x29, sp 0x0000ffffb78d7ff4 <+20>: str x2, [x29, #120] 0x0000ffffb78d7ff8 <+24>: adrp x2, 0xffffb78f5000 0x0000ffffb78d7ffc <+28>: stp x4, x3, [x29, #104] 0x0000ffffb78d8000 <+32>: ldr x3, [x2, #4040] // (gdb) 0xffffb78f5fc8: 0x0000ffffb7ffe740 0x0000ffffb78d8004 <+36>: str x5, [x29, #136] 0x0000ffffb78d8008 <+40>: ldrh w2, [x0, #4] // answer.qdcount = 0x0100 => 0x0000ffffb78d800c <+44>: ldr x5, [x3] // $x3 = 0x41564952505f4342 ??? This function is called twice from _nss_dns_gethostbyname4_r. On the first call, everything works just fine. On the second call, x3 contains an invalid pointer and the process segfaults. However, when I set a breakpoint to the load instruction at 0x0000ffffb78d8000, everything looks good again. I can even continue execution of the program, and it does not segfault any longer. In short, it smells like some sort of race condition in glibc. As a side note, the value of x3 is ASCII "BC_PRIVA". Not sure if it rings a bell...
Oh, I've just realized something!! Note the address of the load instruction: 0x0000ffffb78d8000 is on a page boundary. But "ADRP" gets the address of the PC-relative 4KB page (plus immediate offset). Now, look at the address at 0xffffb78f5000 + 4096: (gdb) x/x $x2+4040+4096 0xffffb78f6fc8: 0x41564952505f4342 That's our bogus value of x3! In other words, it seems the ADRP destination value may be off by one page if the instruction appears near the end of a page...
All right, so this looks like ARM Cortex-A53 Erratum 843419, sequence 1: > 1) An ADRP instruction, which writes to a register Rn. > • This instruction must be located in memory at an address where the bottom > 12 bits are equal to 0xFF8 or 0xFFC. 0x0000ffffb78d7ff8 <+24>: adrp x2, 0xffffb78f5000 Rn is x2 > 2) A load or store instruction: > • This can be: > • A single register load or store, of either integer or vector registers > • Or an STP or STNP, of either integer or vector registers 0x0000ffffb78d7ffc <+28>: stp x4, x3, [x29, #104] > • Or an Advanced SIMD ST1 store instruction. > • This must not write to Rn. ✓ >[...] > 3) There can optionally be one instruction after instruction 2. Not here. > 4) A load or store instruction from the "Load/store register (unsigned immediate)" encoding class, using Rn as the base address register. 0x0000ffffb78d8000 <+32>: ldr x3, [x2, #4040]
There is the --fix-cortex-a53-843419 linker option (-Wl,--fix-cortex-a53-843419 if you use the GCC driver), also enabled via -mfix-cortex-a53-843419 (at link time).
From the ld manual: The '--fix-cortex-a53-835769' switch enables a link-time workaround for erratum 835769 present on certain early revisions of Cortex-A53 processors. The workaround is disabled by default.
Should we add that linker flag as default to all distributions then? While at it, maybe also add -mfix-cortex-a53-835769?
(In reply to Andreas Schwab from comment #29) > From the ld manual: > > The '--fix-cortex-a53-835769' switch enables a link-time workaround > for erratum 835769 present on certain early revisions of Cortex-A53 > processors. The workaround is disabled by default. I was able to reproduce this on the following SoCs (based on info printed on the board): Raspberry Pi 3 Model B V1.2 Pine64 A64-DB-2G-Rev B 2016-02-25 I wonder if these devices use the "early revisions of Cortex-A53" and what early revision means here.
(In reply to Matthias Brugger from comment #31) >[...] > I wonder if these devices use the "early revisions of Cortex-A53" and what > early revision means here. Same here. Anyway, I can only quote ARM Processor Cortex®-A53 MPCore Software Developers Errata Notice here: > 843419: A load or store might access an incorrect address > Category A > Products Affected: Cortex-A53 MPCore. > Present in: r0p0, r0p1, r0p2, r0p3, r0p4 > > Configurations affected > All configurations of Cortex-A53 are affected. It would be good to get confirmation from ARM whether there are any other potentially affected cores.
Please, note that 835769 is not 843419. Erratum 835769 is “AArch64 multiply-accumulate instruction might produce incorrect result”, which was not causing any trouble in my setup.
--fix-cortex-a53-843419 isn't even documented.
Wouldn't it make sense to just enable those two erratum workarounds in gcc by default? Then all applications will be built with the workarounds, even those that don't use prjconf flags.
gcc needs to be configured with --enable-fix-cortex-a53-843419.
(In reply to Andreas Schwab from comment #34) > --fix-cortex-a53-843419 isn't even documented. I found the 2015 threads https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00017.html and https://sourceware.org/ml/binutils-cvs/2015-04/msg00012.html having a bit more documentation. But I'm confused: these are 2015 indicating "Some early revisions of the Cortex-A53 have an erratum (843419)" which would suggest that more recent revisions are not affected, and having fairly recent Raspberry Pi 3 systems, I kind of expected them to have more recent revisions. Next from the assumptions above, I tried finding out what sets these revisions apart, but my Google foo failed me here. Anyone who can shed some more light on this?
I think the upstream thread is confused. ARM says r0p0, r0p1, r0p2, r0p3, r0p4. In rxpy, the x corresponds to major revision (aka Variant field in MIDR_EL1 aka "CPU variant" in /proc/cpuinfo), and y corresponds to minor revision or product revision (aka Revision field in MIDR_EL1 aka "CPU revision" in /proc/cpuinfo). Commented content of /proc/cpuinfo on a RPi3 system (rpi33.arch) says: CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 // major revision number 0 CPU part : 0xd03 // Cortex-A53 processor CPU revision : 4 // product revision number 4 In short, this CPU is r0p4, thus affected by the erratum 843419 according to ARM official documentation.
Xilinx ZynqMP is also r0p4, thus is affected.
Pine64's A64 is also r0p4...
Well, in 2015, when the thread was written obviously the hope still was that ARM would be fixing this bug in later revisions of the mask, hence the optimistic "early revisions". Equally obviously ARM thought it not worth the trouble; I'm guessing it has something to do with bang-for-buck and margins :)
(In reply to Petr Tesařík from comment #38) > ... ARM says r0p0, r0p1, r0p2, r0p3, > r0p4. ... Found it at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500g/index.html (In reply to Michael Matz from comment #41) > ... I'm guessing it has something to do with bang-for-buck and margins > :) You are right. Seems 2016 only had a second release of r0p4, so no actual change. Bummer.
This is an autogenerated message for OBS integration: This bug (1084812) was mentioned in https://build.opensuse.org/request/show/593393 Factory / gcc7
(In reply to Stefan Brüns from comment #2) > (In reply to Andreas Färber from comment #0) > > ... > > This issue is prohibiting further zypper dup's. > > Workaround: add "195.135.221.134 download.opensuse.org" to /etc/hosts Somehow that does not always work and makes zypper still segfailt (I think because of the MirrorBrain based mirror system in combination with no zypper --verbose level being able to show which mirror it uses before doing the IPv4 lookup over DNS). So I've put your builds in a repository on gitlab including instructions on how to update: https://gitlab.com/wiert.me/public/linux/opensuse/tumbleweed/aarch64/1084182-fix-osc-binaries That should allow many more people to get their system in a kind of working state again. I've tested this on a few systems, one I tried to later do a `zypper dist-upgrade` on, but that failed (not yet found the cause for that, to figure that one out I need to install a few more 20180202 based systems from the JeOS at http://download.opensuse.org/ports/aarch64/tumbleweed/images/) Thanks for those builds. It helped me getting a system to work again, and made me learn a lot of new things in the mean time.
Firefox is also affected. You can check openSUSE Tumbleweed AArch64 - Build20180403. Or try to run Firefox on AArch64 hardware.
I'm very happy to read about all the progress that has been made and that the root cause has been found! thanks for all the hard work. Any idea when a fix will be generally available (i.e. i will be able to just "zypper dup")? @guillaume , are you suggesting Build20180403 has been compiled with the workarounds enabled?
(In reply to matthias sweertvaegher from comment #57) > @guillaume , are you suggesting Build20180403 has been compiled with the > workarounds enabled? No, it is affected.
(In reply to Guillaume GARDET from comment #56) > Firefox is also affected. > You can check openSUSE Tumbleweed AArch64 - Build20180403. > Or try to run Firefox on AArch64 hardware. Please be more specific: Are you saying it needs a rebuild due to being affected by the missing compiler workaround? Can you clarify how to reproduce a crash? Or are you saying Firefox' JIT needs to enable the workaround for dynamic code? In that case please open a new bug depending on this one. Note there's more JITs that may need to be checked for whether they're affected - OpenJDK comes to mind, Mono, ... Our kernel itself has the erratum enabled.
(In reply to Andreas Färber from comment #59) > Please be more specific: Are you saying it needs a rebuild due to being > affected by the missing compiler workaround? Can you clarify how to > reproduce a crash? Just try to start firefox on AArch64 and it will segfault in libnss_dns.so.2 in gaih_getanswer_slice.isra function. If the compiler is fixed, then yes, I guess it would need a rebuild. If I need to open a new bug, please tell me, but it really seems to be the same problem as zypper.
libnss_dns is part of glibc, so rebuilding that will be enough to fix that particular crash. That doesn't mean that there aren't more opportunities hidden somewhere else.
(In reply to Andreas Schwab from comment #61) > libnss_dns is part of glibc, so rebuilding that will be enough to fix that > particular crash. That doesn't mean that there aren't more opportunities > hidden somewhere else. Yes, sure. But on the same system, zypper is broken too. Did a fix reached Factory / Factory:ARM? I cannot find any reference to this bug in recent changelog.
This is an autogenerated message for OBS integration: This bug (1084812) was mentioned in https://build.opensuse.org/request/show/595578 Factory / gcc8
I tested a new image for the pine64 today: openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2018.04.11-Build7.13.raw.xz No problems with ping, zypper dup etc. gcc7 has been fixed: localhost:~ # rpm -q --changelog gcc7|head * Tue Apr 03 2018 rguenther@suse.com - Update to gcc-7-branch head (r258812). * Picks fix to no longer enable -mpc-relative-literal-loads by default with --enable-fix-cortex-a53-843419. - Enable --enable-fix-cortex-a53-843419 on aarch64. [bnc#1084812] [bnc#1087930] * Wed Mar 07 2018 rguenther@suse.com - Update to gcc-7-branch head (r258313). * includes spectre V2 mitigation patch for s390x. [bnc#1083946] gcc8 seems is still in the queue: localhost:~ # rpm -q --changelog gcc8|head * Mon Mar 12 2018 rguenther@suse.com - Update to SVN trunk head (r258445). * Thu Mar 08 2018 rguenther@suse.com - Update to SVN trunk head (r258365). * adds pconfigintrin.h and wbnoinvdintrin.h intrinsic headers for x86 * Mon Mar 05 2018 schwab@suse.de - Add riscv64 cross compiler
I confirm this is solved on RPi3 too. zypper does not fail anymore and Firefox does not crash in libnss_dns.so.2
I started with image openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.02.02-Build1.2.raw.xz and needed to remove from /boot/grub2/grub.cfg the text looking like "console=tty0 console=tty??0,... " leaving only console=tty??1,... on the line with the boot command. This is necessary to get output on the console connection when the system is performing the initialization. This is what I did earlier, after which I performed a "zypper dup --no-recommends" and ended with a bootable system where zypper and pip crashed. Now doing this again with this image, I performed again "zypper dup --no-recommends", after which I got a non-bootable system. Even nothing appears on the console, not even the initial messages of the boot process. Any information you need?
(In reply to Freek de Kruijf from comment #66) > I started with image > openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.02.02-Build1.2.raw.xz > and needed to remove from /boot/grub2/grub.cfg the text looking like > "console=tty0 console=tty??0,... " leaving only console=tty??1,... on the > line with the boot command. This is necessary to get output on the console > connection when the system is performing the initialization. This is what I > did earlier, after which I performed a "zypper dup --no-recommends" and > ended with a bootable system where zypper and pip crashed. Now doing this > again with this image, I performed again "zypper dup --no-recommends", after > which I got a non-bootable system. Even nothing appears on the console, not > even the initial messages of the boot process. > > Any information you need? Please wait that new images are published (or build you own from Factory:ARM/JeOS) because a lot of fixes were integrated last month.
This is an autogenerated message for OBS integration: This bug (1084812) was mentioned in https://build.opensuse.org/request/show/597810 Factory / gcc8
I've managed to recover my two affected systems as follows: 1) Try "zypper -vvv ref" to see from where it downloads - download.opensuse.org most likely. ping the host name from a working system to obtain the IP address and enter it in /etc/hosts, as Stefan had suggested. 2) The download server might redirect you elsewhere, so if zypper dup still crashes, browse for some existing rpm on download.opensuse.org and do a wget with that URL, e.g., "wget https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/aarch64/glibc-2.27-4.3.aarch64.rpm" - this will show you where you're getting redirected to, in my case ftp.gwdg.de. Ping that second host name again to obtain the IP address and enter it in /etc/hosts, too. 3) Now "zypper up glibc" should work, downloading and installing a single package. The symptoms should be gone now! 4) Don't forget to remove your two temporary entries in /etc/hosts. 5) Perform a "zypper dup" for a full system upgrade to latest Tumbleweed. Thanks to Stefan, Petr and Richie for helping resolve this. On two systems that I had not updated to the affected glibc, I could simply do a "zypper dup" as usual.
Tested that name resolution is no longer broken after update as described above.
(In reply to Guillaume GARDET from comment #67) > (In reply to Freek de Kruijf from comment #66) > > I started with image > > openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.02.02-Build1.2.raw.xz > > and needed to remove from /boot/grub2/grub.cfg the text looking like > > "console=tty0 console=tty??0,... " leaving only console=tty??1,... on the > > line with the boot command. This is necessary to get output on the console > > connection when the system is performing the initialization. This is what I > > did earlier, after which I performed a "zypper dup --no-recommends" and > > ended with a bootable system where zypper and pip crashed. Now doing this > > again with this image, I performed again "zypper dup --no-recommends", after > > which I got a non-bootable system. Even nothing appears on the console, not > > even the initial messages of the boot process. > > > > Any information you need? > > Please wait that new images are published (or build you own from > Factory:ARM/JeOS) because a lot of fixes were integrated last month. I tried the same procedure as above. Replaced glibc from the repository mentioned in comment #70 and did a reboot, which went OK. However "zypper dup --no-recommends" ended the same as above; did not boot, not a single character on the console. When will a new image be available? I have no idea how to build my own.
(In reply to Freek de Kruijf from comment #72) > (In reply to Guillaume GARDET from comment #67) > > Please wait that new images are published (or build you own from > > Factory:ARM/JeOS) because a lot of fixes were integrated last month. > > I tried the same procedure as above. Replaced glibc from the repository > mentioned in comment #70 and did a reboot, which went OK. > However "zypper dup --no-recommends" ended the same as above; did not boot, > not a single character on the console. > > When will a new image be available? I have no idea how to build my own. Please discuss your unrelated boot problems in a new Bugzilla, if they persist. You can always download newer images directly from OBS with osc getbinaries or even via the Web interface (login needed for downloading): https://build.opensuse.org/package/binaries/openSUSE:Factory:ARM:Live/JeOS:JeOS-raspberrypi3.aarch64/images
SUSE-RU-2018:1155-1: An update that has 8 recommended fixes can now be installed. Category: recommended (important) Bug References: 1061667,1068967,1074621,1083290,1083946,1084812,1087550,1087930 CVE References: Sources used: SUSE OpenStack Cloud 7 (src): gcc7-7.3.1+r258812-5.2 SUSE OpenStack Cloud 6 (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Software Development Kit 12-SP3 (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Server for SAP 12-SP2 (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Server for SAP 12-SP1 (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Server 12-SP3 (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Server 12-SP2-LTSS (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Server 12-SP1-LTSS (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Server 12-LTSS (src): gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Module for Toolchain 12 (src): cross-nvptx-gcc7-7.3.1+r258812-5.1, gcc7-7.3.1+r258812-5.2 SUSE Linux Enterprise Desktop 12-SP3 (src): gcc7-7.3.1+r258812-5.2 SUSE Enterprise Storage 4 (src): gcc7-7.3.1+r258812-5.2 SUSE CaaS Platform ALL (src): gcc7-7.3.1+r258812-5.2 OpenStack Cloud Magnum Orchestration 7 (src): gcc7-7.3.1+r258812-5.2
> 2) The download server might redirect you elsewhere, so if zypper dup still > crashes, browse for some existing rpm on download.opensuse.org Update the repo URL to point to a mirror, using its IP address as the host name part.
openSUSE-RU-2018:1197-1: An update that has 5 recommended fixes can now be installed. Category: recommended (important) Bug References: 1061667,1068967,1084812,1087550,1087930 CVE References: Sources used: openSUSE Leap 42.3 (src): cross-nvptx-gcc7-7.3.1+r258812-10.1, gcc7-7.3.1+r258812-10.1, gcc7-testresults-7.3.1+r258812-10.1
SUSE-RU-2018:3096-1: An update that has 5 recommended fixes can now be installed. Category: recommended (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: Sources used: SUSE OpenStack Cloud 7 (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Software Development Kit 12-SP3 (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Server for SAP 12-SP2 (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Server for SAP 12-SP1 (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Server 12-SP3 (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Server 12-SP2-LTSS (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Server 12-SP1-LTSS (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Server 12-LTSS (src): gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Module for Toolchain 12 (src): cross-nvptx-gcc8-8.2.1+r264010-1.3.1, gcc8-8.2.1+r264010-1.3.3 SUSE Linux Enterprise Desktop 12-SP3 (src): gcc8-8.2.1+r264010-1.3.3 SUSE Enterprise Storage 4 (src): gcc8-8.2.1+r264010-1.3.3 SUSE CaaS Platform ALL (src): gcc8-8.2.1+r264010-1.3.3 SUSE CaaS Platform 3.0 (src): gcc8-8.2.1+r264010-1.3.3 OpenStack Cloud Magnum Orchestration 7 (src): gcc8-8.2.1+r264010-1.3.3
SUSE-RU-2018:1155-2: An update that has 8 recommended fixes can now be installed. Category: recommended (important) Bug References: 1061667,1068967,1074621,1083290,1083946,1084812,1087550,1087930 CVE References: Sources used: SUSE Linux Enterprise Server 12-SP2-BCL (src): gcc7-7.3.1+r258812-5.2
SUSE-RU-2018:3096-2: An update that has 5 recommended fixes can now be installed. Category: recommended (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: Sources used: SUSE Linux Enterprise Server 12-SP2-BCL (src): gcc8-8.2.1+r264010-1.3.3
openSUSE-OU-2018:3541-1: An update that has 5 optional fixes can now be installed. Category: optional (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: Sources used: openSUSE Leap 42.3 (src): cross-nvptx-gcc8-8.2.1+r264010-2.1, gcc8-8.2.1+r264010-2.3, gcc8-testresults-8.2.1+r264010-2.2
SUSE-RU-2018:3655-1: An update that has 5 recommended fixes can now be installed. Category: recommended (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: Sources used: SUSE Linux Enterprise Module for Development Tools 15 (src): cross-nvptx-gcc8-8.2.1+r264010-1.3.3, gcc8-8.2.1+r264010-1.3.7 SUSE Linux Enterprise Module for Basesystem 15 (src): gcc8-8.2.1+r264010-1.3.7
openSUSE-RU-2018:4172-1: An update that has 5 recommended fixes can now be installed. Category: recommended (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: Sources used: openSUSE Leap 15.0 (src): cross-nvptx-gcc8-8.2.1+r264010-lp150.2.1, gcc8-8.2.1+r264010-lp150.2.3
SUSE-RU-2018:3655-2: An update that has 5 recommended fixes can now be installed. Category: recommended (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: Sources used: SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src): gcc8-8.2.1+r264010-1.3.7
SUSE-RU-2018:3655-3: An update that has 5 recommended fixes can now be installed. Category: recommended (low) Bug References: 1084812,1084842,1087550,1094222,1102564 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Server for SAP 15 (src): cross-nvptx-gcc8-8.2.1+r264010-1.3.3, gcc8-8.2.1+r264010-1.3.7 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): cross-nvptx-gcc8-8.2.1+r264010-1.3.3, gcc8-8.2.1+r264010-1.3.7 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): cross-nvptx-gcc8-8.2.1+r264010-1.3.3, gcc8-8.2.1+r264010-1.3.7 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.