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?

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

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.

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

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

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?

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

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

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

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

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

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.

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

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.

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.

(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

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.

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