Arch Linux

No problem here

I have just confirmed the described behaviour. Segfault with my setup, and "crashing tabs" with default setup, which I've achieved by

# pacman -Rcs firefox
# pacman -S firefox

$ rm -rf .mozilla
$ /bin/firefox >/tmp/ff.log 2>&1

I fail to attach the logfile and a post-crash screenshot

sk@tauhou:~$ cat /tmp/ff.log
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[Parent 7774] WARNING: pipe error (45): Connection reset by peer: file /build/firefox/src/firefox-49.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 316
[Parent 7774] WARNING: pipe error (42): Connection reset by peer: file /build/firefox/src/firefox-49.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 316

###!!! [Parent][MessageChannel] Error: (msgtype=0x2C007A,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x2C007A,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

Can confirm this happening on Firefox 49.0.2-1, except it doesn't happen on Linux 4.8.3 and does on 4.8.6. Might not be related, but it might be worth noting.

Yes, I'm on 4.8.6:

sk@tauhou:~$ cat /proc/version
Linux version 4.8.6-1-ARCH (builduser@tobias) (gcc version 6.2.1 20160830 (GCC) ) #1 SMP PREEMPT Mon Oct 31 18:51:30 CET 2016

I cannot reproduce this.

Here's a stack trace generated using `strace -o /tmp/ff.log /usr/bin/firefox`. Is there any other way how I can provide information?

strace produces system call traces, not stack traces. System call traces are not useful here.

You might find stacktraces using coredumpctl.

Awww, how embarassing, I know. I've tried gdb first but it complains
with

$ gdb /usr/bin/firefox
GNU gdb (GDB) 7.12
[...]
Reading symbols from /usr/bin/firefox...(no debugging symbols found)...done.
(gdb)

so I gaveup, sending the list of syscalls instead. Coredumctl gave me
the attached stack trace.

The stacktraces indicate something with nouveau_dri, so it's probably not a bug in firefox but a crash in your graphics driver. That's also why most of us can't reproduce your bug.

Hmmm, would that not also manifest in a lot more situations? I'm
using nouveau since the installation of this system in 2015, but I do
not see too many coredumps.

Also, I've not seen Firefox segfault on any other website, and not in
such a reproducible fashion.

The first entry reported by `coredumpctl` is for the program
`darktable` on the date 2015-07-26. Over time, I've seen

$ coredumpctl list | head -n-1 | wc -l
843

coredumps. Listed by program, that's

$ coredumpctl list |
sed -rn 's#^.*/([^/-]*)$#\1#p' |
sed -r 's#emacs-#emacs#g' |
sort | uniq -c | sort -n
1 svn
1 Xorg
2 mkGraphs
3 freewrl
4 fglMatcher
4 hugin
4 zathura
5 fgl
8 rsh
9 assi
10 queue
15 a.out
15 darktable
16 viking
21 gnuplot
32 firefox
110 parser

Out of these 843 coredumps, only 30 mention `nouveau`, 25 of which
involve `firefox`:

$ coredumpctl list |
sed -r 's#^(\S+\s+){4}(\S+)\s+(\S+\s+){3}.*/([^/]+)$#\2 \4#' |
while read pid name; do
coredumpctl info "$pid" "$name" 2>/dev/null | grep -q nouveau &&
echo "$name";
done | sort | uniq -c
25 firefox
4 hugin
1 Xorg


So the other option may be to file a bug against the
`xf86-video-nouveau` package?

I'm not certain it's an issue with xf86-video-nouveau as it happens to me on Nvidia proprietary drivers, on both 370.28 and 375.10. It doesn't happen on my other machine with xf86-video-intel for whatever reason though. I'll attach the coredumps I have later today.

I have no logical explanation for it, but I've fixed the issue on my end. Apparently the root partition (/boot and /home are separate partitions) being near full or full was causing Firefox to segfault. After extending the root partition, I'm having absolutely no issues so far. It's worth noting that the .mozilla directory is indeed in /home, which isn't even close to full. I wish I could help further but I believe my problem might be another one, regardless of it making any sense or not.