868787 - Crash with Mesa LLVMpipe and WebGL

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: Create a WebGL context

1. Create a profile with following prefs:
     user_pref("gfx.prefer-mesa-llvmpipe", true);
     user_pref("layers.acceleration.force-enabled", true);
2. Load the testcase (it just creates a WebGL context)
3. Open a new browser window (Ctrl+N)

Nightly: bp-1fac5cc7-78a9-473b-ba9b-cb84c2130504
> [@ @0x0 | mozilla::gl::GLLibraryLoader::LookupSymbol(PRLibrary*, char const*, void (*(*)(char const*))()) ]

Comment 1

[Jesse Ruderman]

Attachment: stack (gdb)

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

You must also be force-enabling WebGL, as llvmpipe is specifically blacklisted for WebGL at the moment. Correct? Assuming yes: I don't see us spending a lot of effort on bugs in a driver that we already blacklist.

I'd be interested in knowing what Mesa version you're using too (in about:support -> Graphics) so we get another clue about that Mesa versions have a llvmpipe that we shouldn't un-blacklist.

What would be the most helpful to do about a llvmpipe bug is to file it against Mesa at bugs.freedesktop.org.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Oh hey, that crash stack is really crazy: it's crashing in glxGetProcAddress, which is a dlsym-like function; I've never seen this crashing before on any driver. Really interested in your about:support.

Comment 4

[Christian Holler (:decoder)]

(In reply to Benoit Jacob [:bjacob] from comment #2)
> You must also be force-enabling WebGL, as llvmpipe is specifically
> blacklisted for WebGL at the moment. Correct? Assuming yes: I don't see us
> spending a lot of effort on bugs in a driver that we already blacklist.

The bug doesn't need to be in the driver, we're also trying to find bugs in the intermediate layers and llvmpipe can be helpful there, esp. for testing environments. Furthermore, it would be desirable to get rid of the broken software rendering drivers on TBPL and use llvmpipe instead (as we discussed via mail, right?).

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Hm, right, now I remember that the b2g-emulator test slaves are (or at least, were at some point) Ubuntu machines using the llvmpipe driver, so that fixes in llvmpipe would benefit us at least in this way. Beyond that, we are certainly interested in llvmpipe getting better, if only as it is the most advanced open source software OpenGL implementation around and so would be our best option if we decided to ship a software fallback for WebGL (as Chrome has been doing using a proprietary software OpenGL renderer).

Comment 6

[Jesse Ruderman]

Attachment: about:support for an empty profile

Comment 7

[Jesse Ruderman]

Attachment: about:support with the prefs in comment 0

Comment 8

[Jesse Ruderman]

(In reply to Benoit Jacob [:bjacob] from comment #2)
> You must also be force-enabling WebGL, as llvmpipe is specifically
> blacklisted for WebGL at the moment. Correct? Assuming yes: I don't see us
> spending a lot of effort on bugs in a driver that we already blacklist.

I'm only setting the two prefs mentioned in comment 0.  Does one of them force-enable WebGL?

> I'd be interested in knowing what Mesa version you're using too (in
> about:support -> Graphics) so we get another clue about that Mesa versions
> have a llvmpipe that we shouldn't un-blacklist.

I don't see a Mesa version?

> What would be the most helpful to do about a llvmpipe bug is to file it
> against Mesa at bugs.freedesktop.org.

You might be able to give them a more reduced bug report.

Comment 9

[Jesse Ruderman]

Attachment: screenshot of ubuntu settings for nvidia driver

I'm using Ubuntu 13.04.  I installed Ubuntu a few versions ago and have been updating Ubuntu, but maybe that doesn't update the closed-source NVIDIA driver?

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Jesse Ruderman from comment #8)
> (In reply to Benoit Jacob [:bjacob] from comment #2)
> > You must also be force-enabling WebGL, as llvmpipe is specifically
> > blacklisted for WebGL at the moment. Correct? Assuming yes: I don't see us
> > spending a lot of effort on bugs in a driver that we already blacklist.
> 
> I'm only setting the two prefs mentioned in comment 0.  Does one of them
> force-enable WebGL?

Hah, I see now --- the prefer-mesa-llvmpipe bypasses the blacklisting of llvmpipe.

What happened is at some point we worked towards making llvmpipe our WebGL software rendering fallback. That preference was a step towards that. Then we found that we had to blacklist llvmpipe for security issues, so that effort stalled.

Anyway, at this point it's a non-default preference that's only exposed in about:config. Not a fully supported path.

> 
> > I'd be interested in knowing what Mesa version you're using too (in
> > about:support -> Graphics) so we get another clue about that Mesa versions
> > have a llvmpipe that we shouldn't un-blacklist.
> 
> I don't see a Mesa version?

Indeed, the system OpenGL implementation on your machine is not Mesa, it's NVIDIA.

Please run:

glxinfo | egrep renderer\|vendor\|version

(You may need to install mesa-utils).

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Benoit Jacob [:bjacob] from comment #10)
> Please run:
> 
> glxinfo | egrep renderer\|vendor\|version
> 
> (You may need to install mesa-utils).

Erm sorry, that is also going to give you the NVIDIA strings by default.

You'd have to LD_PRELOAD your llvmpipe library for that to give you Mesa strings.

Anyway --- I think I know what's happening :-)

That prefer-mesa-llvmpipe preference is very little tested. It assumes that you have a mesallvmpipe.so in your LD_LIBRARY_PATH. I suppose you haven't ;-)

Comment 12

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Mass resolving WFM: signature(s) hasn't(/haven't) reported in past 28 days.