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

[Juergen Gross <jgross@xxxxxxxx>]

On 15/07/16 14:42, Paolo Bonzini wrote:
> 
> 
> On 15/07/2016 12:41, Juergen Gross wrote:
>> 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() )? 
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01643.html has a patch
> that _removes_ code to do this from the golang runtime.  The comments
> there say that only with glibc before version 2.16 the static TLS size
> is taken out of the stack size...
> 
> What version of glibc are you using?

2.19. But according to:

https://sourceware.org/bugzilla/show_bug.cgi?id=11787

the issue is still present today.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel