qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] linux-user: trap internal SIGABRT's


From: Alex Bennée
Subject: Re: [RFC PATCH] linux-user: trap internal SIGABRT's
Date: Wed, 09 Feb 2022 13:12:38 +0000
User-agent: mu4e 1.7.7; emacs 28.0.91

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 9 Feb 2022 at 11:35, Alex Bennée <alex.bennee@linaro.org> wrote:
>> linux-user wants to trap all signals in case they are related to the
>> guest. This however results in less than helpful core dumps when the
>> error is internal to QEMU. We can detect when an assert failure is in
>> progress by examining __glib_assert_msg and fall through to
>> cpu_abort() which will pretty print something before restoring the
>> default SIGABRT behaviour and dumping core.
>
> There is definitely a problem here that it would be nice to
> fix, but __glib_assert_msg is as far as I can tell not a
> documented public-facing glib API,

Yeah it's in an odd position - it is explicitly exported but not
documented as an API but for use by crash tools:

  https://gitlab.gnome.org/GNOME/glib/-/issues/712

> and in any case it won't
> catch assertions via plain old assert() or abort() or for

libc does provide an a private __abort_msg but that is explicitly
private and I guess would break against a non-gnu libc (do we support
that?).

Explicit aborts() in linux-user code should probably be converted to
cpu_abort as it does the right thing. asserts() can be converted to
g_assert() given as glib is a absolute requirement for building.

> that matter SIGSEGVs and other kinds of crash in QEMU's own code.

There is some checking in the host_signal_handler that could be a bit
cleverer. We currently check for h2g_valid(host_addr) but we could
expand that to cover QEMU's own address space and behave appropriately.

>
> thanks
> -- PMM


-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]