Qemu zombi blocking everything in proot during CMake build

75 views
Skip to first unread message

Samuel Martin

unread,
Aug 4, 2014, 10:14:03 AM8/4/14
to proo...@googlegroups.com
Hi all,


(Apologies for this cryptic subject. Lemme explain the issue I'm facing.)

I'm using proot to build a number of packages for my target
(target=arm ; host=x86_64).
Everything works fine until CMake-based packages is built.

When trying to build cmake, during it bootstrap step, cmake uses its
own binary (a minimal one) to configure itself (the final program).
During cmake checks, qemu become zombi at some point, this does not
seems correctly catched by cmake, so it endlessly hangs... :-(

Here is some the end of the cmake log (in an emerge build), and the
process tree when everything is blocked:
http://code.bulix.org/2ie7jo-86676

Note:
- to get my proot shell back, I have to kill the build;
- it hangs at different point (not always the same check);
- if I load my system, cmake in proot may run correctly;
- I unsuccessfully try to attach a gdb on qemu or cmake to know where it hangs.
- an easy setup to reproduce the issue is: just trying to build cmake
using a stage3 (from gentoo or something else), this is not related to
emerge.


I don't really know where to look: is this a cmake issue, or a qemu
one or a proot one?
Any pointer how to investigate this is welcome.


Regards,


--
Samuel

Cédric VINCENT

unread,
Aug 4, 2014, 11:09:09 AM8/4/14
to Samuel Martin, proo...@googlegroups.com
Hello Samuel,
This is a known issue with QEMU user-mode: it doesn't handle
multi-threaded programs correctly [0].  As a workaround, I bind the
host version of multi-threaded programs over guest ones.  For example
[1]:

    proot -b /usr/bin/cmake -q qemu-arm -r [...]

That way, the host version of cmake is executed in lieu of the
QEMU-lated one.  Well, as of my understanding, this trick may not be
helpful in your case.

Sadly, this multi-threading problem seems to be due to the current
design of QEMU user-mode.  As a consequence, we [2] have decided to
write an alternative tool named UMEQ [3] that doesn't suffer from
these issues.  As of today, this tool is still a prototype but it can
already run some complex applications, like VLC [4] for ARM on x86_64:

    http://www.youtube.com/watch?v=fjG2Ym58M0s

However, we don't know yet when/if this tool will be productized.

Regards,
Cédric.


[0] https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg00367.html (not fixed, as of QEMU v2.1.0)

[1] https://github.com/cedric-vincent/proot-static-build/blob/6521685b/GNUmakefile#L14

[2] CEC team at STMicroelectronics

[3] User Mode Emulation Quest, and reverse anagram for QEMU

[4] heavily multi-threaded!

Reply all
Reply to author
Forward
0 new messages