Visiting a site makes FF crash with Intel GPUs (after Mesa/GL error messages)

RESOLVED FIXED in Firefox 12

Status

()

defect
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: t01dev, Assigned: bjacob)

Tracking

(Blocks 1 bug, {crash})

7 Branch
mozilla13
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox10 affected, firefox11 affected, firefox12 fixed, firefox13 fixed, firefox-esr10- affected)

Details

(Whiteboard: [qa-], crash signature)

Attachments

(3 attachments)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110930100559

Steps to reproduce:

Using Firefox 7.0.1, startpage is https://www.ixquick.com/eng/ entering
"delayed cron" in the search, in the list, there is a link to
devcenter.heraku.com/cron - clicking on it makes Firefox crash


Actual results:

Firefox crashed, with this as message in the console:

Can't find symbol 'glXBindTexImageEXT'
Can't find symbol 'glXReleaseTexImageEXT'
Mesa 7.11 implementation error: unexpected format in _mesa_choose_tex_format()
Please report at bugs.freedesktop.org
Mesa 7.11 implementation error: unexpected MESA_FORMAT for renderbuffer
Please report at bugs.freedesktop.org
###!!! ABORT: Divide by zero: file
/build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
###!!! ABORT: Divide by zero: file
/build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
Aborted




Expected results:

...I should have seen the page...

Freedesktop had the same bug reported...

Thanks for the effort!
Is there a crash in about:crashes?  If so, could you past the link to it into the bug?
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Summary: Visiting a site makes FF crash → Visiting a site makes FF crash (after Mesa/GL error messages)
(In reply to David Baron [:dbaron] from comment #1)
> Is there a crash in about:crashes?  If so, could you past the link to it
> into the bug?

Hi, Tried to enter the address, Firefox does'nt like it...
Any clues to the logs Firefox makes and the location of the (main) config file(s)?
Severity: normal → critical
Keywords: crash
WFM on the latest Beta and on the latest Nightly (OS - Ubuntu 11.10):
Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20100101 Firefox/9.0 (beta 3)
Mozilla/5.0 (X11; Linux i686; rv:11.0a1) Gecko/20111129 Firefox/11.0a1

I used the steps from the bug description but devcenter.heroku.com/articles/cron was found instead of devcenter.heraku.com/cron (not existent). The link was opened without any issues.

Thor, can you please try to reproduce this issue with a clean profile or in safe mode?
Hi,

Visited the link on a Xubuntu (XFCE, the same as I use) and did get to the devcenter page, on Arch (curent system) this is stil what I get:

Mesa 7.11.1 implementation error: unexpected format in _mesa_choose_tex_format()
Please report at bugs.freedesktop.org
Mesa 7.11.1 implementation error: unexpected MESA_FORMAT for renderbuffer
Please report at bugs.freedesktop.org
###!!! ABORT: Divide by zero: file /build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
###!!! ABORT: Divide by zero: file /build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
Segmentation fault

by te way, the page can be seen/visited on Epiphany.

The Xubuntu box visits the site error free. I can (if need be) test on a Debian and a MacPup as well...
> Using Firefox 7.0.1, startpage is https://www.ixquick.com/eng/ entering
> "delayed cron" in the search, in the list, there is a link to
> devcenter.heraku.com/cron - clicking on it makes Firefox crash

I experience the same problem but with another site, and searching for similar bug inside bugzilla, seems that bug affects Linux users with gen2 Intel graphic card.
I have an i855 and here is the bug i've opened to Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652941

Here there are other Firefox related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=703048
https://bugzilla.mozilla.org/show_bug.cgi?id=699181

And here is the bug opened on Mesa bugzilla by the reporter of #699181:
https://bugs.freedesktop.org/show_bug.cgi?id=42611

Cesare.
Blocks: 605779
I kindly ask to the bug submitter and to the other affected by this bug to post here details about your graphic card, kernel version, X.org driver type and version and Mesa version, as suggested by a Mozilla developer. For those who can he also suggest, in addition to crash backtrace: "even better crash id from the upstream crash reporter (try reproducing the bug with an upstream tarball and try to make it send crash info, then go in about:crashes to
have a link to your crashes)".

As i said before and as proved by bugs i've found on other programs, seems to be a bug related to gen2 Intel graphic card (i845, i830, i855, i865) and a combination of kernel/x-driver/mesa. Your detail can help to prove o deny that.

My system:
Graphic card: Intel 855
Distribution: Debian (Sid)
Browser: Iceweasel 9.0.1
Flash plug-in: 11.1.102.55
Kernel: Linux 3.2.1
X.org driver: Intel 2.17.0
Mesa: 7.11.2

