X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=aH43HaqB1mIoOBL0
	P0pztyLGCtTYceAfsczmnasZXN9erSgxircFSR5R7iO0SvciybI5QR6C5hnixTXL
	SMWh7UkVnYbLye/Kr0exsFDdFF5d8qNrnyNlx29H73GX5/cuCO+GnbVRrtwJlmRr
	RgxdZDPX+oaiLEEAkjiTQF2nY6M=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=ohgenPy8o/ELFhIrBgiJqs
	jEGas=; b=jQXY/VcG+KY2zYXr5MGJvOk6qaprPkjkTTH3Q+MA8igYnc8UkdJtuE
	Xmx5rhRhLASxeQjzpXJp5/RGTdcwW1vfg5Qp7DJcnM9eKMA0lnJbyqzA8T+0uktw
	cMutpShUdAOn9US09+5TN0sikSqbsz+MeKrg1qfW5HHBsALybRQRM=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*M:cygwin, H*Ad:U*yselkowitz, Hx-languages-length:2082, H*f:sk:4311402
X-HELO:	mx1.redhat.com
Subject:	Re: [ANNOUNCEMENT] mesa 11.0.9-2
To:	cygwin AT cygwin DOT com
References:	<announce DOT 201602220900 DOT u1M90xBM023169 AT int-mx11 DOT intmail DOT prod DOT int DOT phx2 DOT redhat DOT com> <570D122B DOT 50307 AT gmail DOT com> <570DAFFA DOT 7020700 AT cygwin DOT com> <b8ee7d32-504d-27d8-51ab-547ea7a51968 AT dronecode DOT org DOT uk> <4311402a-fb7d-c68a-9cb3-954161a37e58 AT dronecode DOT org DOT uk>
From:	Yaakov Selkowitz <yselkowitz AT cygwin DOT com>
Message-ID:	<dc6a9435-58ca-36fd-8fa6-4f9da0b49b81@cygwin.com>
Date:	Mon, 6 Jun 2016 02:24:58 -0500
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version:	1.0
In-Reply-To:	<4311402a-fb7d-c68a-9cb3-954161a37e58@dronecode.org.uk>
X-IsSubscribed:	yes

On 2016-06-03 12:56, Jon Turney wrote:
> 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...

FWIW, I tried rebuilding with llvm 3.8.0.  32-bit doesn't crash anymore, 
and glxgears says its running, but only the background shows.

-- 
Yaakov

--
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

- Raw text -