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: Juergen Gross
Subject: Re: [Qemu-devel] Regression with commit 095497ffc66b7f031
Date: Fri, 15 Jul 2016 12:41:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0

On 15/07/16 12:35, Paolo Bonzini wrote:
> 
> 
> On 15/07/2016 12:12, Gerd Hoffmann wrote:
>> On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote:
>>>
>>> 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.
>>>
>>> Can you capture a backtrace where the 16K stack is exceeded?  Perhaps
>>> it's only due to inlining decision on the compiler, in which case
>>> Peter's patch from today is only a bandaid.
>>
>> Hmm, I guess I hold off the vnc pull request for now ...
> 
> Go ahead.  I looked at glibc source code and the patch is okay.

Paolo, do you know of any interface to obtain the size of the TLS area
taken from the stack (before calling pthread_create() )? This would
enable me to modify libxenstore to set the stack size to a sensible
value without having to choose a magic number which might fit for qemu,
but not for other users of libxenstore in the future.


Juergen



reply via email to

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