[Bug 1924231] Re: Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on.

This is the bug tracker for upstream QEMU. If you'd like to request Ubuntu to backport some fix into their packages of QEMU, you'll need to file it against the Ubuntu QEMU package bug tracker. Since those bugs are also tracked in Launchpad, I'll try re-componenting this bug report to the Ubuntu

[Bug 1908063] Re: gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

It looks like the reason QEMU's test suite passed was that the older Ubuntu gdb didn't have a fix for LP:1901026 (support remote connection over UNIX domain socket), so the test suite would simply skip the offending test and never get as far as falling over the assertion failure. After pulling

[Bug 1908063] Re: gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

Further testing with the old gdb-8.1-0ubuntu3 package shows that this isn't a regression since then, as that version fails too. I must have been misled by the apt history.log somehow; sorry for the confusion there. -- You received this bug notification because you are a member of Ubuntu Bugs,

[Bug 1908063] [NEW] gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

Public bug reported: This bug is a regression introduced in 8.1.1-0ubuntu1 for Bionic -- the previous 8.1-0ubuntu3.2 gdb works fine with QEMU's gdbstub. Reproduce: Get the sources for QEMU 5.2.0, and build the aarch64-linux-user target. (It looks like Bionic's QEMU is old enough that it doesn't

[Bug 1163034] Re: linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code)

This bug is still valid, yes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1163034 Title: linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils

Re: [Qemu-devel] [Bug 1793183] [NEW] apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

On 18 September 2018 at 10:24, Dmitry Isaykin wrote: > Public bug reported: > > Error log: > > /tmp/qemu-2.10+dfsg/util/memfd.c:40:12: error: static declaration of > ‘memfd_create’ follows non-static declaration > static int memfd_create(const char *name, unsigned int flags) >

[Bug 955379] Re: cmake hangs with qemu-arm-static

>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

[Bug 1740219] Re: static linux-user ARM emulation has several-second startup time

We don't generally mark bugs 'fix released' until the final (non-rc) release is made. ** Changed in: qemu Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1749393] Re: [PATCH] linux-user: Allocate extra space for brk in PIE executable

On 16 March 2018 at 10:34, Richard Henderson wrote: > Limit this to 16M; there does not appear to be any special > support for this in the kernel itself, at least for i686. > > Fixes: https://bugs.launchpad.net/bugs/1749393 > Signed-off-by: Richard Henderson

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

There seem to be two parts to this. Firstly, with a big reserved-region, which is the default for 32-bit-guest-on-64-bit-host, this code in main.c: if (reserved_va) { mmap_next_start = reserved_va; } says to start trying for the next mmap address at the top of the

[Bug 1163034] Re: linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code)

** Summary changed: - linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28 configure check code) + linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) ** Tags added: linux-user -- You received this

[Bug 1726394] Re: Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