As others have already posted, this is what i obtain trying to opening about:support:
-----------------
$ Mesa 7.11.2 implementation error: unexpected format in _mesa_choose_tex_format()
Please report at bugs.freedesktop.org
Mesa 7.11.2 implementation error: unexpected MESA_FORMAT for renderbuffer
Please report at bugs.freedesktop.org
###!!! ABORT: Divide by zero: file /build/buildd-iceweasel_9.0.1-1-i386-DsqgnV/iceweasel-9.0.1/toolkit/xre/nsSigHandlers.cpp, line 174
###!!! ABORT: Divide by zero: file /build/buildd-iceweasel_9.0.1-1-i386-DsqgnV/iceweasel-9.0.1/toolkit/xre/nsSigHandlers.cpp, line 174

[1]+  Segmentation fault      firefox
$
-----------------

The same happen visiting this online italian radio, highly flash based (always reproducible):
http://www.m2o.it

Cesare.
For cesare,

Thanks for your attention in this.
I started FireFox in the console:
Mesa 7.11.2 implementation error: unexpected format in _mesa_choose_tex_format()
Please report at bugs.freedesktop.org
Mesa 7.11.2 implementation error: unexpected MESA_FORMAT for renderbuffer
Please report at bugs.freedesktop.org
###!!! ABORT: Divide by zero: file /build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
###!!! ABORT: Divide by zero: file /build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
Segmentation fault

My card (output from lshw)
             description: VGA compatible controller
             product: 82865G Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: vga_controller bus_master cap_list rom
             configuration: driver=i915 latency=0
             resources: irq:16 memory:f0000000-f7ffffff memory:f8400000-f847ffff ioport:14e0(size=8)

Using Firefox 9.0.1, XFCE 4.8

CPU
     *-cpu
          product: Intel(R) Pentium(R) 4 CPU 2.66GHz
          vendor: Intel Corp.
          physical id: 1
          bus info: cpu@0
          version: 15.2.7
          size: 2650MHz
          width: 32 bits
          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid xtpr

Hope this helps...

The crashes happen on certain sites (the radio for instance) - but none of them are lifelines (yet) :) so, take your time here...

If it could help at all, this config does nog support Blender either, that one dies on a segfault as well...
Firefox 10 have the same problem, I have two computers and they are both equipped with
graphic chip  82865G

My third computer have a diferent intel chip, firefox does not crash there
Can you provide a stack (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Visiting a site makes FF crash (after Mesa/GL error messages) → Visiting a site makes FF crash with Intel GPUs (after Mesa/GL error messages)
(In reply to Scoobidiver from comment #9)
> Can you provide a stack (see
> https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report)?

From this link i've choosed the alternative way from the Ubuntu (since i use Debian):
https://wiki.ubuntu.com/MozillaTeam/Bugs#Obtain%20a%20backtrace%20from%20an%20apport%20crash%20report%20(using%20gdb)
And here the "Run Firefox in a Debugger" method.

First of all i've cleaned Firefox session by closing all tabs.
Then, even if not requested by the guide, i've installed libgl1-mesa-dri-dbg.
Then i've followed the Ubuntu steps:
1) install firefox-dbg
2) install libgtk2.0-0-dbg libglib2.0-0-dbg  libx11-6-dbg libpango1.0-0-dbg libc6-dbg
3) iceweasel -g 2>&1 | tee Desktop/firefox-gdb.txt
4) (gdb) run
5) (gdb) bt full
6) (gdb) thread apply all backtrace full
7) (gdb) (gdb) quit

Attached the output produced by gdb.

Cesare.
Posted file gdb stacktrace
Thanks for the great stack trace going all the way down to the Intel driver!

First of all, this is NOT a security bug. SIGFPE means very probably a integer division by zero. So we don't need to consider blacklisting this driver.

This is clearly a bug in the Intel driver for Mesa. It should be reported to Mesa developers here, choosing a component that relates to the Intel driver.

https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa

Are you going to file that bug?
Crash Signature: [@ intel_region_alloc]
Please see this Mesa bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=42128

Suggestion is to run glxinfo and check driver capability.
Attachment #599847 - Flags: review?(matt.woodrow)
Attachment #599847 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/512df80d7ca4
Assignee: nobody → bjacob
Target Milestone: --- → mozilla13
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Comment on attachment 599847 [details] [diff] [review]
Block OpenGL 1 drivers

[Approval Request Comment]
Regression caused by (bug #): not a regression. We just realized now that some OpenGL 1 drivers are not gracefully failing, and are crashing instead, when we try to do OpenGL 2 work on them.
User impact if declined: WebGL crashy on old machines on Linux
Testing completed (on m-c, etc.): just landed on m-i
Risk to taking this patch (and alternatives if risky): very low risk
String changes made by this patch: none
Attachment #599847 - Flags: approval-mozilla-aurora?
Push backed out for xpcshell failures:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=b638c0deeafa

https://hg.mozilla.org/integration/mozilla-inbound/rev/44de0ed9fa1d
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla13 → ---
My best guess is that's because the xpcshell test doesn't define GL strings at all, so GL version == 0 --> blacklisted
https://hg.mozilla.org/mozilla-central/rev/b15858a5d485
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Attachment #599847 - Flags: approval-mozilla-beta?
(In reply to Benoit Jacob [:bjacob] from comment #16)
> Risk to taking this patch (and alternatives if risky): very low risk

We're likely to approve this to land tomorrow (2/28) for our fifth beta.

A couple of quick questions though - what's the worst case scenario? I'm not clear on the user experience for a user when blacklisted. Could we accidentally take things from being crashy to completely unusable?
The worst-case scenario is that we would accidentally blacklist WebGL. Indeed, on X11, WebGL is the only feature that depends on OpenGL driver blacklists.

No WebGL is something that a majority of users wouldn't even notice at this point, since most websites still don't use WebGL (and over 50% of users still don't get WebGL, precisely due to blacklists).

More generally, no gfx feature blacklisting would render the browser unusable.

But, power users would notice and would be disappointed.
Whiteboard: [qa+]
Comment on attachment 599847 [details] [diff] [review]
Block OpenGL 1 drivers

[Triage Comment]
Although this is low risk, we're only approving for Aurora 12 based upon the low user benefit.
Attachment #599847 - Flags: approval-mozilla-beta?
Attachment #599847 - Flags: approval-mozilla-beta-
Attachment #599847 - Flags: approval-mozilla-aurora?
Attachment #599847 - Flags: approval-mozilla-aurora+
[Triage Comment]
Not a regression in Firefox 10, and hasn't been called out as a pain point in enterprise users, also not a topcrash so taking tracking off for esr10.
Fx 13 is the trunk build where the patch landed first.
Target Milestone: mozilla12 → mozilla13
The patch is now on Aurora. Am I misunderstanding Target Milestone?
Without that, we're doing the OpenGL 1 check before we're retrieving the data from the glxtest process, which means that the OpenGL 1 check isn't effective during the first GetFeatureStatus call.
Attachment #603586 - Flags: review?(matt.woodrow)
Attachment #603586 - Flags: review?(matt.woodrow) → review+
Duplicate of this bug: 731296
I wonder if we were creating a shader of type GL_FRAGMENT_SHADER without checking for the ARB_fragment_shader extension.
You could say that, but the problem is more general: we were trying to use OpenGL 2.1 without checking that that was supported, and these crashes occur when only OpenGL 1 is supported. So the problem was more general than just shaders.
I've just upgraded Firefox (Iceweasel) on my Debian to version 10.0.3esr-1 and for me the problem looks resolved (indeed after restoring webgl.disabled=default).

Looking in the changelog from Mike Hommey i guess that the fix was brougth by this:
- Avoid crashing when there are no GL extensions reported by the GL implementation. bz#728656. Closes: #656611.
Hi,

Reproducing the original steps still makes the thing crash:

Mesa 8.0.1 implementation error: unexpected format GL_DEPTH_COMPONENT24 in _mesa_choose_tex_format()
Please report at bugs.freedesktop.org
###!!! ABORT: Divide by zero: file /build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
###!!! ABORT: Divide by zero: file /build/src/mozilla-release/toolkit/xre/nsSigHandlers.cpp, line 174
Segmentation fault

...of course, this is not at all life threatening for me, just thought you'd like to know...

Thanks

THor
I have upgraded firefox from 10.0.2 to 11 but it continues to crash unless I add
webgl.disabled=default
This bug is not fixed in Fx 10 and Fx 11 (see the tracking flags).
To comment #36 and #37.
From the past messages, i got that the fixes are targeted for FF13, IIUC.

But Mike Hommey, Mozilla developer and mantainer of the Firefox Debian package, has released a *Debian* Firefox (Iceweasel) package that fixes the problem for me. I think it contain a patch that is not upstream yet, and i wanted to make them that it seems to fix this problem.
I noticed that the package name contains the "esr" string (Extended Support Release).
The bug seems to be fixed in nightly (Version 13), it does not crash at sites 
where Firefox 11 crash.
The fix is in Firefox >= 12, see the tracking flags.
I have tried to verify this fix on Firefox 12.0 beta 3 but:
http://devcenter.heraku.com/cron shows "Server not found",
I suppose the right page is http://devcenter.heroku.com/cron, am I right?

The issue doesn't reproduce for me on older Fx versions, is there a certain environment I should try to reproduce it on?

I am currently using Ubuntu 11.10 x86 and an Intel(R) G41 GPU.
Whiteboard: [qa+] → [qa?]
Whiteboard: [qa?] → [qa+]
Thor, or anyone else that has the hardware to reproduce this bug, can you please help QA in verifying it is fixed? We need someone to check if this bug still reproduces in Firefox 12.0 and Firefox 13.0b6.

Thank you
QA has so far been unable to reproduce this bug, and therefore are incapable of verifying the fix. Please mark this bug [qa+] if a reproducible case can be provided. Alternative, if you can reproduce it, please verify this is fixed in Firefox 12 and 13.

Thank you
Whiteboard: [qa+] → [qa-]
You need to log in before you can comment on or make changes to this bug.