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

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Thor]

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!

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is there a crash in about:crashes?  If so, could you past the link to it into the bug?

Comment 2

[Thor]

(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)?

Comment 3

[Ioana (away)]

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?

Comment 4

[Thor]

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...

Comment 5

[Cesare Leonardi]

> 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.

Comment 6

[Cesare Leonardi]

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.

Comment 7

[Thor]

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...

Comment 8

[trond]

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

Comment 9

[Scoobidiver (away)]

Can you provide a stack (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report)?

Comment 10

[Cesare Leonardi]

(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.

Comment 11

[Cesare Leonardi]

Attachment: gdb stacktrace

Comment 12

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

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?

Comment 13

[John AS]

Please see this Mesa bug report:

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

Suggestion is to run glxinfo and check driver capability.

Comment 14

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

Attachment: Block OpenGL 1 drivers

Comment 15

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/512df80d7ca4

Comment 16

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

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

Comment 17

[Ed Morley [:emorley]]

Push backed out for xpcshell failures:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=b638c0deeafa

https://hg.mozilla.org/integration/mozilla-inbound/rev/44de0ed9fa1d

Comment 18

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

My best guess is that's because the xpcshell test doesn't define GL strings at all, so GL version == 0 --> blacklisted

Comment 19

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

New try: https://tbpl.mozilla.org/?tree=Try&rev=ab11ce954d6c

Comment 20

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

http://hg.mozilla.org/integration/mozilla-inbound/rev/b15858a5d485

Comment 21

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/b15858a5d485

Comment 22

[Alex Keybl [:akeybl]]

(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?

Comment 23

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

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.

Comment 24

[Alex Keybl [:akeybl]]

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.

Comment 25

[Lukas Blakk [:lsblakk] use ?needinfo]

[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.

Comment 26

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

http://hg.mozilla.org/releases/mozilla-aurora/rev/02f621047867

Comment 27

[Scoobidiver (away)]

Fx 13 is the trunk build where the patch landed first.

Comment 28

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

The patch is now on Aurora. Am I misunderstanding Target Milestone?

Comment 29

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

Attachment: move GetData to the beginning so it's always called first

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.

Comment 30

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

http://hg.mozilla.org/integration/mozilla-inbound/rev/647561e71b34

Comment 32

[Karl Tomlinson (:karlt)]

I wonder if we were creating a shader of type GL_FRAGMENT_SHADER without checking for the ARB_fragment_shader extension.

Comment 33

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

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.

Comment 34

[Ed Morley [:emorley]]

(In reply to Benoit Jacob [:bjacob] from comment #30)
> http://hg.mozilla.org/integration/mozilla-inbound/rev/647561e71b34

https://hg.mozilla.org/mozilla-central/rev/647561e71b34

Comment 35

[Cesare Leonardi]

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.

Comment 36

[Thor]

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

Comment 37

[trond]

I have upgraded firefox from 10.0.2 to 11 but it continues to crash unless I add
webgl.disabled=default

Comment 38

[Scoobidiver (away)]

This bug is not fixed in Fx 10 and Fx 11 (see the tracking flags).

Comment 39

[Cesare Leonardi]

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).

Comment 40

[trond]

The bug seems to be fixed in nightly (Version 13), it does not crash at sites 
where Firefox 11 crash.

Comment 41

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

The fix is in Firefox >= 12, see the tracking flags.

Comment 42

[Ioana (away)]

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.

Comment 43

[u279076]

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

Comment 44

[u279076]

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