Closed Bug 868787 Opened 12 years ago Closed 9 years ago

Crash with Mesa LLVMpipe and WebGL

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(5 files)

Attached file Create a WebGL context (deleted) —
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*))()) ]
Attached file stack (gdb) (deleted) —
Crash Signature: [@ @0x0 | mozilla::gl::GLLibraryLoader::LookupSymbol(PRLibrary*, char const*, void (*(*)(char const*))()) ]
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.
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.
(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?).
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).
Attached file about:support for an empty profile (deleted) —
(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.
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?
(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).
(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 ;-)
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.

Attachment

General

Creator:
Created:
Updated:
Size: