This bug was fixed in the package qemu - 1:4.2-3ubuntu6.19
---
qemu (1:4.2-3ubuntu6.19) focal; urgency=medium
* d/p/u/lp-1749393-linux-user-Reserve-space-for-brk.patch: fix static
use cases needing a lot of brk space (LP: #1749393)
* d/p/u/lp-1929926-target-s390x-Fix-translati
Thank you Frank for that extra confirmation,
by now also all the blockers on the other bug fixed are good. I expect this to
be released as soon as the SRU Team is back from the Christmas shutdown.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscrib
i can confirm that focal-proposed package fixes problems for arm64 and
armhf on hostarch amd64
note: tried ppa listed here which fixes for arm64 but breaks armhf:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1928075/comments/15
steps for installing proposed Package:
cat
FYI the release of this is slowed down by the slow verification of bug
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1929926
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk(
Focal
old
$ sudo apt install --reinstall qemu-user-static=1:4.2-3ubuntu6.18
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 21.3 MB of archives.
After this ope
Hello Raphaël, or anyone else affected,
Accepted qemu into focal-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.19
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki
Uploaded to F-unapproved, waiting for the SRU team to accept 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/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
Status
** Changed in: qemu (Ubuntu Focal)
Status: Triaged => In Progress
** Changed in: qemu (Ubuntu Focal)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.la
SRU template updated, PPA rebuilt, Merge requests updated.
Also bundled another bug fix.
Waiting for MR review 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/1749393
Title:
sbrk() not working
Hi,
sorry this has fallen through the cracks, but bug 1928075 made me re-discover
it and it is time finally to complete that.
** Tags added: server-next
** Description changed:
[Impact]
- * The current space reserved can be too small and we can end up
-with no space at all for BRK. It
Yeah Sebastian, a new ticket (with a reference to this bug as being
similar) would be preferred.
** Changed in: qemu (Ubuntu)
Assignee: Christian Ehrhardt (paelzer) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEM
I'm running qemu-arm version 4.2.1 (Debian 1:4.2-3ubuntu6.17) on Ubuntu
20.04.03, but I seem to still be affected by this (or something very
much like it). In my case it is armhf exim4 crashing while creating a
chroot on an amd64 host. The final command run from deeply within
exim4's postinst is:
Thank you for fixing the problem.
I confirmed that https://bugs.launchpad.net/bugs/1924231 is fixed with
https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4535/+packages.
Thank you.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
For Focal:
- SRU Template added to the bug
- MP:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/401771
- PPA:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4535/+packages
(still building)
I'd ask anyone affected by this on Focal to give it a try on the PP
** Description changed:
+ [Impact]
+
+ * The current space reserved can be too small and we can end up
+with no space at all for BRK. It can happen to any case, but is
+much more likely with the now common PIE binaries.
+
+ * Backport the upstream fix which reserves a bit more space wh
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/401771
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under q
There's a request for a backport of this fix to be made to Ubuntu 20.04
in duplicate bug 1924231, so I'm adding a task for that.
** Also affects: qemu (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu Focal)
Status: New => Confirmed
** Changed in: qemu
This bug was fixed in the package qemu - 1:5.0-5ubuntu3
---
qemu (1:5.0-5ubuntu3) groovy; urgency=medium
* d/p/ubuntu/lp-1887763-*: fix TCG sizing that OOMed many small CI
environments (LP: #1887763)
* Pick further changes for groovy from debian/master since 5.0-5
- ati-vg
** Changed in: qemu (Ubuntu)
Assignee: Richard Henderson (rth) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user
Will be merged in 20.10 with qemu >=5.0 where this came upstream.
** Tags added: qemu-20.10
** Changed in: qemu (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
Status
Fixed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6fd5944980f4
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk()
Another proposed patch:
https://patchew.org/QEMU/20200117230245.5040-1-richard.hender...@linaro.org/
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Richard Henderson (rth)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
qemu patch proposed at http://lists.nongnu.org/archive/html/qemu-
devel/2018-03/msg04700.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (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/1749393
Title:
sbrk
Could we over-allocate the data segment by
QEMU_DATA_SIZE/getrlimit(RLIMIT_DATA)/128 MB depending on what's set -
similar to how the stack size is managed?
My current workaround for aarch64 on x86-64 is to mmap a dynamic main
executable in some far-away part of the address space but I'm not sure
h
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
rese
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary
** Tags added: arm linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
Status in QEMU:
New
Bug description:
This appears to be a problem in all PIE-compiled executables that use
sbrk in qemu-user due to the way that position-independent code gets
mmapped into adjacent ranges meaning there is no room for expansion.
I've hacked my version of QEMU to force the program binary to mmap in a
different range all
Affected by the same bug.
target architecture arm
host architecture amd64
bug message
bash: xmalloc: .././locale.c:: cannot allocate 2 bytes (0 bytes allocated)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
31 matches
Mail list logo
