[Mesa-dev] FPE Invalid Operation

[Ilia Mirkin]

On Mon, Sep 5, 2016 at 2:32 PM, Bram Stolk <b.stolk at gmail.com> wrote:
>
>>If you're able to, make a local build, adding -O0 to cflags, and don't
>>strip the debug info. That should show you exactly where the issue
>>lies.
>
> I built mesa 12.0.2 using:
> ~/src/mesa-12.0.2$ CFLAGS=-O0 ./configure --prefix=$HOME --disable-dri3
>
> If I LD_PRELOAD the resulting libGL.so then the crash goes away and I see
> correctly reported:
> GL_VERSION  3.3 (Core Profile) Mesa 12.0.2
>
> So maybe it is an old bug, making 11.2.0 affected, but not 12.0.2?
> So then I proceeded to build the same version that comes with Ubuntu.
>
> When LD_PRELOAD-ing that libary, I get:
>
> Thread 1 "game" received signal SIGFPE, Arithmetic exception.
> 0x00007fffeecb48e4 in gen7_upload_urb (brw=0x27419b8) at gen7_urb.c:301
> 301             round(hs_wants * (((double) remaining_space) /
> total_wants));

Ah yes. That was a known bug for gen7+ (IvyBridge+), which was fixed
some time back.

commit 01c89ccc5d1529aa1efbae80c8ef641a59abbd93
Author: Ardinartsev Nikita <ardinar23 at gmail.com>
Date:   Wed Jun 22 18:28:11 2016 -0700

    i965: Avoid division by zero.

    Fixes regression introduced by af5ca43f2676bff7499f93277f908b681cb821d0

    Cc: "12.0 11.2" <mesa-stable at lists.freedesktop.org>
    Reviewed-by: Matt Turner <mattst88 at gmail.com>
    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95419

(And there even was an earlier attempt with 2a8aa1e3deb99 but it got
reverted due to reasons unspecified in the commit log.)

> Even though 12.0.2 seems unaffected:
> Ubuntu is using 11.2.0, maybe fixing the v11 tree still makes sense?

While it was tagged for 11.2.x, I'm not sure that there will be
another 11.2.x release. The 12.0 release has already been out for 2
months, and in general, we only support 1 stable release branch at a
time. (Except right around release time.)

We can't control what distros carry, but if they want to use
out-of-support releases, they're on their own to pick up fixes.

> I'm also puzzled that this division by zero depends on the values I pass to
> glClearColor before the glClear command, though.

Some colors can be fast-cleared while others can't. 0,0,0,1 can be,
while I think 0.5,anything can't. This in turn causes a full draw to
happen, which hits different code paths.

>
> Bram
>
> PS: Just a side-note: when I tried re-configuring (after building) my 11.2.0
> tree, it choked on pyton mako. I had to delete the entire source tree, and
> unpack again before I could re-configure.

The required mako version was recently increased. However it's odd
that running configure would "choke" like that. Sometimes doing a
configure isn't enough to get everything properly rebuilt and you have
to do a "make clean" first.

  -ilia