User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/2008072301 Fedora/3.0.1-1.fc10 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/2008072301 Fedora/3.0.1-1.fc10 Firefox/3.0.1 Firefox crashes with signal 11 on a large number of Russian websites. On most, like odnoklassniki.ru, the crash does not happen every time. So, I suspect a rogue ad. The URL at rian.ru seems to crash every time reliably, at the time of posting. When using the mozilla.org version of Firefox, I can see a large part of the page rendered. Reproducible: Always Steps to Reproduce: 1. Visit the URL Actual Results: Crash Expected Results: No crash I tested this with the Mozilla-built Firefox 3.0.1, but it seems no different from what Fedora builds. It is possible that Fedora built a bad library, like Pango, or libjpeg. But I don't know how to identify the crash reason, so I'm looking for a help here.
It looks like you're using a 64-bit version of Firefox. Based on reading bug 385398 I think Firefox's crash reporter is disabled for 64-bit builds. There are a few directions you can go: * Try to identify the crash by running Firefox under gdb. Run "firefox -g", type "r" at the gdb prompt to run Firefox, and type "bt" at the gdb prompt after Firefox crashes to get a stack trace. Hopefully we ship the 64-bit versions with enough symbols (e.g. function names) for the stack trace shown by gdb to be useful. If not, you may have to build Firefox yourself, which luckily is pretty easy on Linux. * Try a 32-bit version of Firefox and use Firefox's crash reporter. Then load about:crashes and click the link to the stack trace for your crash. Once you have a stack trace, attach it here and search Bugzilla for the name of the function at the top of the stack. Alternatively, * Try to identify what part of the page is responsible for the crash. Save it using |wget| or another web browser and strip it down to the smallest page that crashes Firefox.
Running "firefox -g" was a good idea, thanks. Here's how it looks at Mozilla build: [New LWP 15805] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 15805] 0x422591a1 in memcpy () from /lib/libc.so.6 Missing separate debuginfos, use: debuginfo-install gamin.i386 libXScrnSaver.i386 libXinerama.i386 scim-bridge.i386 (gdb) where #0 0x422591a1 in memcpy () from /lib/libc.so.6 #1 0xf6f61bed in ?? () from /lib/libnss_dns.so.2 #2 0xf6f62056 in _nss_dns_gethostbyname4_r () from /lib/libnss_dns.so.2 #3 0x422a7673 in ?? () from /lib/libc.so.6 #4 0x00000000 in ?? () (gdb) Very short stack... Isn't it strange? I forgot to mention that I disabled all add-ons and plugins (e.g. Flash).
That is certainly a strange stack. Based on seeing "0x00000000" at the bottom, I'm guessing the stack is corrupt by the time Firefox crashes. I think a buffer overflow of a stack variable can cause that to happen. You can try "firefox -g -d valgrind", but valgrind is isn't good at detecting stack corruption, so it might tell you the same thing gdb did.
Actually valgrind seems to work, thanks for the hint. The stack is short because apparently it's on a helper thread: ==4082== Thread 11: ==4082== Source and destination overlap in memcpy(0x16629A94, 0x16628D9A, 50049) ==4082== at 0x4A07FCA: memcpy (mc_replace_strmem.c:402) ==4082== by 0xB4C4DDF: (within /lib64/libnss_dns-2.8.90.so) ==4082== by 0xB4C522C: _nss_dns_gethostbyname4_r (in /lib64/libnss_dns-2.8.90 .so) ==4082== by 0x3A7AECFEFD: (within /lib64/libc-2.8.90.so) ==4082== by 0x3A7AED1CBC: getaddrinfo (in /lib64/libc-2.8.90.so) ==4082== by 0x3A8A61D577: PR_GetAddrInfoByName (in /lib64/libnspr4.so) ==4082== by 0x3A8AE905B7: (within /usr/lib64/xulrunner-1.9/libxul.so) ==4082== by 0x3A8A629AA2: (within /lib64/libnspr4.so) ==4082== by 0x3A7BA07409: (within /lib64/libpthread-2.8.90.so) ==4082== by 0x3A7AEE8DBC: clone (in /lib64/libc-2.8.90.so) ==4082== ==4082== ERROR SUMMARY: 4234 errors from 38 contexts (suppressed: 83 from 1) ==4082== malloc/free: in use at exit: 38,821,370 bytes in 175,537 blocks. ==4082== malloc/free: 1,665,276 allocs, 1,489,739 frees, 945,252,276 bytes alloc 50049 in memcpy in a nameserver? That's a lot of data to move.
I filed our own bug, against glibc. This is because the same Firefox seems to work on Fedora 9 and Fedora 8. It must be something in libraries we ship in Fedora Rawhide. https://bugzilla.redhat.com/show_bug.cgi?id=456810
So, the problem turned out to be body.imho.ru. Accessing http://body.imho.ru/ crashes the browser immediately. Mozilla people, please free to close as appropriate. If not, I'll close once the glibc folks found the cause.
in case you didn't see it, debuginfo-install is your friend if you're on fedora.
Pete, thanks for filing the Fedora Rawhide glibc bug https://bugzilla.redhat.com/show_bug.cgi?id=456810 Marked the bug INVALID.