qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Regression with commit 095497ffc66b7f031


From: Peter Lieven
Subject: Re: [Qemu-devel] Regression with commit 095497ffc66b7f031
Date: Fri, 15 Jul 2016 12:13:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Am 15.07.2016 um 12:12 schrieb Paolo Bonzini:
>
> On 15/07/2016 12:07, Peter Lieven wrote:
>> Am 15.07.2016 um 12:02 schrieb Paolo Bonzini:
>>> On 15/07/2016 10:47, Juergen Gross wrote:
>>>> Nothing scaring and no real difference between working and not working
>>>> variant.
>>>>
>>>> Meanwhile I've been digging a little bit deeper and found the reason:
>>>> libxenstore is setting up a reader thread which is waiting for the
>>>> watch to fire. With above commit the stack size of that thread (16kB)
>>>> is too small. Setting it to 32kB made qemu work again.
>>> This makes very little sense (not your fault)...  The commit doesn't
>>> change stack usage at all, TLS should not be on the stack.
>> But we still allocate the VncPalette for every thread, right? Even
>> if it has nothing todo with VNC.
> Yes, I'm just trying to understand the root cause.  Which is that glibc
> actually does carve out TLS space from the requested stack size.  That
> means that a program that has a lot of TLS variables, or has big TLS
> variables, will fail in weird ways.
>
> So that's two reasons why your patch is okay. :)

Okay, then I will wait for the analysis and then resubmit that Patch
with a different commit message.

Peter




reply via email to

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