From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO07R-0008H4-7j for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:13:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO07N-0001kI-SM for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:13:17 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:59584 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO07N-0001jH-J4 for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:13:13 -0400 Message-ID: <5788B737.6030100@kamp.de> Date: Fri, 15 Jul 2016 12:13:11 +0200 From: Peter Lieven MIME-Version: 1.0 References: <57888385.1080403@suse.com> <57889319.3030609@kamp.de> <5788A308.5010909@suse.com> <5788B5CC.8050305@kamp.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Regression with commit 095497ffc66b7f031 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Juergen Gross , xen-devel , "qemu-devel@nongnu.org" Cc: Gerd Hoffmann 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