On Thu, Dec 01, 2022 at 10:49:27 +, Alex Bennée wrote:
> Emilio Cota writes:
> > On Tue, Oct 04, 2022 at 13:00:47 +0100, Daniel P. Berrangé wrote:
> > (snip)
> >> Can't say I especially like this but I'm out of other ideas for how
> >> to guarantee a solution. Users can't set env vars prior
Emilio Cota writes:
> On Tue, Oct 04, 2022 at 13:00:47 +0100, Daniel P. Berrangé wrote:
> (snip)
>> Can't say I especially like this but I'm out of other ideas for how
>> to guarantee a solution. Users can't set env vars prior to launching
>> QEMU user emulators when using binfmt.
>
> An
On Tue, Oct 04, 2022 at 13:00:47 +0100, Daniel P. Berrangé wrote:
(snip)
> Can't say I especially like this but I'm out of other ideas for how
> to guarantee a solution. Users can't set env vars prior to launching
> QEMU user emulators when using binfmt.
An alternative is to not use GSlice
On Thu, Oct 6, 2022 at 11:29 AM Richard Henderson
wrote:
>
> On 10/6/22 11:12, Daniel P. Berrangé wrote:
> > The only possible silver linining is that in static linked builds,
> > it appears that a QEMU constructor with priority 101, will pre-empt
> > the constructor from any library. This is
On 10/6/22 11:12, Daniel P. Berrangé wrote:
On Tue, Oct 04, 2022 at 07:59:18AM -0700, Richard Henderson wrote:
On 10/4/22 05:00, Daniel P. Berrangé wrote:
g_slice uses a one-time initializer to check the G_SLICE env variable
making it hard for QEMU to set the env before any GLib API call has
On Tue, Oct 04, 2022 at 07:59:18AM -0700, Richard Henderson wrote:
> On 10/4/22 05:00, Daniel P. Berrangé wrote:
> > g_slice uses a one-time initializer to check the G_SLICE env variable
> > making it hard for QEMU to set the env before any GLib API call has
> > triggered the initializer. Even
On 10/4/22 05:00, Daniel P. Berrangé wrote:
g_slice uses a one-time initializer to check the G_SLICE env variable
making it hard for QEMU to set the env before any GLib API call has
triggered the initializer. Even attribute((constructor)) is not
sufficient as QEMU has many constructors and there
On Tue, 4 Oct 2022 at 13:00, Daniel P. Berrangé wrote:
>
> The g_slice custom allocator is not async signal safe with its
> mutexes. When a multithreaded program running in the qemu user
> emulator forks, it can end up deadlocking in the g_slice
> allocator
>
> Thread 1:
> #0 syscall () at
The g_slice custom allocator is not async signal safe with its
mutexes. When a multithreaded program running in the qemu user
emulator forks, it can end up deadlocking in the g_slice
allocator
Thread 1:
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x7f54e190c77c in
