From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO33m-0008FN-58 for qemu-devel@nongnu.org; Fri, 15 Jul 2016 09:21:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO33h-0007ur-2f for qemu-devel@nongnu.org; Fri, 15 Jul 2016 09:21:41 -0400 Received: from mx2.suse.de ([195.135.220.15]:38247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO33g-0007ue-RF for qemu-devel@nongnu.org; Fri, 15 Jul 2016 09:21:36 -0400 References: <57888385.1080403@suse.com> <57889319.3030609@kamp.de> <5788A308.5010909@suse.com> <1468577568.22036.8.camel@redhat.com> <5788BDBE.8010500@suse.com> From: Juergen Gross Message-ID: <5788E35F.6030901@suse.com> Date: Fri, 15 Jul 2016 15:21:35 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] Regression with commit 095497ffc66b7f031 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Gerd Hoffmann Cc: xen-devel , Peter Lieven , "qemu-devel@nongnu.org" 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