This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] mesa 11.0.9-2
- From: Yaakov Selkowitz <yselkowitz at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 6 Jun 2016 02:24:58 -0500
- Subject: Re: [ANNOUNCEMENT] mesa 11.0.9-2
- Authentication-results: sourceware.org; auth=none
- 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>
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
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
Program received signal SIGSEGV, Segmentation fault.
0x7fdf00c1 in ?? ()
(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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple