summary refs log tree commit diff stats
path: root/results/classifier/118/all/1861161
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/all/1861161')
-rw-r--r--results/classifier/118/all/1861161176
1 files changed, 176 insertions, 0 deletions
diff --git a/results/classifier/118/all/1861161 b/results/classifier/118/all/1861161
new file mode 100644
index 00000000..fcae3667
--- /dev/null
+++ b/results/classifier/118/all/1861161
@@ -0,0 +1,176 @@
+graphic: 0.990
+register: 0.989
+performance: 0.988
+device: 0.986
+debug: 0.985
+peripherals: 0.982
+assembly: 0.981
+permissions: 0.981
+architecture: 0.980
+virtual: 0.979
+user-level: 0.978
+semantic: 0.977
+hypervisor: 0.975
+arm: 0.974
+files: 0.972
+mistranslation: 0.971
+PID: 0.970
+risc-v: 0.967
+socket: 0.967
+VMM: 0.966
+boot: 0.965
+ppc: 0.964
+TCG: 0.961
+KVM: 0.961
+kernel: 0.955
+vnc: 0.952
+x86: 0.941
+network: 0.888
+i386: 0.771
+
+qemu-arm-static stuck with 100% CPU when cross-compiling emacs
+
+Hello,
+
+I'm trying to build multi-arch docker images for https://hub.docker.com/r/silex/emacs.
+
+Here is the machine I'm building on:
+
+root@ubuntu-4gb-fsn1-1:~# lsb_release -a
+No LSB modules are available.
+Distributor ID: Ubuntu
+Description:    Ubuntu 18.04.3 LTS
+Release:        18.04
+Codename:       bionic
+root@ubuntu-4gb-fsn1-1:~# uname -a
+Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+
+Whenever I try to build the following alpine Dockerfile https://gitlab.com/Silex777/docker-emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile with this command:
+
+$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+$ docker build --pull -t test --platform arm .
+
+It builds fine until this:
+
+root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu
+root     26473 26465 99 14:26 pts/0    01:59:58 /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el
+
+This is supposed to take a few seconds, but in practice it takes 100% CPU and never ends. When I strace the process I see this:
+
+getdents64(5, /* 0 entries */, 2048)    = 0
+lseek(5, 0, SEEK_SET)                   = 0
+getdents64(5, /* 5 entries */, 2048)    = 120
+tgkill(5875, 5878, SIGRT_2)             = -1 EAGAIN (Resource temporarily unavailable)
+getdents64(5, /* 0 entries */, 2048)    = 0
+lseek(5, 0, SEEK_SET)                   = 0
+getdents64(5, /* 5 entries */, 2048)    = 120
+tgkill(5875, 5878, SIGRT_2)             = -1 EAGAIN (Resource temporarily unavailable)
+getdents64(5, /* 0 entries */, 2048)    = 0
+lseek(5, 0, SEEK_SET)                   = 0
+getdents64(5, /* 5 entries */, 2048)    = 120
+tgkill(5875, 5878, SIGRT_2)             = -1 EAGAIN (Resource temporarily unavailable)
+getdents64(5, /* 0 entries */, 2048)    = 0
+lseek(5, 0, SEEK_SET)                   = 0
+getdents64(5, /* 5 entries */, 2048)    = 120
+tgkill(5875, 5878, SIGRT_2)             = -1 EAGAIN (Resource temporarily unavailable)
+getdents64(5, /* 0 entries */, 2048)    = 0
+lseek(5, 0, SEEK_SET)                   = 0
+getdents64(5, /* 5 entries */, 2048)    = 120
+tgkill(5875, 5878, SIGRT_2)             = -1 EAGAIN (Resource temporarily unavailable)
+
+It happens with all the QEMU versions I tested: 
+- 2.11.1 (OS version)
+- 4.1.1-1 (from multiarch/qemu-user-static:4.1.1-1)
+- 4.2.0-2 (from multiarch/qemu-user-static)
+
+Any ideas of what I could do to debug it further?
+
+Kind regards,
+Philippe
+
+Given the presence of getdents64 in the strace, I wonder if you are running into LP:1805913. You could test this theory by running the test with a host filesystem that is not ext4.
+
+
+Thanks. It matches my bug because ubuntu:18.04 has a glibc 2.27 while alpine 3.9 has glib 2.58, and your bug report mentions that 2.27 has not the bug, so it makes sense.
+
+However I don't see how not having the host filesystem as ext4 would change anything, can you elaborate? Also, what filesystem do you recommand?
+
+Okay, currently testing XFS. Using newer version of glibc on alpine triggered other problems, like 0% CPU processes stuck on FUTEX_WAIT.
+
+Building on XFS does the same thing :-( To test I bind mounted my XFS partition on `/var/lib/docker` so everything docker was stored on XFS. Not sure if this is what you meant. 
+
+I tried several workarounds including removing `dir_index` from ext4 partitions and using a 32 bit qemu-user-static version, but it does not work:
+
+The process still gets stuck in a loop involving `getdents64`:
+
+
+```
+root@earth:~# file /usr/bin/qemu-arm-static
+/usr/bin/qemu-arm-static: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=ff1224d87ca5dece8d0b0f5735cfee7fae97ee58, stripped
+
+root@earth:~# ps afx | grep qemu
+21031 pts/0    S+     0:00          \_ grep --color=auto qemu
+ 1036 ?        Ss     0:00 /usr/sbin/qemu-ga --daemonize -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0
+10584 ?        Ssl    0:00      |   |   \_ /usr/bin/qemu-arm-static /usr/bin/make install
+28768 ?        Sl     0:01      |   |       \_ /usr/bin/qemu-arm-static /usr/bin/make -C src VCSWITNESS=$(srcdir)/../.git/logs/HEAD all
+16718 ?        Sl     0:00      |   |           \_ /usr/bin/qemu-arm-static /usr/bin/make -C ../lisp compile-first EMACS=../src/bootstrap-emacs
+16726 ?        Rl    48:24      |   |               \_ /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el
+10696 ?        Ssl    0:00      |       \_ /usr/bin/qemu-aarch64-static /usr/bin/make install
+10972 ?        Sl     0:02      |           \_ /usr/bin/qemu-aarch64-static /usr/bin/make -C src VCSWITNESS=$(srcdir)/../.git/logs/HEAD all
+20397 ?        Sl     0:00      |               \_ /usr/bin/qemu-aarch64-static /usr/bin/make -C ../lisp compile-first EMACS=../src/bootstrap-emacs
+20405 ?        Rl    24:09      |                   \_ /usr/bin/qemu-aarch64-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el
+
+root@earth:~# strace -p 16726
+clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=921230669}) = 0
+getdents64(5, /* 0 entries */, 2048)    = 0
+_llseek(5, 0, [0], SEEK_SET)            = 0
+getdents64(5, /* 5 entries */, 2048)    = 144
+tgkill(29984, 29987, SIGRT_2)           = -1 EAGAIN (Resource temporarily unavailable)
+clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=921642405}) = 0
+getdents64(5, /* 0 entries */, 2048)    = 0
+_llseek(5, 0, [0], SEEK_SET)            = 0
+getdents64(5, /* 5 entries */, 2048)    = 144
+tgkill(29984, 29987, SIGRT_2)           = -1 EAGAIN (Resource temporarily unavailable)
+clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=922333065}) = 0
+getdents64(5, /* 0 entries */, 2048)    = 0
+_llseek(5, 0, [0], SEEK_SET)            = 0
+getdents64(5, /* 5 entries */, 2048)    = 144
+tgkill(29984, 29987, SIGRT_2)           = -1 EAGAIN (Resource temporarily unavailable)
+clock_gettime(CLOCK_REALTIME, ^C{tv_sec=1584794027, tv_nsec=923201432}) = 0
+strace: Process 16726 detached
+```
+
+What is interesting is that the qemu-aarch64-static process also get stuck, which if I understand the bug correctly should not happen. I'll try stracing the process to figure out what happens.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+