From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10085 invoked by alias); 3 Jun 2016 17:56:31 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 10067 invoked by uid 89); 3 Jun 2016 17:56:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=todays, vmware, today's, VMware X-HELO: out2-smtp.messagingengine.com Received: from out2-smtp.messagingengine.com (HELO out2-smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 03 Jun 2016 17:56:15 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0ABD321CAC for ; Fri, 3 Jun 2016 13:56:13 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 03 Jun 2016 13:56:13 -0400 Received: from [192.168.1.102] (host86-141-128-254.range86-141.btcentralplus.com [86.141.128.254]) by mail.messagingengine.com (Postfix) with ESMTPA id AD080F29EE for ; Fri, 3 Jun 2016 13:56:12 -0400 (EDT) Subject: Re: [ANNOUNCEMENT] mesa 11.0.9-2 To: cygwin@cygwin.com References: <570D122B.50307@gmail.com> <570DAFFA.7020700@cygwin.com> From: Jon Turney Message-ID: <4311402a-fb7d-c68a-9cb3-954161a37e58@dronecode.org.uk> Date: Fri, 03 Jun 2016 17:56:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00043.txt.bz2 On 31/05/2016 18:03, Jon Turney wrote: > On 13/04/2016 03:33, Yaakov Selkowitz wrote: >> On 2016-04-12 10:20, Marco Atzeri wrote: >>> $ cd /usr/lib/mesa-demos >>> $ ./quad-clip.exe >>> GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits) >>> GL_VERSION = 3.0 Mesa 11.0.9 >>> GL_VENDOR = VMware, Inc. >>> Segmentation fault (core dumped) >> >> I can reproduce this on 32-bit but not 64-bit, and the same happens with >> 11.1.2. It may be an issue with LLVM 3.7 (11.0.9-1 was built with 3.5) >> but without a useful backtrace it will be hard to pin down. > > gdb can successfully backtrace this, with today's cygwin snapshot. > > Both examples of the crash provided by Marco show very similar symptoms. > > Unfortunately, the backtrace stops at llvm_pipeline_generic() calling > into some JIT-ed code. The faulting is at an insertps instruction with > what looks like a bogus absolute address. > > So I guess this some is an llvm issue, possibly with some address > computation which doesn't give the right result on 32 bit? > >> # gdb ./quad-clip >> [...] >> (gdb) r >> [...] >> Program received signal SIGSEGV, Segmentation fault. >> 0x7fdf00c1 in ?? () [...] >> /usr/src/debug/mesa-demos-8.3.0-1/src/trivial/quad-clip.c:137 >> (gdb) disassemble 0x7fdf00b1,0x7fdf00d2 >> Dump of assembler code from 0x7fdf00b1 to 0x7fdf00d2: >> 0x7fdf00b1: insertps $0x10,0x4(%eax,%edi,1),%xmm0 >> 0x7fdf00b9: insertps $0x20,0x8(%eax,%edi,1),%xmm0 >> => 0x7fdf00c1: insertps $0x30,0xfffeff34,%xmm0 >> 0x7fdf00cb: mov (%esi),%eax >> 0x7fdf00cd: mul %ecx After staring this a bit more, I see that this is the offset to the data to load, apparently being used as an absolute address This seems to be the case with other addresses in the JIT-ed code, so perhaps there is some problem preventing relocations being applied... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple