6 years ago
2 years ago


(Reporter: julienw, Unassigned, NeedInfo)


({crash, regression, reproducible})

22 Branch

Firefox Tracking Flags

(firefox23-, firefox24-)


(Whiteboard: [gfx-noted][platform-rel-nVidia], crash signature, )


(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-d1f97c77-738e-4904-8abc-bb7102130502 .

I get this crash several times a day.

For me, it seems to happen most on (maybe more in subpages but I'm not sure), particularly if I do anything while the page is still loading: scrolling, entering a comment. But it's not systematic either.

If I wait that the loading is finished, then I have no crash.

I think the nvidia driver is the latest one I can have.

The first time I got this crash was :

Could this be related to the recent layers refactoring ?
Does it happen in Safe Mode (see and with only extensions disabled (HW acceleration turn on)?

(In reply to Julien Wajsberg [:julienw] from comment #0)
> Could this be related to the recent layers refactoring ?
The layer refactoring hasn't landed in Aurora 22.
Flags: needinfo?(felash)
Summary: crash in libnvidia → crash in libnvidia-glcore
so, unfortunately, my computer where that happened decided to not turn on anymore, so I can't test it now. I suppose this could be related too, but I'm not sure.
Flags: needinfo?(felash)
(keeping the needinfo for now)
Flags: needinfo?(felash)
Duplicate of this bug: 869967
Crash Signature: [@] → [@] [@ ]
As mentioned elsewhere, I can easily reproduce (what seems to be) this same failure by visiting this page:

Shortly after loading that page (and possibly involving some random movement of the mouse pointer without any clicks) my browser dies with a SIGSEGV.

This seems to be quite repeatable, even if I first completely delete my entire ~/.mozilla hierarchy, ie. if I run a completely "virgin" (unmodified, no add-ons, etc) Firefox.  However, when I run this in my normal mode with my usual collection of add-ons and extensions active, and if I then use NoScript to prevent Javascript from executing on that site, no SIGSEGV is seen.
It doesn't happen with a new profile but does it happen in Safe Mode ( that disables HW acceleration as your crash is a driver crash?

Can you find a regression range using
Flags: needinfo?(felash) → needinfo?(mod.bugzilla.mozilla)
That mozregression tool is handy - nice work.

The easily reproducible conclusion is:

 Last good nightly: 2013-02-22
 First bad nightly: 2013-02-23

...which quickly fails when viewing the page mentioned in Comment 5.
Flags: needinfo?(mod.bugzilla.mozilla)
Also, please note that I am a different person than the one who opened this bug (I opened a different one that got closed as a dupe of this one) and I have no info re: Safe Mode behavior.
(In reply to M ODonnell from comment #7) 
>  Last good nightly: 2013-02-22
>  First bad nightly: 2013-02-23
The regression range is:

(In reply to M ODonnell from comment #8)
> I have no info re: Safe Mode behavior.
Please answer to that question.
Flags: needinfo?(felash)
Version: unspecified → 22 Branch
OK, I explicitly restarted the 2013-02-23 version in Safe Mode and it still fails.  I'm just a civilian but FYI this may have been an unnecessary exercise as it sure looks to me like the default is already for mozregression to launch the browsers in (what is effectively) Safe Mode.
(In reply to M ODonnell from comment #10)
> OK, I explicitly restarted the 2013-02-23 version in Safe Mode and it still
> fails. 
So it's not a graphics bug, maybe an ImageLib one because both URLs have many images

It might be a regression from bug 853169 that has a Linux specific change.
Flags: needinfo?(felash)
Crash Signature: [@] [@ ] → [@] [@] [@]
It's #1 top crasher in 22.0 on Linux.
Keywords: topcrash
Hardware: x86 → All
Crash Signature: [@] [@] [@] → [@] [@] [@] [@] [@]
Joe, what's your spidey sense tell you on this being a regression from bug 853169?
Flags: needinfo?(joe)
Seems very unlikely, though I guess it's possible. If someone could get us a stack trace from that thread, it'd be *very* helpful.

Odd that it's libnvidia-glcore, considering we don't enable GL layers by default on Linux; maybe X just ends up there.
Flags: needinfo?(joe)
M ODonnell, are you able to get a stack trace with a debugger (see
Flags: needinfo?(mod.bugzilla.mozilla)
Output from GDB showing attachment to the firefox process, trapping a subsequent SIGSEGV and then the results of a "thread apply all backtrace full" command.
Flags: needinfo?(mod.bugzilla.mozilla)
Please note that this morning my browser has no trouble rendering that previously fatal wooseung-lee page, but this morning this page:

...very reliably triggers a SIGSEGV that I believe to be closely related.  Note that I obtained the attached stack trace "by hand" using GDB and that the automated dump creation/transmission procedure seems not to have sent the corresponding dump back to the mother-ship.  However, dumps ID'd thusly:

  -rw------- 1 mod mod 1036552 Jun 29 09:25 33331e06-b5a6-1c3b-4286e1d5-7e365b06.dmp
  -rw-r--r-- 1 mod mod    1963 Jun 29 09:25 33331e06-b5a6-1c3b-4286e1d5-7e365b06.extra

...were triggered under identical conditions.  (Yes, in Safe Mode)
Over to Joe to take a look at comment 16.
Assignee: nobody → joe
I can reproduce this with SeaMonkey 2.19 on openSUSE 12.3 (x86-64) using the page.  Perhaps my Bug 891812 is a duplicate of this one.
Duplicate of this bug: 891812
Joe - have you had a chance to investigate further here?
Flags: needinfo?(joe)
Looking at the stacks, it's almost certainly a bug in NVIDIA's X driver, since we're on thread 1 and it doesn't go beyond the NVIDIA symbols. More than that I can't say. :(

It'd be nice if we could get an NVIDIA Linux driver developer to look at this!
Flags: needinfo?(joe)
Karl, I could use a hand here. Can you look at the patches on bug 853169 and see if there's something I missed in PlatformGtk initialization? Do you have an NVIDIA computer that can reproduce this (I don't)?
Flags: needinfo?(karlt)
I think a crash in must be WebGL related.  That could be confirmed by setting webgl.disabled to true in about:config.  Xlib and Xrender usage is all server communication with use of the driver only in the X server.

It's hard to imagine how bug 853169 could be involved here.  If I had to guess from the regression window, then perhaps bug 852803 or some xpconnect changes causing a change in lifetime timing.

I don't have an NVIDIA card.
Component: Graphics: Layers → Canvas: WebGL
Flags: needinfo?(karlt)
Grrrr!  at this moment my 25.0a1/2013-07-21 build easily displays both of the troublesome pages in question...
...and I can't get 25.0a1/2013-07-22 to fail, either.
No longer in the topcrasher lists for Linux, untracking.
(In reply to [:lsblakk] from comment #27)
> No longer in the topcrasher lists for Linux, untracking.
It's still #1 top crasher in 22.0 on Linux so a topcrash according to
Keywords: topcrash
Assignee: joe → nobody
(In reply to Karl Tomlinson (:karlt) from comment #24)
> I think a crash in must be WebGL related.  That could be
> confirmed by setting webgl.disabled to true in about:config.  

I can confirm this. Disabling "webgl" stops the crashes when browsing sites where Firefox has constantly and reproducible crashes.

Running Debian Wheezy, nvidia quadro nvs 440 card, firefox 23 and nvidia 304.88 driver.
I'm also experiencing the same segfault. I have found that I can reproduce the crash consistently using the following site, although sometimes I need to close Firefox and launch a second instance to get the crash, particularly if it was the first Firefox instance after logging in:

To get the crash:
1. Click the dropdown to the right of "Product:"
2. Scroll up and down randomly by grabbing the scrollbar.
3. Click on one of the product names.
4. Repeat steps 1-3 until you get the crash. For me, the crash usually happens when I click the scrollbar to drag it.

I am using an NVIDIA GeForce 7900 GS with the 304.88 proprietary NVIDIA driver.

I hope this is helpful to someone. Let me know if you want any more info (gdb backtrace, etc.).
I forgot to mention two other things:
1. The crash no longer happens for me after disabling WebGL in Firefox (by setting "webgl.disabled" to "true" in about:config)
2. The cause of this crash seems to appear around Firefox 22, as I do not get the crash with Firefox 21 or earlier.
Crash Signature: [@] [@] [@] [@] [@] → [@] [@] [@] [@] [@] [@] [@ …
Same SIGSEV happened to me today on chromium v28, so I agree that this must be somehow NVIDIA related.
Background: When opening a specific site (Which I cannot post here, because it's under development) firefox (v24) crashes after a few seconds wheras chromium only crashed on the same site once so far.
I sent my crash dump of firefox and chromium to and after some questioning they decided to create an issue:
Bug ID:1381810
(As it seems, the nvidia bugtracker can only be accessed with an nvidia developer account, which I don't have. I just mention it in case someone else wants to reference the issue...)

So as I perceive it - this is really an nvidia bug and should be discussed there.

However for the sake of completeness:
For me this happens using a GeForce 7050 PV on an up-to-date Ubuntu 12.04 64bit (x server 1.11.3, nvidia-304.88-0ubuntu0.0.3, firefox 24.0). It happens under unity-2d as well as under unity-3d.

It does however NOT happen (for example) on a different PC using a GeForce GTX 260 and the same software versions as on the first machine (also 64bit).
topcrash is being replaced by more precise keywords per
Keywords: topcrashtopcrash-linux
(In reply to Camaleon from comment #29)
> (In reply to Karl Tomlinson (:karlt) from comment #24)
> > I think a crash in must be WebGL related.  That could be
> > confirmed by setting webgl.disabled to true in about:config.  
> I can confirm this. Disabling "webgl" stops the crashes when browsing sites
> where Firefox has constantly and reproducible crashes.

This workaround works for me.  (I am running SeaMonkey 2.23 on openSUSE 13.1 (64-bit) with a GeForce 7300 SE and version 304.108 of the NVIDIA driver.)  Are there any disadvantages of disabling WebGL, apart from presumably a degradation in performance?
Crash Signature:] →] [@]
If someone wants to reproduce it, this online banking site regularly crashed FF (24.2.0, Gentoo amd64) for me: (one of the largest German banks).  Disabling WebGL manually seems  to work for me so far.  If anyone is interested, this is a (pretty meaningless) backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe933fb60 in ?? () from /usr/lib64/
(gdb) bt
#0  0x00007fffe933fb60 in ?? () from /usr/lib64/
#1  0x00007fffe9292846 in ?? () from /usr/lib64/
#2  0x00007fffe91f3c7e in ?? () from /usr/lib64/
#3  0x00007fffe9066db3 in ?? () from /usr/lib64/
#4  0x00007ffff4d7338e in ?? () from /usr/lib64/firefox/
#5  0x00007ffff4d733b1 in ?? () from /usr/lib64/firefox/
#6  0x00007ffff4d73e6b in ?? () from /usr/lib64/firefox/
#7  0x00007ffff4d73f66 in ?? () from /usr/lib64/firefox/
#8  0x00007ffff4d7406b in ?? () from /usr/lib64/firefox/
#9  0x00007ffff4d7120a in ?? () from /usr/lib64/firefox/
#10 0x00007ffff4d71237 in ?? () from /usr/lib64/firefox/
#11 0x00007ffff4d6c2c6 in ?? () from /usr/lib64/firefox/
#12 0x00007ffff4d6c57f in ?? () from /usr/lib64/firefox/
#13 0x00007ffff4d6a427 in ?? () from /usr/lib64/firefox/
#14 0x00007ffff4d6a499 in ?? () from /usr/lib64/firefox/
#15 0x00007ffff43838f5 in ?? () from /usr/lib64/firefox/
#16 0x00007ffff439275b in ?? () from /usr/lib64/firefox/
#17 0x00007ffff4392b6b in ?? () from /usr/lib64/firefox/
#18 0x00007ffff4392ce9 in ?? () from /usr/lib64/firefox/
#19 0x00007ffff438ee20 in ?? () from /usr/lib64/firefox/
#20 0x00007ffff4c9f12b in ?? () from /usr/lib64/firefox/
#21 0x00007ffff4cd2d02 in ?? () from /usr/lib64/firefox/
#22 0x00007ffff4cd2d8c in ?? () from /usr/lib64/firefox/
#23 0x00007ffff4cd309b in ?? () from /usr/lib64/firefox/
#24 0x00007ffff4cd318c in ?? () from /usr/lib64/firefox/
#25 0x00007ffff4568d22 in ?? () from /usr/lib64/firefox/
#26 0x00007ffff45692e1 in ?? () from /usr/lib64/firefox/
#27 0x00007ffff4ccd6ca in ?? () from /usr/lib64/firefox/
#28 0x00007ffff4ccd79f in ?? () from /usr/lib64/firefox/
#29 0x00007ffff4ccafde in ?? () from /usr/lib64/firefox/
#30 0x00007ffff4c9ede3 in ?? () from /usr/lib64/firefox/
#31 0x00007ffff49cc700 in ?? () from /usr/lib64/firefox/
#32 0x00007ffff4cea81d in ?? () from /usr/lib64/firefox/
#33 0x00007ffff4974175 in ?? () from /usr/lib64/firefox/
#34 0x00007ffff484e785 in ?? () from /usr/lib64/firefox/
#35 0x00007ffff3f4f14a in ?? () from /usr/lib64/firefox/
#36 0x00007ffff3f510ce in ?? () from /usr/lib64/firefox/
#37 0x00007ffff3f512e5 in XRE_main () from /usr/lib64/firefox/
#38 0x000000000040498d in _start ()
(In reply to daniel.hornung from comment #37)
> (one of the largest German banks).
If you want to test it without using your bank account (if you even have one), there's a link "Demokonto testen" (test sample account).  Playing around a bit crashed my FF after clicking typically 5-15 buttons on the site.
Using WebGL in Firefox 23 with a Geforce 6 GPU would trigger a crash in the NVIDIA driver, when the WebGL tab was closed. We have fixed this bug in driver version 304.119. More recent GPUs are not affected.

Thread no. 1 (10 frames)
 #1 nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) at /usr/lib64/firefox/
 #3 ??
 #4 st_texture_release_all_sampler_views at /usr/lib64/dri/
 #5 st_DeleteTextureObject at /usr/lib64/dri/
 #6 _mesa_reference_shared_state at /usr/lib64/dri/
 #7 _mesa_free_context_data at /usr/lib64/dri/
 #8 st_destroy_context at /usr/lib64/dri/
 #9 dri_destroy_context at /usr/lib64/dri/
 #10 driDestroyContext at /usr/lib64/dri/
 #11 drisw_destroy_context at /lib64/
Taking all* crashes into account this is no longer a topcrash. Just looking at Linux crashes this is ranked around #47. 

That said, there are still crashes happening:
> 26 in Firefox 41 
>  3 in Firefox 40
> 65 in various Firefox versions 32 and below
Keywords: topcrash-linux
These crashes are still being reported, we have 67 reports against Firefox 48. We don't get adapter/driver correlations for some reason but we do get some info via AppNotes.

50.75% NVIDIA GeForce 6150SE nForce 430 w/ 2.1.2 NVIDIA 304.88
17.91% NVIDIA GeForce Go 7400 w/ 2.1.2 NVIDIA 304.88
 4.48% NVIDIA GeForce 7025 nForce 630a  w/ 2.1.2 NVIDIA 304.88
 2.99% NVIDIA GeForce 7600 GS w/2.1.2 NVIDIA 304.88
 1.49% NVIDIA GeForce 6800 LE w/2.1.2 NVIDIA 304.88
 1.49% NVIDIA GeForce 6800 XT w/2.1.2 NVIDIA 304.88
 1.49% NVIDIA GeForce 7050 PV nForce 630a w/2.1.2 NVIDIA 304.88
 1.49% NVIDIA GeForce Go 7600 w/2.1.2 NVIDIA 304.88

Looks like this is completely isolated to old GeForce 6000/7000 GPUs on the 304.88 Linux driver. I wonder if we can work around this with blocklisting?
Flags: needinfo?(milan)
Whiteboard: [gfx-noted]
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted][platform-rel-nVidia]
platform-rel: ? → ---
I still get this bug regularly on all the latest firefox releases with nvidia 378.13 driver tends to happen with youtube videos, but it's happened completely randomly for me as well.
This is happening every day now, at least once a day if not more, firefox has become pretty much unusable.
Comment #42: the crash is fixed in 304.199 as explained in my comment #39. It is absolutely specific to Geforce 6/7, and will not affect newer GPUs or up-to-date drivers.
Comment #43: this isn't the same bug. If you're running 378.13, then you're using a GPU that isn't affected by this crash. You should file a separate bug.
You need to log in before you can comment on or make changes to this bug.