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

configure tries to check how printf behaves when it runs out of memory. I've attached a cut-down version of the code that reproduces the hang in qemu-arm-static, but works on real hardware. It uses a SIGSEGV handler, which is probably relevant.

I've tested with qemu-arm-static 1.4.0-2013.02+git63+20130225+79aa792-0linaro1 and 1.4.0+dfsg-1expubuntu4.

Anyway even if you disable this check you will find another unsupported syscall bug... :(

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 doesn't work on QEMU because we just pass the rlimit syscall through to the host, and end up limiting not just the guest program but also QEMU itself. QEMU doesn't expect its own allocations to fail and typically dies in confusing ways as a result. (Sometimes we do check allocations and call abort(), which then under linux-user doesn't work properly because we treat the resulting signal as if it were caused by the guest and not by QEMU's own code; IIRC we end up hanging in that situation.) In this particular instance we segfault in tb_alloc_page() because it doesn't check that page_find_alloc() didn't return NULL.

[Confirmed by running qemu-arm under gdb.]

Fixing this would require us to implement the address space rlimits entirely in QEMU by keeping track of how much memory we've handed the guest so we can fail mmap() etc. That is probably relatively speaking fairly tractable, though it's not a five minute job.

Unsupported syscall bugs are usually easy fixes, incidentally (though occasionally they are nasty); also often QEMU will warn but things will continue OK because the guest libc/userspace supports fallback code for when a native kernel hasn't yet implemented the new syscall.

I'm referring to bug 1042388, I din't know about the fallback on this, but I have to say it doesn't work since apt exits and fails when encounters this call, maybe the fallback has some problems?

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.

This will come in when implemented upstream.

It's been a while since the last change to this ticket ... Has this ever been implemented?

This bug is still valid, yes.

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/95