>From upstream QEMU's point of view the status of this bug is "it's an
old bug report that tended to accumulate 'this seems like it's the same
as my bug' extra comments; we have fixed the underlying cause of the
original bug, so leave this one closed and file new ones with proper
reproducer
What's the status of this bug? I see LP: #1764555 has been marked as invalid as
the test environment was tainted - does this imply the fix was correct and
everything is working as intended?
The bug is marked for 16.04.5. If it's still something we intent to get
released for the point-release we
I have filed a new bug:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1764555
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
Steps to reproduce:
# on ubuntu bionic amd64 host
sudo apt-add-repository ppa:ev3dev/tools
# assuming apt-add-repository does apt update now
sudo apt install pbuilder-ev3dev git
git clone --depth=1 https://github.com/ev3dev/opencv
cd opencv
OS=debian ARCH=armhf DIST=stretch pbuilder-ev3dev base
I am seeing the same symptoms as the original poster. I'm building the
opencv package in a debian stretch armfh chroot on a ubuntu bionic amd64
host. So, I'm guessing that the race condition wasn't entirely fixed or
there has been some sort of regression.
--
You received this bug notification
That means our assumption taken in comment #63 that it was fixed in
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=014628a705bdaf31c09915
either was wrong (unset fix released) - or this is a similar but not the
same issue (which would imply a new bug since this already has plenty of
potentially
** Also affects: qemu (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: qemu-linaro (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Confirmed
** Changed in: qemu (Ubuntu)
Milestone: None => ubuntu-16.04.5
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Fixes should be part of QEMU v2.7.0, e.g.:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=014628a705bdaf31c09915
... so setting the status to "Fix Released" now.
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of
Hello, Peter Maydell
we have new qemu-arm hang issue.
I guess you are busy for new qemu 2.7 release.
But, could you please help us if you have time?
https://bugs.launchpad.net/qemu/+bug/1617929
Very thank you in advance :-)
--
You received this bug notification because you are a member of
OK, so the behaviour you saw is expected since we didn't fix 32-bit
hosts until a bit later; but they should both be fixed now.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake
Thanks for your feedback.
I was running this on intel i7 Ubuntu 64bit.
but I used 32bit qemu as you suspected.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with
Thanks for that test case; unfortunately it works fine for me (both with
current git master and with commit b66e10e4c9ae7384).
Can you tell me what host machine you're running this on, and in
particular whether it is 32 bit or 64 bit? Commit b66e10e4c9ae7384 will
fix this hang for x86-64 (64-bit
chroot env. attached (120M tar).
I hope you can reproduce with this chroot.
Instructions to reproduce
- extract, chroot
- su - abuild
- cd /home/abuild/rpmbuild/BUILD/cmake-2.8.5/armv7l-tizen-linux-gnueabi/
- Bootstrap.cmk/cmake .. -CBootstrap.cmk/InitialCacheFlags.cmake '-GUnix
Makefiles'
Please provide exact reproduction instructions -- I need enough
information that I can completely replicate your setup and what you're
doing: exactly how you've set up any chroot or whatever other guest
setup you have, what cmake command you're running, and so on.
--
You received this bug
I test with b66e10e4c9ae738412b9742db49457f6b703e349 before.
I test with 14c7d99333e4a474c65bdae6f99aa8837e8078e6 today and no hang.
But I had to revert 4fb8320a2efb2216c7ddcc929ad0362f4e285681 which causes
segfault.
--
You received this bug notification because you are a member of qemu-
Please can you (a) double check that you're definitely running the
correct new QEMU and (b) provide exact reproduction instructions so I
can investigate the hang.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I'm so sorry that
cmake still hang with my Ubuntu 12.04 and openSUSE 12.3 machine.
and the hanging point has changed. cmake hung at select() with old qemu. but
now cmake hang at pselect6() with new qemu.
And also I could continue build by sending SIGCHLD to hanging qemu. but now
cmake still hang
I'm going to mark this bug as 'fix committed', because changes which
should fix both the cmake and the git hang are now in QEMU git master.
If people have test cases for things which still fail on current git
master, please open fresh bugs for them.
** Changed in: qemu
Status: Confirmed
That's great! it works for me. Thanks a lot.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
Confirmed
Status in Linaro QEMU:
A prebuilt package of qemu-user built statically at:
http://repo.linaro.org/ubuntu/linaro-tools/pool/main/q/qemu/qemu-user-
static_2.6.0+git931+g9bbbf64-1linarojessie1_amd64.deb
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Please try the latest qemu git HEAD, Timothys and Peters fixes have been
merged in.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
That's great news - thanks very much. This will make working on RetroPie
development in a chroot much easier (we have workarounds to avoid using
git because of this issue).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Thanks for that report of a hang running git. I've been able to identify and
fix the bug (it is a different problem to the issue that was causing cmake to
hang) and have sent a patch:
http://patchwork.ozlabs.org/patch/631708/
That fix will hopefully make it into QEMU 2.7.
--
You received this
I get a hang doing this most times in an emulated ARM chroot with qemu-
arm-static (Raspbian). Host machine is x86_64 Ubuntu 16.04 running qemu
2.5.0.
git clone --depth 1 https://github.com/libretro/picodrive.git
cd picodrive &&
git submodule update --init
--
You received this bug notification
I was hoping for a "run this command" level of reproducer :-)
Alternatively, if anybody's conveniently able to build and test a new QEMU with
whatever was failing for them, you can try the git branch
https://git.linaro.org/people/peter.maydell/qemu-arm.git sigrace-fixes
--
You received this
iirc i've was able to reproduce this bug every time while compiling
kdelibs4 on a chrooted arm image
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Does anybody have a reliable reproduce case for this bug? I have some
patches I'd like to test which I think should fix it, but I cannot get
the test case attached in comment #10 to hang at all, even without the
fixes.
--
You received this bug notification because you are a member of qemu-
ok, i've found a better place for patchset download:
https://patchwork.ozlabs.org/project/qemu-
devel/list/?submitter=Timothy+Baldwin=linux-user
unfortunately cmake still hangs in a way that even sending SIGCHLD
doesn't wake it up, i have to send SIGKILL to stop it and consequently
breaking the
On Sat, Sep 19, 2015 at 4:31 PM, skunk wrote:
> thank you peter, do you know if timothy has a github account?
> i'm too lazy to copy the 34 patches by hand from the mailing list...
The patches utility can do this for you off the list:
https://github.com/stefanha/qemu-patches
Recent patchseries which I think ought to be a proper fix for this bug:
https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01388.html
It does need some more work to address review comments but it's sound in
principle.
--
You received this bug notification because you are a member of qemu-
the above patch still applies with qemu 2.4, but then it fails to build
with the following error:
x86_64-pc-linux-gnu-gcc
-I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/tcg
-I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/tcg/i386
thank you peter, do you know if timothy has a github account?
i'm too lazy to copy the 34 patches by hand from the mailing list...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake
Most rececnt qemu-devel discussion and a promising looking approach (ie it
would work whereas my idea linked from comment #14 would not):
http://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04569.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
It's just excellent illustration why I hate pipes.
So CMake guys can remove this crap from their code and use socketpair()
or like instead.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
What cmake is doing is an entirely legitimate and well-recognized Unix
idiom for converting signals into effects on filedescriptors for
select(), and there's no reason for them to change it. This is
absolutely a bug in QEMU, it's just one that's not easy for us to fix.
(Using socketpair would not
Isn't it fixed yet with latest qemu 2.1 rc?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
Confirmed
Status in Linaro QEMU:
No; this is a a complicated issue to fix that basically requires a
significant restructuring of the linux-user code. Nobody's done that yet
and as far as I know nobody's said they plan to do so either.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
LK: Ok, good catch, that might be more suitable option. Thanks,
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
Confirmed
Status in
Janne Karhunen: Do you think if it is correct that return 0 when
ts-signal_pending is true and select() returns '0' (timeout)? Because the
caller doesn't expect to return select() with 0, should we return other error
values such as EINTR?
When I modified you patch to return EINTR if select()
I wouldn't mind giving this patch a test if given some instructions on
doing so.
I am also unable to compile pcl because of this bug.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
Luke Kim: quite unlikely that above patch would cause the issue you
see.. are you sure something else did not break in your environment?
Can you execute that same make manually?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I have tested cmake.patch but it doesn't work for me.
It didn't hang but it failed to run gmake.
I applied this patch onto qemu-1.3.
[ 52s] -- Detecting CXX compiler ABI info
[ 53s] CMake Error: Generator: execution of make failed. Make command was:
/usr/bin/gmake cmTryCompileExec/fast
[
Just out of interest tried how far the timeout hackery can go working
around the issue. Well, looks like it goes quite far: having previously
reproduced the hang in 4-5 runs and in under a minute, now have had this
running without a hang for an hour. I will also test the patch under OBS
worker(s)
Some kind of semi-workaround patch attached. It seems to leave this kind
of race window for me (for select which is worse):
0x6004bf98 +136: xor%r8d,%r8d
0x6004bf9b +139: test %eax,%eax
0x6004bf9d +141: jne0x6004c2b7 do_select+935
The attachment racy workaround patch of this bug report has been
identified as being a patch. The ubuntu-reviewers team has been
subscribed to the bug report so that they can review the patch. In the
event that this is in fact not a patch you can resolve this situation by
removing the tag
And what would break if we make poll timeout instantly in case there are
signals pending and restart the given syscall after handlers run?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
On 4 December 2012 11:21, Janne Karhunen 955...@bugs.launchpad.net wrote:
And what would break if we make poll timeout instantly in case there are
signals pending and restart the given syscall after handlers run?
If there are signals pending in the host kernel poll will *already*
return
Moreover, is there even a need to restart anything, just make it async
call in case signals were pending?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with
Never mind, async/zero timeout call would suffer from same (albeit now
tiny) race. It would make this far less invasive as a change though.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Yes. You can never shut the window completely trying to do it that way,
which is why you need fix the problem properly instead.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake
On 01.12.2012, at 12:27, Peter Maydell wrote:
On 1 December 2012 10:29, Janne Karhunen 955...@bugs.launchpad.net wrote:
this blocks forever, because the thing that would wake it up is the
signal handler writing to the pipe we're selecting on, but we will never
run the signal handler until
On 3 December 2012 21:20, Alexander Graf ag...@suse.de wrote:
Could you please try and see if this patch makes a difference?
http://repo.or.cz/w/qemu/agraf.git/patch/489924aa0115dc6cfcd4e91b0747da4ff8425d1f
I think the answer will turn out to be no (though it's worth
testing anyway), because
So I guess 'raciness' of my proposed patch would only depend on how
small I could squeeze the section between 'sigpending' flag comparison
and actual syscall entering?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
** Changed in: qemu
Status: New = Confirmed
** Changed in: qemu-linaro
Status: New = Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with
this blocks forever, because the thing that would wake it up is the
signal handler writing to the pipe we're selecting on, but we will never
run the signal handler until select exits
Duh, makes sense, have to think about this. Thank you for great analysis
:)
Apparently have to dig into qemu's
On 1 December 2012 10:29, Janne Karhunen 955...@bugs.launchpad.net wrote:
this blocks forever, because the thing that would wake it up is the
signal handler writing to the pipe we're selecting on, but we will never
run the signal handler until select exits
Duh, makes sense, have to think
That test case seems to have very weak reproducibility -- I think I saw
a hang perhaps once in 30+ runs. That's not really usable for debugging,
I'm afraid :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
If that is the case for you (for me it reproduces it every 4-5 runs or so),
there are two options:
1) put while(true) loop around the rpmbuild and you will hit it always, or
2) I can wrap up a bit bigger cmake usecase that systematically hits it. Warn
you though, size will jump to 200M.
--
You
I'll take the bigger usecase, please. It's pretty hard to debug race
conditions that don't manifest often enough to let you do useful
logging.
From the time or two I caught it hanging, it looks like qemu is sleeping in
poll, and there's a zombie child process. I wonder if what's happening is
Actually I just managed to interact with a hung qemu under a debugger
sufficiently to confirm what is happening here.
CMake's code for running child processes (in kwsys/ProcessUNIX.c) does this:
On UNIX, a child process is forked to exec the program. Three output pipes
are read by the parent
Ok, test case attached (80M tar). This hugely stripped one is not 100%
reproducer, but do few loops and you will hit it. Instructions for using:
- extract, chroot
- cd /home/abuild/rpmbuild
- su abuild
- export RPM_BUILD_ROOT=$PWD
- rpmbuild -ba SOURCES/libshortcut.spec
** Attachment added:
Mind you, when you hit the bug it just hangs and cmake test errors are
just to speed up the process of hitting the bug (if cmake just fails you
did not hit the bug). Feel free to try with any qemu variant, they all
hang similarly when bug is hit. I think that root had some suse 1.2 one
inside.
--
Peter, I have qemu chrootable test case under which you could fire one
command to hit the bug reliably. Only issue is, are you willing to take
a peek at 100M extractable tarball? If not, I'll try to create a smaller
one.
--
You received this bug notification because you are a member of qemu-
On 28 November 2012 08:42, Janne Karhunen 955...@bugs.launchpad.net wrote:
Peter, I have qemu chrootable test case under which you could fire one
command to hit the bug reliably. Only issue is, are you willing to take
a peek at 100M extractable tarball? If not, I'll try to create a smaller
Peter, if you try to run the cmake file for lp:unity you should hit it.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
New
Status
On 25 November 2012 20:40, Tim Penhey tim.pen...@canonical.com wrote:
Peter, if you try to run the cmake file for lp:unity you should hit it.
I'm afraid that's way too little detail. Assume I know nothing about
launchpad, cmake or unity, and give me a set of instructions I
can run on a machine
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu-linaro (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
If you can provide a simple straightforward reproduce case that would be
useful.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
Status in QEMU:
New
** Also affects: qemu-linaro
Importance: Undecided
Status: New
** Also affects: qemu-linaro (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I am also having this issue with latest qemu on quantal using an armhf
chroot.
cmake will occasionally finish, but mostly it just hangs, most often in
the pkg_check bits.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I can confirm that this is still an issue even with latest qemu-linaro,
from Quantal (1.2.0-2012.09-0ubuntu1).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with
I have found several places cmake may hang, with either qemu-arm-static
or mipsel, and in debian (testing) as well as in Ubuntu. One of them is
the cmake check for c++ compiler, which can be overridden. Things that
use cmake's pkg_check_modules and pkg-config files will also hang.
Curiously,
73 matches
Mail list logo