Closed
Bug 868787
Opened 12 years ago
Closed 9 years ago
Crash with Mesa LLVMpipe and WebGL
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(5 files)
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*))()) ]
Reporter | ||
Comment 1•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Crash Signature: [@ @0x0 | mozilla::gl::GLLibraryLoader::LookupSymbol(PRLibrary*, char const*, void (*(*)(char const*))()) ]
Comment 2•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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).
Reporter | ||
Comment 6•12 years ago
|
||
Reporter | ||
Comment 7•12 years ago
|
||
Reporter | ||
Comment 8•12 years ago
|
||
(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.
Reporter | ||
Comment 9•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
(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 ;-)
Updated•9 years ago
|
Crash Signature: [@ @0x0 | mozilla::gl::GLLibraryLoader::LookupSymbol(PRLibrary*, char const*, void (*(*)(char const*))()) ] → [@ @0x0 | mozilla::gl::GLLibraryLoader::LookupSymbol(PRLibrary*, char const*, void (*(*)(char const*))()) ]
[@ @0x0 | mozilla::gl::GLLibraryLoader::LookupSymbol ]
Mass resolving WFM: signature(s) hasn't(/haven't) reported in past 28 days.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•