v2 of the patch (https://lists.gnu.org/archive/html/qemu- devel/2017-11/msg01199.html) has been accepted upstream, though it isn't in master yet. ** Tags added: linux-user ** Changed in: qemu Status: New => In Progress -- You received this bug notification because you are a member of

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

We think we've fixed our linux-user threading issues, so if there are still problems as of qemu-2.11 or later, please raise a fresh bug report with repro instructions. ** Changed in: qemu Status: Confirmed => Fix Committed -- You received this bug notification because you are a member

[Bug 1077116] Re: automoc4 segfaults when building in an armhf pbuilder on an amd64 host

I was able to reproduce this failure with QEMU 2.5, and the code runs OK under QEMU current master, so I think this is fixed by the threading/signal handling bugfixes we've done between then and now. I'm going to close this as will-be-fixed-in-2.11 (though it's quite possible it's already fixed in

[Bug 1319100] Re: qemu-arm-static bug in signal handling causes mono and java to hang

Yes it did. ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1319100 Title: qemu-arm-static bug in signal handling causes mono and

[Bug 1615021] Re: Unable to network boot Ubuntu 16.04 installer normally on Briggs

Just a note that the udev rules change from comment 6 seems to be necessary to reliably get an image booted under QEMU to bring up a getty on the serial console. What seems to happen without it is that udevd spends all its time running copies of 'readlink', and it doesn't get around to telling

[Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

I finally got round to looking into why the test case from comment #27 worked on x86-64 guests and i386-guest-on-i386-host but not on arm- on-x86-64. This turns out to be a wrong structure definition which meant we weren't handling the 32-bit-guest-on-64-bit-host combinations correctly. I've sent

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

In the upcoming QEMU 2.7 we've removed the abort() call in this code path, and instead will print an error message which hopefully is clearer at suggesting to users where they've gone wrong rather than implying that this is a QEMU bug: == qemu-system-arm: Trying to execute code outside RAM or

[Bug 955379] Re: cmake hangs with qemu-arm-static

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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/955379 Title: cmake

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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 Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1285363] Re: qemu-aarch64-static segfaults

We've now overhauled the signal handling code in upstream QEMU, and it has its own implementation of the basic idea in the patch from comment 1 (which is "don't let the guest block SIGSEGV"). ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because

[Bug 1319100] Re: qemu-arm-static bug in signal handling causes mono and java to hang

Recent changes to QEMU's handling of signals fix this hang trying to run mono under QEMU; they should be out in QEMU 2.7. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: 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 Ubuntu

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

This post to the dnsmasq-discuss list: http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2015q2/009575.html suggests that the bug has been fixed in a later version of dnsmasq and should be fairly easy to backport. -- You received this bug notification because you are a member of Ubuntu

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

Ah, it looks like Colin did just cherry pick the fix for this bug; from the backport .deb's changelog: +dnsmasq (2.68-1ubuntu0.1ppa1) trusty; urgency=medium + + * Cherry-pick from 2.73: +- Correctly sanitise DNS header bits in answer when recreating query for + retry. + + -- Colin

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

This post to the dnsmasq-discuss list: http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2015q2/009575.html suggests that the bug has been fixed in a later version of dnsmasq and should be fairly easy to backport. -- You received this bug notification because you are a member of Ubuntu

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

Ah, it looks like Colin did just cherry pick the fix for this bug; from the backport .deb's changelog: +dnsmasq (2.68-1ubuntu0.1ppa1) trusty; urgency=medium + + * Cherry-pick from 2.73: +- Correctly sanitise DNS header bits in answer when recreating query for + retry. + + -- Colin

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

I wrote: "PS: it's possible that that commit doesn't actually fix the underlying kernel crash, it just means that rr isn't triggering it any more, and that if you modified EFLAGS via the ptrace interface rather than r11 you'd get the crash back again." but looking at the kernel I think that is

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

PS: it's possible that that commit doesn't actually fix the underlying kernel crash, it just means that rr isn't triggering it any more, and that if you modified EFLAGS via the ptrace interface rather than r11 you'd get the crash back again. -- You received this bug notification because you are

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

I've now completed the kernel git bisect. git bisect says the commit which fixed this issue is 29722cd4ef666705b2eda1c3ba44435488e509eb ("x86/asm/entry/64: Save R11 into pt_regs->flags on SYSCALL64 fastpath"). This fits in with the discovery on the rr side that the rr commit which started causing

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

I retried with a workaround for the rr bug I described in "caveat (2)" and the kernel still does not lockup, so I am now confident that this bug is not present in the upstream kernel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

No, I don't think this was associated with a kernel upgrade, though it's hard to say for certain as I hadn't run the test suite in some months. I suspect it's more that rr's test suite got more complex and included some stress tests that reveal pre-existing kernel bugs. I will test the upstream

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

I tested with linux-headers-4.4.0-040400 / linux- headers-4.4.0-040400-generic / linux-image-4.4.0-040400-generic 4.4.0-040400.201601101930. The kernel lockups did *not* reproduce. Two caveats: (1) I did get this kernel warning in the log: Jan 21 18:00:08 e104462 kernel: [ 171.577000]

[Bug 1535307] [NEW] running 'rr' make check causes kernel "hard LOCKUP"

Public bug reported: Running the 'rr' make check on Ubuntu Trusty causes the machine to become unusable because the kernel crashes. (rr build-and-make-check instructions: https://github.com/mozilla/rr/wiki/Building-And- Installing) This is 3.13.0-74-generic #118-Ubuntu for x86_64. This is rr

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

#10: if that's your entire command line then that's expected behaviour, and is saying "we just executed a pile of zeros and fell off the end of RAM". You need to supply a kernel to run. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

#10: if that's your entire command line then that's expected behaviour, and is saying "we just executed a pile of zeros and fell off the end of RAM". You need to supply a kernel to run. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 1463172] Re: destination arm board hangs after migration from x86 source

I think it is in theory supposed to work, but possibly in practice it doesn't... -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1463172 Title: destination arm board hangs after

[Bug 1463172] Re: destination arm board hangs after migration from x86 source

I think it is in theory supposed to work, but possibly in practice it doesn't... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1463172 Title: destination arm board hangs after migration from x86

[Bug 1478035] [NEW] pkg-config --static --libs gnutls includes an option that gcc doesn't recognize (-R)

Public bug reported: The output of pkg-config --static --libs gnutls is the following: -R/usr/lib/x86_64-linux-gnu -lgnutls -lgcrypt -lgpg-error -ltasn1 -lz -lp11-kit However, gcc doesn't understand the -R option, so you can't pass the pkg-config output as a set of gcc command line options the

[Bug 1349277] Re: AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater

** Changed in: qemu Status: New = Fix Committed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1349277 Title: AArch64 emulation ignores SPSel=0 when taking (or returning from)

[Bug 1349277] Re: AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater

** Changed in: qemu Status: New = Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1349277 Title: AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception

Re: [Qemu-devel] [Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

On 9 August 2014 07:15, Erik de Castro Lopo 1042...@bugs.launchpad.net wrote: Unfortunately the test case @pittit submitted is far harder to support than the original test case. In this case the timer_create() syscall gets passed pointers to functions and data in the target's address space and

[Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

Patch which seems to at least make the test case work (tested with i386-on-i386 linux-user): http://patchwork.ozlabs.org/patch/378769/ -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu.

Re: [Qemu-devel] [Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

On 9 August 2014 07:15, Erik de Castro Lopo 1042...@bugs.launchpad.net wrote: Unfortunately the test case @pittit submitted is far harder to support than the original test case. In this case the timer_create() syscall gets passed pointers to functions and data in the target's address space and

[Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

Patch which seems to at least make the test case work (tested with i386-on-i386 linux-user): http://patchwork.ozlabs.org/patch/378769/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1042388 Title:

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

I think it's likely to happen eventually; it depends rather on the balance between this and other work priorities (at least if it's going to be Linaro doing the work). Regardless, I'm not taking hacky workarounds like this into mainline (hacks are hard to get out once you let them in, and they

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

Well, it won't make anything any worse, so it's your call based on how much it actually improves your failure rate I guess. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1350435 Title:

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

I think it's likely to happen eventually; it depends rather on the balance between this and other work priorities (at least if it's going to be Linaro doing the work). Regardless, I'm not taking hacky workarounds like this into mainline (hacks are hard to get out once you let them in, and they

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

Well, it won't make anything any worse, so it's your call based on how much it actually improves your failure rate I guess. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1350435 Title: tcg.c:1693:

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

That patch is not in mainline because it's an appalling hack. If we care about multi-threaded guests we need to fix them properly, not paper over the issues by constraining multiple threads to one CPU in the hopes the race conditions don't bite us so often. -- You received this bug notification

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

That patch is not in mainline because it's an appalling hack. If we care about multi-threaded guests we need to fix them properly, not paper over the issues by constraining multiple threads to one CPU in the hopes the race conditions don't bite us so often. -- You received this bug notification

[Bug 955379] Re: cmake hangs with qemu-arm-static

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 Ubuntu Bugs, which is

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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 Ubuntu Bugs, which is

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

On 9 May 2014 09:14, Riku Voipio riku.voi...@iki.fi wrote: Hi Craig, On Wed, May 07, 2014 at 03:53:38PM +0100, Peter Maydell wrote: Original 2011 patch: http://lists.gnu.org/archive/html/qemu-trivial/2011-12/msg00025.html (hitting the 'reply' button gets us back the original email address

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

On 9 May 2014 09:14, Riku Voipio riku.voi...@iki.fi wrote: Hi Craig, On Wed, May 07, 2014 at 03:53:38PM +0100, Peter Maydell wrote: Original 2011 patch: http://lists.gnu.org/archive/html/qemu-trivial/2011-12/msg00025.html (hitting the 'reply' button gets us back the original email address

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

On 7 May 2014 15:34, Paul Jimenez 1317...@bugs.launchpad.net wrote: Bug description: Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg- 2ubuntu1. Reported to qemu and patch submitted long ago by the guy who wrote http://www.devttys0.com/2011/12/qemu-vs-sstrip/

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

On 7 May 2014 15:48, Peter Maydell peter.mayd...@linaro.org wrote: On 7 May 2014 15:34, Paul Jimenez 1317...@bugs.launchpad.net wrote: Bug description: Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg- 2ubuntu1. Reported to qemu and patch submitted long ago

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

On 7 May 2014 15:34, Paul Jimenez 1317...@bugs.launchpad.net wrote: Bug description: Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg- 2ubuntu1. Reported to qemu and patch submitted long ago by the guy who wrote http://www.devttys0.com/2011/12/qemu-vs-sstrip/

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

On 7 May 2014 15:48, Peter Maydell peter.mayd...@linaro.org wrote: On 7 May 2014 15:34, Paul Jimenez 1317...@bugs.launchpad.net wrote: Bug description: Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg- 2ubuntu1. Reported to qemu and patch submitted long ago

[Bug 1285363] Re: qemu-aarch64-static segfaults

Doing this only for aarch64 targets seems like a bad idea to me -- this isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own handler (so we can unprotect pages we've marked as read-only in order to catch guest writes to them so we can throw away invalidated translated code), and

[Bug 1285363] Re: qemu-aarch64-static segfaults

Doing this only for aarch64 targets seems like a bad idea to me -- this isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own handler (so we can unprotect pages we've marked as read-only in order to catch guest writes to them so we can throw away invalidated translated code), and

[Bug 1285505] Re: [ppa 2.0~git-20140225] SIGABRT with -virtfs

Actually, the interesting bit of the stack trace starts just below where you cut it off, because object_initialize_with_type() is just asserting that it wasn't called with a NULL pointer, so what we really want to know is what the caller was... -- You received this bug notification because you

[Bug 1285505] Re: [ppa 2.0~git-20140225] SIGABRT with -virtfs

Actually, the interesting bit of the stack trace starts just below where you cut it off, because object_initialize_with_type() is just asserting that it wasn't called with a NULL pointer, so what we really want to know is what the caller was... -- You received this bug notification because you

[Bug 1256546] Re: qemu-s390x-static: segmentation fault entering chroot

Does this patch fix this issue? http://patchwork.ozlabs.org/patch/309529/ -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1256546 Title: qemu-s390x-static: segmentation fault entering

[Bug 1256546] Re: qemu-s390x-static: segmentation fault entering chroot

Does this patch fix this issue? http://patchwork.ozlabs.org/patch/309529/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1256546 Title: qemu-s390x-static: segmentation fault entering chroot To

[Bug 1254672] Re: ps segfaults with qemu-arm-static

I suspect this is a NULL pointer access that happens in procps where it isn't handling an error path that it's not expecting somehow (either a syscall we're not implementing, or perhaps something like /proc not being mounted in your chroot environment, or something about qemu's emulation of some

[Bug 1246990] Re: [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped

The backtrace indicates that this is a multithreaded application. These won't work reliably under qemu-user : they tend to crash, as you have found. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu.

[Bug 1246990] Re: [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped

The backtrace indicates that this is a multithreaded application. These won't work reliably under qemu-user : they tend to crash, as you have found. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1163034] Re: linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28 configure check code)

Regarding bug 1042388, those are the posix timer syscalls, and I guess they've just been around long enough that apt expects them to exist. Anyway, we should just implement them in QEMU. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1163034] Re: linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28 configure check code)

** Summary changed: - gnutls28 fails to build from source in armhf + linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28 configure check code) ** Changed in: qemu Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu

[Bug 1163034] Re: gnutls28 fails to build from source in armhf

Actually, assuming the guest ARM glibc doesn't have the printf() bug the code is testing for, we shouldn't take the SIGSEGV anyway, so that's a red herring. The actual problem here is the setrlimit(). The conftest.c test case works by using rlimit to limit the address space. This generally

[Bug 1157066] Re: qemu-keymaps lacks en_us. REGRESSION: VMs do not boot out of Virtual Machine Manager any more

Of course, qemu-keymaps coming from linaro may not be a problem if it would include the en_us map :) It does include en_us, it's just putting all the keymaps in a different directory to the one qemu is looking for (/qemu-linaro/ vs /qemu/) -- You received this bug notification because you are

[Bug 1129571] Re: libreoffice armhf FTBFS

Well, you can try, but I don't think it is very likely to help. The patch is a hacky workaround for select() in particular, not for the entire class of hangs. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1129571] Re: libreoffice armhf FTBFS

John: it would be interesting to try to determine whether that hang has the same root cause as the cmake and boehm-gc hangs, ie the thing that is supposed to post the futex is a signal handler whose signal comes in either just before or during the syscall [either way, the emulated code for the

[Bug 1129571] Re: libreoffice armhf FTBFS

cmake bug: LP:955379. sketch of how to fix signal races: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1129571 Title: libreoffice

[Bug 1129571] Re: libreoffice armhf FTBFS

John: you might also like to try with this patchset applied: http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg04207.html as that fixes one category of races. There are still other races that can cause segfaults and other problems (as the cover letter describes) but it's possible this

[Bug 1129571] Re: libreoffice armhf FTBFS

Thanks for the patch. John, since you're going to be doing more QEMU work in future I'd encourage you to go through the process of submitting it to upstream's mailing list and shepherding it through the patch review process. Upstream's patch submission guidelines are here:

[Bug 1129571] Re: libreoffice armhf FTBFS

Well, the first step would be to provide a reasonably tractable set of reproduce instructions (at minimum, something like do this to set up a chroot, then in the chroot run this command and watch it SIGILL.) Also checking it still repros on 1.4.0 (just released) would be nice (though I don't think

[Bug 1129571] Re: libreoffice armhf FTBFS

The actual command from the build log: /usr/lib/jvm/java-6-openjdk-armhf/bin/java -cp .:../../unxlngr.pro/class:/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/rt.jar:.:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin

[Bug 571432] Re: qemu-system-arm crashed with SIGSEGV in subpage_register()

Closing as invalid for QEMU because it's an Incomplete bug against an ancient QEMU version. ** Changed in: qemu Status: Incomplete = Invalid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu.

[Bug 393430] Re: kvm: use PulseAudio instead of ALSA

(ancient distro packaging bug so never valid for QEMU upstream itself; marking Invalid there) ** Changed in: qemu Status: Incomplete = Invalid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to kvm in Ubuntu.

[Bug 571432] Re: qemu-system-arm crashed with SIGSEGV in subpage_register()

Closing as invalid for QEMU because it's an Incomplete bug against an ancient QEMU version. ** Changed in: qemu Status: Incomplete = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 393430] Re: kvm: use PulseAudio instead of ALSA

(ancient distro packaging bug so never valid for QEMU upstream itself; marking Invalid there) ** Changed in: qemu Status: Incomplete = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

qemu-system-arm -M versatilepb -kernel u-boot.bin [...] Trying to execute code outside RAM or ROM This almost always means that you tried to execute a guest binary which wasn't for the VersatilePB. Without more info about exactly what this u-boot.bin file was this bug report can't progress any

[Bug 955379] Re: cmake hangs with qemu-arm-static

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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/955379 Title: cmake

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

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

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

** Changed in: qemu Status: New = Confirmed ** Changed in: qemu-linaro Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/955379 Title: cmake hangs with

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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 Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

[Bug 955379] Re: cmake hangs with qemu-arm-static

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

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

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

  1   2   3   >