I have installed www-client/mozilla-firefox-1.5-r9. Firefox reliably crashes due to a segmentation violation when fed certain HTML files. I seem to be encountering about one such bad file per day in random web browsing. The problem may be related to the font machinery. The problems happen in a fresh profile (i.e., remove ~/.mozilla before testing) and are thus not due to interactions with extensions or any other user customizations. Here is a file I will call A.html that triggers a crash, where everything is in ASCII except that the character X is replaced in the file by some other byte(s): ------cut here to get A.html:----------------------------------------- <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <pre>X</pre> ------cut here-------------------------------------------------------- To see a crash, replace the character X in A.html by any one of these possibilities: * The single byte 0x85 (decimal 133, octal 205). (This is not a legal character in the UTF-8 or ISO-8859-* encodings.) * The single byte 0x92 (decimal 146, octal 222). (This is not a legal character in the UTF-8 or ISO-8859-* encodings.) * The three bytes 0xEF, 0xBF, and 0xBD. (This is the UTF-8 encoding of the Unicode character "REPLACEMENT CHARACTER" (hexadecimal 0xfffd, decimal 65533).) Probably other byte combinations cause a crash; these are just the ones I've seen in real pages on the web. Also, the "pre" element in A.html can be replaced by a "code" element and Firefox will still crash. I am guessing (but have not verified) that what is important here is that the element is one that in the default style will use a monospaced font. To reproduce the bug with A.html, simply put the above text into a file named A.html, replace the X by one of the bytes (or byte sequence) mentioned above, run the command "firefox A.html", and observe a crash. Here is another file I will call B.html that triggers a crash, but only if a certain setting is present in the prefs.js configuration file: ------cut here to get B.html:----------------------------------------- <code>x</code><span></span> ------cut here-------------------------------------------------------- For B.html to cause a crash, the following line must exist in the prefs.js file (which is found in ~/.mozilla/firefox/RANDOMSTRING.PROFILENAME/prefs.js): user_pref("font.name.monospace.x-western", "monospace"); In B.html it is important that the "code" element is displayed at the beginning of the line as putting characters in front of it generally seems to prevent the crash. To reproduce the bug with B.html, simply put the above text into a file named B.html, take the line mentioned above and add it by hand to Firefox's prefs.js file while Firefox is not running, run the command "firefox B.html", and observe a crash. Below are my system details. Firefox is installed with the system-wide USE flags plus "gnome" (i.e., there is the line "www-client/mozilla-firefox gnome" in /etc/portage/package.use). Can someone please help? Gentoo Base System version 1.12.0_pre13 Portage 2.1_pre3-r1 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.8.1-co-0.6.2-pre1 i686) ================================================================= System uname: 2.6.8.1-co-0.6.2-pre1 i686 Intel(R) Pentium(R) M processor 1100MHz dev-lang/python: 2.2.3-r6, 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy distlocks moo sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://gentoo.mirror.solnet.ch http://mir.zyrianes.net/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/ http://ds.thn.htu.se/linux/gentoo" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/extra/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X Xaw3d acl apache2 audiofile bdf bitmap-fonts bonobo bzip2 cairo canvas crypt djvu doc dvi dynagraph eds emacs emacs-w3 emboss escreen esd etwin exif expat fam finger firefox font-server fortran fpx ftp gcj gd gd-external gif glep glitz glut gmp gopher graphviz gs gstreamer gtk gtk2 guile idn imagemagick imlib ipv6 jasper java javascript jbig jpeg latex lcms leim libg++ libwww lua lzw-tiff mad mailwrapper md5sum mmx mng motif mozdevelop mozilla mozsvg mozxmlterm mp3 mpeg ncurses nntp nodrm nptl nsplugin numeric objc ogg oggvorbis opengl pam pam_chroot pam_console pam_timestamp perl png python readline rle samba sdk slang socks5 spell sse ssl svg syslog t1lib tcltk tcpd tetex tiff toolbar truetype truetype-fonts type1-fonts unicode vorbis wmf xinerama xml2 xmms xprint xv zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
By the way, the meta http-equiv line in A.html can be omitted and Firefox will still crash when viewing the file if the following line is in prefs.js: preference: user_pref("intl.charset.default", "UTF-8");
Created attachment 76957 [details] A-1.html: A.html with X replaced by byte 0x85 This is A-1.html, which is the file A.html with X replaced by the single byte 0x85. I'm attaching this file to save people the trouble of figuring out how to input such a file.
Created attachment 76958 [details] A-2.html: A.html with X replaced by byte 0x92 This is A-2.html, which is the file A.html with X replaced by the single byte 0x92. I'm attaching this file to save people the trouble of figuring out how to input such a file.
Created attachment 76959 [details] A-3.html: A.html with X replaced by bytes 0xEF, 0xBF, 0xBD This is A-3.html, which is the file A.html with X replaced by the three bytes 0xEF, 0xBF, and 0xBD. I'm attaching this file to save people the trouble of figuring out how to input such a file.
I found yet another web page that Firefox crashes on, from which I discovered that the character X in A.html can also be replaced by these two possibilities: * The single byte 0xFA (decimal 250). (This is a legal character in any of the ISO-8859-* encodings, but in UTF-8 must be followed by 5 bytes with bit 7 on and bit 6 off.) * The single byte 0xE5 (decimal 229). (This is a legal character in any of the ISO-8859-* encodings, but in UTF-8 must be followed by 2 bytes with bit 7 on and bit 6 off.)
Thanks, but this should be reported upstream (if not done yet).
(In reply to comment #6) > Thanks, but this should be reported upstream (if not done yet). For example, I have no evidence yet that this is not a Gentoo-specific problem due to libraries. Can you at least try to reproduce it? It should be simple to just save one of the three attachments to a file and run Firefox on it. If you can't reproduce it, I doubt upstream could.
if someone could change the content/MIME type of the attachments to "text/html; charset=utf-8", it would be easier to test.
I have tested all three attachments and have not been able to duplicate the segfault. I have even modified the attachments to test different possibilities and have not been able to duplicate the problem.
Comment #9 states: > I have tested all three attachments and have not been able to > duplicate the segfault. I have even modified the attachments to > test different possibilities and have not been able to duplicate the > problem. Thanks very much for trying the files! This helped me understand where to look. On further investigation, I have discovered that if I remove my old ~/.fonts.cache-1 file, the crashes no longer occur. This is looking extremely bizarre now. I have some fonts in subdirectories under ~/.fonts that I disabled by changing the subdirectories' permissions with "chmod ugo-rwx". Strangely, my ~/.fonts.cache-1 lists _only_ these directories and font files _inside_ them. This file was last regenerated on 2005-12-10 but the inaccessible directories had their permissions changed earlier (verified with "ls -lcd"). This is impossible unless the program that last regenerated .fonts.cache-1 was running as root and could bypass my file permissions. I checked the files in my PORT_LOGDIR and there wasn't any emerge running at that particular time on 2005-12-10. Earlier that same day I emerged both mozilla-firefox-1.0.7-r4 and xpdf-3.01-r3, which both use fontconfig, and they might have done something the first time they were run, but neither of them runs as root so I don't see how they could have generated a list of files _inside_ inaccessible directories. Unless fontconfig is doing chmod's to temporarily make directories accessible when it is scanning them? Maybe the design of fontconfig changed to not store anything in ~/.fonts.cache-1 which is stored in ~/.fonts/fonts.cache-1 and it went through ~/.fonts.cache-1 removing all the files that were also listed in ~/.fonts/fonts.cache-1, leaving behind only the files in the inaccessible directories (which were of course not listed in ~/.fonts/fonts.cache-1)? Totally mysterious. Thus, there are two problems: * It is clear that some library (presumably libfontconfig) is wrongly trusting bad data in the ~/.fonts.cache-1 file instead of checking it. The particular problem seems to be that ~/.fonts.cache-1 lists font files that are not actually accessible. (And somehow something changed from Firefox 1.0.7 to Firefox 1.5 such that this bug is now being triggered when it was not before.) * It is utterly bizarre how the bad data in my ~/.fonts.cache-1 file could ever have been generated in the first place! Simply removing ~/.fonts.cache-1 seems to make the the problem go away, but obviously there are still some bugs lurking here.
I've changed the bug summary to mention fontconfig's cache so that if anyone else runs into this problem they will be more likely to find this bug report.
Created attachment 77092 [details] firefox-crash-fonts-snapshot.tar.gz: Bad fontconfig cache files to trigger crash I have added a new attachment firefox-crash-fonts-snapshot.tar.gz that contains additional files needed to reproduce the crash. These files are stripped down to the bare minimum. Here are the instructions for using this attachment to reproduce the crash: 1. Save your ~/.fonts directory by running "mv .fonts{,.save}". 2. Unpack the attachment in your home directory by running "tar xfz firefox-crash-fonts-snapshot.tar.gz". This will create two directories: .fonts and .fonts/old-monospace-disabled. This will also create two files: .fonts.cache-1 and .fonts/fonts.cache-1. Note that there are no actual fonts in this package. 3. Using the attachment A-1.html, run the command "firefox A-1.html". You should now have a crash. Be sure to remove .fonts.cache-1 and restore your old .fonts directory when you are done.
Closing via Anarchy.
