Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#38085 - Firefox segfaults when opening certain website

Attached to Project: Arch Linux
Opened by indianahorst (indianahorst) - Monday, 09 December 2013, 22:08 GMT
Last edited by Ionut Biru (wonder) - Monday, 20 January 2014, 09:21 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 16
Private No


Firefox (without any addons and with all plugins deactivated) throws an segmentation fault when visiting

Additional info:
* package version(s)
extra/firefox 25.0.1-1

System info (inxi):
CPU~Dual core AMD Athlon 5050e (-MCP-) clocked at 2600.000 Mhz Kernel~3.12.3-1-ARCH x86_64 Up~2 days Mem~1245.6/3831.6MB HDD~1000.2GB(94.9% used) Procs~135 Client~Shell inxi~1.9.17

* config and/or log files etc.

$ firefox

(process:28445): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

Segmentation fault (core dumped)

Steps to reproduce:
1. Start Firefox
2. Open the URL
3. Wait until the page is loaded
4. Wait some seconds or scroll down
5. Firefox crashes

This task depends upon

Closed by  Ionut Biru (wonder)
Monday, 20 January 2014, 09:21 GMT
Reason for closing:  Fixed
Additional comments about closing:  Issue seems to be fixed since the update to nvidia 331.38-1.
Comment by Andreas Radke (AndyRTR) - Tuesday, 10 December 2013, 15:03 GMT
Do you use some extension? I have to disable the NoScript extension here on one of my systems or it will crash all time.
Comment by indianahorst (indianahorst) - Tuesday, 10 December 2013, 16:45 GMT
Have you read my text? First sentence:
Firefox (without any addons and with all plugins deactivated) (...)

I have tried it with addons and without addons (and plugins), it doesn't make a difference, Firefox continues crashing after a few seconds on this page.
Comment by Andreas Radke (AndyRTR) - Tuesday, 10 December 2013, 18:55 GMT
Sry for mistake.

BTW: my crash is fixed with FF 26 in testing.
Comment by indianahorst (indianahorst) - Tuesday, 10 December 2013, 23:35 GMT
I'm sorry, but I can't agree. Today I updated to FF 26 and it still segfaults on this site ("testing" is a profile without addons and with all plugins inactive):

$ firefox -P testing

(process:25599): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
OpenGL version detected: 210
OpenGL version detected: 210
OpenGL version detected: 210
Segmentation fault (core dumped)
Comment by Jan de Groot (JGC) - Wednesday, 11 December 2013, 11:57 GMT
Try to get a backtrace, your debug messages indicate nvidia drivers, so this could be a driver or plugin issue.
Comment by Kevin (anonymous_user) - Wednesday, 11 December 2013, 18:29 GMT
Does the crash occur with the build from Mozilla too?
Comment by indianahorst (indianahorst) - Wednesday, 11 December 2013, 19:28 GMT

Here is the output of gdb. Hope it helps!

$ gdb /usr/bin/firefox
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /usr/lib/firefox/firefox...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/firefox
warning: Could not load shared library symbols for
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/".
[New Thread 0x7fffe7220700 (LWP 17590)]
[Thread 0x7fffe7220700 (LWP 17590) exited]

(process:17580): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
[New Thread 0x7fffe7220700 (LWP 17608)]
[New Thread 0x7fffe53ff700 (LWP 17620)]
[New Thread 0x7fffe49ff700 (LWP 17629)]
[New Thread 0x7fffe41fe700 (LWP 17630)]
[New Thread 0x7fffe359f700 (LWP 17633)]
[New Thread 0x7fffe1bff700 (LWP 17640)]
[New Thread 0x7fffe13fe700 (LWP 17641)]
[New Thread 0x7fffe09ff700 (LWP 17642)]
[New Thread 0x7fffe01fe700 (LWP 17643)]
[New Thread 0x7fffdf7ff700 (LWP 17644)]
[New Thread 0x7fffd4227700 (LWP 17645)]
[New Thread 0x7fffd36ff700 (LWP 17646)]
[New Thread 0x7fffd2cff700 (LWP 17647)]
[New Thread 0x7fffd1dff700 (LWP 17648)]
[New Thread 0x7fffc52ff700 (LWP 17681)]
[New Thread 0x7fffc45f0700 (LWP 17682)]
[New Thread 0x7fffc377c700 (LWP 17683)]
[New Thread 0x7fffc2f7b700 (LWP 17684)]
[New Thread 0x7fffe0bfd700 (LWP 17685)]
[New Thread 0x7fffc277a700 (LWP 17686)]
[New Thread 0x7fffc1f79700 (LWP 17697)]
[New Thread 0x7fffc1778700 (LWP 17698)]
[New Thread 0x7fffc0d6b700 (LWP 17699)]
[New Thread 0x7fffc056a700 (LWP 17701)]
[New Thread 0x7fffbfd69700 (LWP 17703)]
[New Thread 0x7fffbf362700 (LWP 17709)]
[New Thread 0x7fffbbc40700 (LWP 17727)]
[New Thread 0x7fffbb43f700 (LWP 17728)]
[New Thread 0x7fffbac3e700 (LWP 17729)]
[New Thread 0x7fffba43d700 (LWP 17730)]
[New Thread 0x7fffb9c3c700 (LWP 17733)]
[New Thread 0x7fffb943b700 (LWP 17742)]
[New Thread 0x7fffb8c3a700 (LWP 17743)]
[New Thread 0x7fffb72ff700 (LWP 17768)]
[New Thread 0x7fffb5fff700 (LWP 17769)]
[New Thread 0x7fffb57fe700 (LWP 17770)]
[Thread 0x7fffba43d700 (LWP 17730) exited]
[New Thread 0x7fffba43d700 (LWP 17851)]
[New Thread 0x7fffa98ff700 (LWP 17887)]
[New Thread 0x7fffa90ff700 (LWP 17907)]
[New Thread 0x7fffa88fe700 (LWP 17915)]
[New Thread 0x7fffa80fd700 (LWP 18110)]
[New Thread 0x7fffa78fc700 (LWP 18111)]
[Thread 0x7fffb943b700 (LWP 17742) exited]
[Thread 0x7fffb8c3a700 (LWP 17743) exited]
[Thread 0x7fffbac3e700 (LWP 17729) exited]
OpenGL version detected: 210
OpenGL version detected: 210
OpenGL version detected: 210

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe8a8db60 in ?? () from /usr/lib/
Comment by indianahorst (indianahorst) - Wednesday, 11 December 2013, 19:30 GMT
@ Kevin
Which program package from the Archlinux Repositories do you mean?
Comment by Kevin (anonymous_user) - Wednesday, 11 December 2013, 19:31 GMT
I mean if you download the tarball build from the Mozilla website:
Comment by patrick (potomac) - Wednesday, 11 December 2013, 22:06 GMT
no problems for me with firefox 26 and a radeon 4650 pcie graphic card ( radeon driver open source )

maybe it's a graphic driver problem, for those who have this bug : try to disable Hardware Acceleration feature in firefox options
Comment by Jan de Groot (JGC) - Thursday, 12 December 2013, 08:55 GMT
Your backtrace indicates a segfault in, which is part of the binary nvidia drivers. Typing "bt" in gdb after the crash would be nice to get a better overview of which path is called.
Probably there's nothing we or mozilla devs can fix here, as a binary module is involved.
Comment by indianahorst (indianahorst) - Thursday, 12 December 2013, 11:11 GMT
Here is the output of "bt":

#0 0x00007fffe8a8db60 in ?? () from /usr/lib/
#1 0x00007fffe89e0846 in ?? () from /usr/lib/
#2 0x00007fffe8941c7e in ?? () from /usr/lib/
#3 0x00007fffe87b4db3 in ?? () from /usr/lib/
#4 0x00007ffff3fa5aec in ?? () from /usr/lib/firefox/
#5 0x00007ffff3fa5b1f in ?? () from /usr/lib/firefox/
#6 0x00007ffff3fa7129 in ?? () from /usr/lib/firefox/
#7 0x00007ffff3fa74ff in ?? () from /usr/lib/firefox/
#8 0x00007ffff3fa75fb in ?? () from /usr/lib/firefox/
#9 0x00007ffff3fa0f21 in ?? () from /usr/lib/firefox/
#10 0x00007ffff3fa0f5f in ?? () from /usr/lib/firefox/
#11 0x00007ffff3f9949c in ?? () from /usr/lib/firefox/
#12 0x00007ffff3f97b15 in ?? () from /usr/lib/firefox/
#13 0x00007ffff3f97b85 in ?? () from /usr/lib/firefox/
#14 0x00007ffff3293139 in ?? () from /usr/lib/firefox/
#15 0x00007ffff3290882 in ?? () from /usr/lib/firefox/
#16 0x00007ffff3e7e303 in ?? () from /usr/lib/firefox/
#17 0x00007ffff375063d in ?? () from /usr/lib/firefox/
#18 0x00007ffff3e729ad in ?? () from /usr/lib/firefox/
#19 0x00007ffff3e31649 in ?? () from /usr/lib/firefox/
#20 0x00007ffff3a15a1b in ?? () from /usr/lib/firefox/
#21 0x00007ffff3ecb6ff in ?? () from /usr/lib/firefox/
#22 0x00007ffff3990435 in ?? () from /usr/lib/firefox/
#23 0x00007ffff3820d2b in ?? () from /usr/lib/firefox/
#24 0x00007ffff2c99c4f in ?? () from /usr/lib/firefox/
#25 0x00007ffff2c99eb9 in ?? () from /usr/lib/firefox/
#26 0x00007ffff2c9a0e4 in XRE_main () from /usr/lib/firefox/
#27 0x0000000000403980 in _start ()
Comment by Jan de Groot (JGC) - Thursday, 12 December 2013, 11:32 GMT
Maybe you can get more information by compiling firefox with debug information, but so far this looks like a bug in the nvidia drivers. Please report this at nvidia, we can't fix this.
Comment by Linus Ljung (Lurq) - Sunday, 15 December 2013, 00:17 GMT
I have the same problem since firefox 26.0-2. But it's, for me, very hard to reproduce. I will do some testing when there is time.
Comment by Bruno Guerreiro (American_Jesus) - Sunday, 15 December 2013, 15:41 GMT
Same problem here since Firefox 26.0, segmentation fault when try to use Lastpass

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff58658da in ?? () from /usr/lib/firefox/

Full log attached

I tried with official build from Mozilla, works without problem without crashes
Comment by Jouke Witteveen (jouke) - Sunday, 15 December 2013, 21:50 GMT
Rebuilding the package (which took an hour!) seems to solve the problem here.

I did need to add the following line to the build() function in the PKGBUILD:
export SHELL="/usr/bin/bash"

At the end of the build process, there was a warning:
==> WARNING: Package contains reference to $srcdir
Comment by Florian Kiersch (Mortes) - Monday, 16 December 2013, 14:45 GMT
Just want to add that for some reason, for me Firefox runs just fine when I start it from the terminal. Otherwise it will crash on some random resources like PDFs or gifs.

Edit: added Firefox gdb output with backtrace. I don't see anything NVIDIA related in there. There's btw. another user reporting the same issue with an Intel graphics card:
Comment by Pantelis Panayiotou (plp) - Monday, 16 December 2013, 21:06 GMT
Mortes: The exact same thing seems to be happening with me.

More details:
- Firefox crashes randomly, but more often when opening PDFs
- The problem seems to go away when running from inside a terminal
- Downgrading to 26.0-1 appears to solve the problem
Comment by Anael (nanawel) - Monday, 16 December 2013, 21:50 GMT
Running Firefox 26.0-2 and crashing randomly, not necessarily with PDFs, but it doesn't seem to happen when running from a terminal.
Comment by Reed Lipman (rlipman) - Tuesday, 17 December 2013, 06:00 GMT
I see segfaults with things like opening the file dialog, or from the basic auth dialog. My backtrace isn't nvidia related either.

#0 0x00007ffff58658da in ?? () from /usr/lib/firefox/
#1 0x00007ffff5908115 in ?? () from /usr/lib/firefox/
#2 0x00007ffff7e4625c in ?? ()
#3 0x0000000000000000 in ?? ()
Comment by J. Dulac (JD) - Wednesday, 18 December 2013, 09:20 GMT
Same issue here.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff590f20d in ?? () from /usr/lib/firefox/

Crashes with a profile with extensions and inactive plugins
Crashes with a profile with no extension and inactive plugins (and even disabled HW acceleration)
Seems ok in "pure" safe-mode

I agree with rlipman : dialog openings (especially auth) seems to lead to more segfaults than regular browsing.

Running from a terminal seemed to correct the problem yesterday, but today it's a mess too...
Comment by J. Dulac (JD) - Thursday, 19 December 2013, 15:41 GMT
Additional information : crashes also in "pure" safe-mode with internal PDF viewer...
Comment by Tomi Leppänen (Tomin) - Thursday, 19 December 2013, 17:17 GMT
Crashes very often on my laptop too. I've got Nvidia Quadro NVS140 graphics.
$ LANGUAGE=C pacman -Qi firefox nvidia |grep -i version
Version : 26.0-2
Version : 331.20-2
gdb stuff (I don't know if it's useful):

PDF viewer seems to always crash even in safe-mode. For example this pdf causes a crash for me:

I reset my Firefox and it didn't help a thing, so now I'm hunting all my addons back.
Comment by JD (lightheat) - Friday, 20 December 2013, 07:23 GMT
It had been crashing for me, too. Same exact chip (NVS 140) and versions for both firefox and the nvidia driver as commenter above me. I tried disabling hardware acceleration which seems to have fixed it for now. Running firefox from terminal outputs a long repeating string of

OpenGL version detected: 330
OpenGL version detected: 330
OpenGL version detected: 330

so long as the page in the original report ( is open, but it will not crash.

This does seem to be an issue between firefox and nvidia. I'll keep playing around and see if I can get it to segfault again.
Comment by J. Dulac (JD) - Friday, 20 December 2013, 08:26 GMT
nvidia too here, with same versions, but different chip (Quadro FX 580 - chip is G96).
As mentioned above, it still crashes with hw acceleration disabled :/

I guess it's related !
Comment by J. Dulac (JD) - Friday, 20 December 2013, 08:55 GMT
Downgrading nvidia drivers version through nvidia-304xx packages solved the issue (I had to use --force with pacman), but downgrading is not a real solution, in my opinion...
Comment by Tomi Leppänen (Tomin) - Friday, 20 December 2013, 10:38 GMT
I've deselected "Use hardware acceleration when available" and "Use smooth scrolling" from Preferences but that didn't help. I also set true to webgl.disabled but it still crashes sometimes. The pdf I mentioned crashes Firefox always. I wonder if there is somewhere another option that I need to change to stop this crashing.

Waiting for a fix.
Comment by Hermann Zahnweh (eigengrau) - Friday, 20 December 2013, 11:11 GMT
Tinkering with Firefox won't really help much. It's a driver issue and for most of us it's probably not restricted to Firefox. Though Firefox would certainly be the most noticeable manifestation. The other issues include processes zombifying, and Mono applications not starting up at all (as with Firefox, this is somewhat alleviated by starting from a terminal window).

For the Mono issues, there's a separate Task at , but in all likelihood this is the same bug.

The driver issues are "tracked" (discussed, rather) upstream at

Another user was so kind to provide PKGBUILDs for the old version of the driver in
Comment by JD (lightheat) - Saturday, 21 December 2013, 01:59 GMT
Follow-up: yep, still crashed, same report of segfault, even with HW accel disabled. Will try rolling back nvidia to previous version. ^Thanks for the link, and to that user for the PKGBUILD.
Comment by Pantelis Panayiotou (plp) - Saturday, 21 December 2013, 09:00 GMT
Here are the differences between firefox 26.0-2 and 26.0-1:

The most important change is that 26.0-2 is linked against a lot more system libraries (as opposed to built-in code provided by Mozilla). In particular, the following lines got added to mozconfig:

+ac_add_options --with-system-nspr
+ac_add_options --with-system-nss
+ac_add_options --with-system-jpeg
+ac_add_options --with-system-zlib
+ac_add_options --with-system-bz2
+ac_add_options --with-system-png
+ac_add_options --with-system-libevent
+ac_add_options --with-system-libvpx
+ac_add_options --enable-system-hunspell
+ac_add_options --enable-system-sqlite
+ac_add_options --enable-system-ffi
+#ac_add_options --enable-system-cairo

Perhaps someone could remove these, re-build the package, and see if Firefox still crashes?

(I plan to do this myself, of course, but I'm in a hurry right now.)

UPDATE: I just verified it's an nvidia issue myself. So, I also think tinkering with Firefox is not really a solution. I-ll be using nvidia-304xx until this is resolved upstream.
Comment by revel (revel) - Saturday, 21 December 2013, 14:51 GMT
Recently my firefox started crashing too. Having read the suggestions above, I rebuilded the package [from ABS] myself [no tinkering] and crashes got even worse. So next went nvidia packages: nvidia and nvidia-utils [splits into 3 packages]. Got them rebuilded [again ABS, no tinkering, no downgrading], reinstalled and then rebooted to make sure everything's fully reloaded. And viola, the crashes went away! Not sure if the problem is really solved or it just stopped manifesting, but for now it surely is good enough for me. For reference, I'm on x86-64.
Comment by Pantelis Panayiotou (plp) - Sunday, 22 December 2013, 19:33 GMT
revel: I tried what you suggested, and it does make Firefox a bit more stable. Mono applications still won't start, though.
Comment by revel (revel) - Sunday, 22 December 2013, 20:17 GMT
I compared my /etc/makepkg.conf to the default one and I have '-D_FORTIFY_SOURCE=2' added at the end of both CFLAGS and CXXFLAGS. Default makepkg have this only in CPPFLAGS and I can remember making above change some time ago. If this really makes difference here, then clearly there is some buffer overflow problem in recent nvidia packages and it got 'autofixed' or masked well enough to stop crashes for me.
Comment by F. Goovaerts (MajorMonodon) - Tuesday, 24 December 2013, 14:12 GMT
I have also been troubled by this occurence the last week, switching to nouveau drivers instead of the nvidia ones until this is fixed helped for me, so it is indeed a driver problem.

This should be changed to a problem with Nvidia packages, not firefox, and merged with the mono bug, seeing as that is probably from the same source (as far as I have deduced from reading forum posts about this topic).
Comment by Bruno Guerreiro (American_Jesus) - Tuesday, 24 December 2013, 15:27 GMT
same here, i changed my gpu to an AMD/ATI and the problem no longer persists. probably a nvidia driver problem
Comment by F. Goovaerts (MajorMonodon) - Wednesday, 25 December 2013, 15:37 GMT
After updating today, the problem seems to have been resolved. Anyone else?
Comment by Tomi Leppänen (Tomin) - Friday, 27 December 2013, 16:24 GMT
Still crashing on my Firefox profile, but I haven't yet had a crash in safe mode. Still testing.
$ LANGUAGE=C pacman -Qi firefox nvidia |grep -i version
Version : 26.0-2
Version : 331.20-3

As this is a Nvidia driver problem, are Nvidia's developers aware of this?
Comment by Tomi Leppänen (Tomin) - Friday, 27 December 2013, 16:26 GMT
Ok, crashed in safe mode too when tried to (rapidly) browse the pdf I mentioned earlier.
Comment by Sergio (whizzo) - Friday, 27 December 2013, 18:07 GMT
Same crashings here
Comment by Ameer (ameer) - Saturday, 28 December 2013, 13:11 GMT
I think the best solution right now is to switch to the open source driver for NVIDIA, nouveau. That worked for me. And maybe wait until NVIDIA solve this bug in the official driver.
Comment by Sergio (whizzo) - Sunday, 29 December 2013, 14:49 GMT
I think is the same problem with:

In the last comment (12/26/2013) they said: "Issue no longer reproduce with our latest driver that will be available soon."
I hope this work.
Comment by Romain Riviere (Le_Coyote) - Thursday, 09 January 2014, 12:42 GMT
I do confirm that rebuilding nvidia and nvidia-utils with -D_FORTIFY_SOURCE=2 is enough to make the problem go away. Thanks revel for the tip!

Edit: added a link to this bug report over at Mozilla's:
Comment by Jan de Groot (JGC) - Thursday, 09 January 2014, 16:05 GMT
Ehm, -D_FORTIFY_SOURCE=2 is the default in our distribution, so how can this possibly fix the bug?

Are you guys all running custom compiles without default CFLAGS/CPPFLAGS?
Comment by J. Dulac (JD) - Thursday, 09 January 2014, 16:18 GMT
I use the official package from official repository mirror.
Comment by revel (revel) - Thursday, 09 January 2014, 16:59 GMT
My story [mentioned above] of altering makepkg.conf as far as I can remember looked like this:
- noticed -D_FORTIFY_SOURCE=2 was sometimes missing during build process despite being in CPPFLAGS
- googled around and learned that indeed CPPFLAGS can sometimes be ignored altogether
- concluded that some build tools on linux are probably flawed in this regard [it's quite a mess isn't it?]
- decided that it's better to alter CFLAGS and CXXFLAGS and sleep well
Comment by Romain Riviere (Le_Coyote) - Thursday, 09 January 2014, 19:32 GMT
Just to clarify, what I did was switch from the binary packages available in the repos to packages built from ABS. On 2 separate machines, this fixed the issue. The rest of the distribution is straight out of the box, and up to date as of yesterday.

Regarding -D_FORTIFY_SOURCE=2, it was set in CPPFLAGS alone on 1 machine, while it was defined in CFLAGS and CXXFLAGS on the other. Building nvidia stuff with only the CPPFLAGS was not enough for the former, so I modified makepkg.conf to match that of the latter, ie. follow revel's advice. Voilà :-)
Comment by Romain Riviere (Le_Coyote) - Sunday, 12 January 2014, 18:44 GMT
I have to amend the previous statement. The bug still exists. It occurs much less often, but it's still there. It seems that restoring a session with a few pinned and unpinned tabs, that are opened simultaneously on start-up, is quite likely to demonstrate the issue. It is still random though.
Comment by Reed Lipman (rlipman) - Monday, 13 January 2014, 20:47 GMT
Is this still an issue with nvidia 331.38?
Comment by Romain Riviere (Le_Coyote) - Wednesday, 15 January 2014, 14:44 GMT
I just upgraded to nvidia 331.38-1 and Firefox seems a lot more stable indeed. I'll give it a go on the other system and report back.

[Edit] Just had 2 crashes. They didn't occur at startup but a little later. I'll have to test some more.
Comment by Florian Kiersch (Mortes) - Monday, 20 January 2014, 08:29 GMT
The issue seems fixed for me since the update to the current NVIDIA driver (nvidia 331.38-1). I didn't have a single browser crash for about a week of daily usage. Anyone still having issues?
Comment by Hermann Zahnweh (eigengrau) - Monday, 20 January 2014, 08:38 GMT
Nope, should be good to close. It's been a fair time now, and since 331.38 also resolved the problems with Mono applications, it seems that this time it's really fixed.
Comment by revel (revel) - Monday, 20 January 2014, 08:56 GMT
Works for me as well.
Comment by Romain Riviere (Le_Coyote) - Monday, 20 January 2014, 09:13 GMT
Looks fixed here too, I couldn't reproduce the crashes.