[@ getaddrinfo - PR_GetAddrInfoByName] Crash due to large/strange DNS response from body.imho.ru



10 years ago
7 years ago


(Reporter: zaitcev, Assigned: Wan-Teh Chang)



Firefox Tracking Flags

(Not tracked)


(crash signature, URL)



10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: 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: 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:  

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.

Comment 1

10 years ago
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.


* 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.
Severity: normal → critical
Keywords: crash

Comment 2

10 years ago
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 ?? ()

Very short stack... Isn't it strange?

I forgot to mention that I disabled all add-ons and plugins (e.g. Flash).

Comment 3

10 years ago
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.

Comment 4

10 years ago
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
==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== 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.

Comment 5

10 years ago
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.

Comment 6

10 years ago
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.


10 years ago
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Summary: Random crash at many Russian websites → Crash due to large/strange DNS response from body.imho.ru
Version: unspecified → 1.9.0 Branch

Comment 7

10 years ago
in case you didn't see it, debuginfo-install is your friend if you're on fedora.
Assignee: nobody → wtc
Component: Networking → NSPR
Product: Core → NSPR
QA Contact: networking → nspr
Summary: Crash due to large/strange DNS response from body.imho.ru → [@ getaddrinfo - PR_GetAddrInfoByName] Crash due to large/strange DNS response from body.imho.ru
Version: 1.9.0 Branch → other

Comment 8

10 years ago
Pete, thanks for filing the Fedora Rawhide glibc bug

Marked the bug INVALID.
Last Resolved: 10 years ago
Resolution: --- → INVALID


10 years ago
Crash Signature: [@ getaddrinfo - PR_GetAddrInfoByName]
You need to log in before you can comment on or make changes to this bug.