221491 - crash [@ nsHostResolver::GetHostToLookup]

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[timeless]

2003100304
Stack Trace:
nsHostResolver::GetHostToLookup 
[c:/builds/seamonkey/mozilla/netwerk/dns/src/nsHostResolver.cpp line 
497] nsHostResolver::ThreadFunc 
[c:/builds/seamonkey/mozilla/netwerk/dns/src/nsHostResolver.cpp line 
571] _PR_NativeRunThread 
[c:/builds/seamonkey/mozilla/nsprpub/pr/src/threads/combined/pruthr.c 
line 455] msvcrt.dll + 0x27fb8 (0x77c37fb8) kernel32.dll + 0x1d33b 
(0x77e7d33b)
   Source File :
   c:/builds/seamonkey/mozilla/netwerk/dns/src/nsHostResolver.cpp 
line : 497 (24120859) Comments: I didn't touch anything. I went to 
bed and when I checked on Mozilla in the morning it was dead :(
(24108960) Comments: I literally touched nothing. I went to watch TV 
came back and Mozilla was dead. (24097637) URL: 
http://www.palminfocenter.com/ (24097637) Comments: I'm not sure what 
happened. I was reading a page perhaps using the scroll wheel and 
Mozilla died. (24042682) Comments: I went for a meeting came back and 
Mozilla was dead. 

--this bug is filed based on talkback data, don't come to me asking
for steps to reproduce or contacts--

Comment 1

[Darin Fisher]

not much info there :(

Comment 2

[Darin Fisher]

i hear through the grapevine that most talkback reports are for WINNT 5.0 and 5.1
... and the problem is that EIP is NULL or garbage in all cases.

it also looks like some moz regulars are seeing this:

  [e-mail]
  [e-mail]
  [e-mail]

there is also one linux report: also with a bogus EIP value.  so, this problem
is cross-platform actually.

alex, henrik, ere: can any of you hit this crash in a debug build? 

Comment 3

[Darin Fisher]

in this crash and in the one from bug 221496, mPendingQ is involved.  i wonder
if we aren't somehow ending up with some bogus data on that.  the
PR_REMOVE_AND_INIT_LINK is probably trashing EIP when it modifies the links
pointed to by "next" and "prev".  hmm...

Comment 4

[Darin Fisher]

i've been experiencing a crash under linux... twice today already. 
unfortunately, i haven't been lucky enough to have it happen while running in
GDB... nor did i have core dumps enabled :(

Comment 5

[Ashley Bischoff (blog at handcoding.com)]

Darin: Though this was a persistent problem for me with builds from early
October, I'm running 2003100304 at the moment and it's been fine (continuous
uptime since Saturday).

I'll update to the latest nightly tomorrow (Wednesday) and, if the bug reoccurs,
I'd be happy to try a debug build.

(PS: Thanx for CCing me on this one -- I've been trawling through Bugzilla over
the past few days trying to find it.)

Comment 6

[Henrik Gemal]

When I leave my Mozilla alone it crashes. If I just uses it I seldom crash. It
seems like Mozilla needs attention...:)
I've also turned on IPv6 for my WinXP. Not sure it matters.
Currently I dont have a debug build, but if someone can put a debug build
somewhere I can download it I'll be happy to test run it.
Sometimes it could be nice if mozilla.org published nightly debug builds.

Comment 7

[Ere Maijala (slow)]

For me it has been usually biff or something else happening in the background
and I've found that Mozilla has crashed when I come back to my computer while
being away for a while. I can try running in debugger, but it happens rarely
enough to be difficult to reproduce there. I haven't seen it in 2003100204, at
least not yet.

Comment 8

[Ashley Bischoff (blog at handcoding.com)]

Darin: I just sent in another talkback (TB24303720X) that I'm guessing might
apply to this bug. 

So... where can I download a debug build for win32?

Comment 9

[Ashley Bischoff (blog at handcoding.com)]

Darin: I forgot to mention in comment #8 that the crash was with 2003101004.

Comment 10

[Darin Fisher]

alex: there aren't any debug builds available for download, but i might be able
to make one available for you to test.  i do appreciate your offer to help out
with this!

Comment 11

[Matthias Versen [:Matti]]

I could provide a debug build but why do you need it ?
(Assertions or a NSPR LOG that only works in a debug ?)

A stack trace wouldn't work without the source files and a debugger.

Comment 12

[Ashley Bischoff (blog at handcoding.com)]

Darin: I'd be happy to try a debug build, but would that still be applicable
considering Matti's comments?

Comment 13

[Darin Fisher]

matti is right... under windows it doesn't do you much good if you don't have a
debugger and the source tree :(

just keep submitting talkback reports... maybe one of them will tell us
something new.  also, if you have time you could maybe see if either of these
preferences has any influence over the frequency of this crash:

  user_pref("network.dnsCacheEntries", 50);     // number of DNS cache entries
  user_pref("network.dnsCacheExpiration", 300); // measured in seconds

for example if you set dnsCacheExpiration to 0 or dnsCacheEntries to 0, then you
will force mozilla to ask the operating system each and every time it makes a
DNS request.  this will put more stress on the DNS threads, and should help
increase the likelihood of this crash.  of course, without a debugging
environment and without the ability to confirm that a talkback report
corresponds to this bug, there isn't that much to be gained from this exercise.
 unfortunately, i can only get access to talkback info indirectly by bothering
someone still at AOL :(

Comment 14

[Darin Fisher]

actually, it might be better to not set dnsCacheEntries and dnsCacheExpiration
to zero because doing so ignores the fact that this crash could be related to
cache churn (i.e., cache entries being evicted).  it might be better to set
these values to something small, but non-zero.

Comment 15

[Ere Maijala (slow)]

One more: TB24446863K.

Comment 16

[Ere Maijala (slow)]

This could be completely unrelated, but I just got an abnormal program
termination with a debug build. Call stack:

  ntdll.dll!77f75a58()  
  nspr4.dll!PR_Assert(const char * s=0x30031a98, const char * file=0x30031a0c,
int ln=213)  Line 515  C
  nspr4.dll!PR_DestroyLock(PRLock * lock=0x0addd688)  Line 213 + 0x26 C
  nspr4.dll!PR_DestroyMonitor(PRMonitor * mon=0x0b1e7368)  Line 82 + 0xe  C
  msgimap.dll!nsImapProtocol::~nsImapProtocol()  Line 552 + 0x10  C++
  msgimap.dll!nsImapProtocol::`scalar deleting destructor'(unsigned int
__flags=1)  + 0xf C++
  msgimap.dll!nsImapProtocol::Release()  Line 296 + 0x93  C++
  xpcom.dll!nsCOMPtr<nsIRunnable>::assign_assuming_AddRef(nsIRunnable *
newPtr=0x00000000)  Line 462  C++
  xpcom.dll!nsCOMPtr<nsIRunnable>::assign_with_AddRef(nsISupports *
rawPtr=0x00000000)  Line 964  C++
  xpcom.dll!nsCOMPtr<nsIRunnable>::operator=(nsIRunnable * rhs=0x00000000)  Line
575  C++
  xpcom.dll!nsThread::Main(void * arg=0x0b60ac00)  Line 135 C++
  nspr4.dll!_PR_NativeRunThread(void * arg=0x0b66e658)  Line 433 + 0xd  C
  MSVCRTD.DLL!_threadstartex(void * ptd=0x04109b60)  Line 212 + 0xd C
  kernel32.dll!77e7d33b()   

Just before that I got this assertion:

###!!! ASSERTION: move/copy already in progress: '!m_copyState', file c:/mozilla
_source/mozilla/mailnews/imap/src/nsImapMailFolder.cpp, line 6551

Comment 17

[timeless]

ere: well, that's familiar to me, since it too was filed by me, bug 183497.
(it doesn't relate to this bug)

Comment 18

[Ashley Bischoff (blog at handcoding.com)]

Darin: In terms of comment #14, how low should I set dnsCacheEntries and
dnsCacheExpiration? I know they shouldn't be zero, but what values would be
better to try?

Comment 19

[Darin Fisher]

Attachment: v1 patch

i think i found a sequence of steps that could lead to this crash:

(1) resolve xxx => adds xxx to pending queue 
(2) detach callback for xxx
(3) resolve xxx again => adds xxx to pending queue again because xxx has no
existing callback (which i wrongly assumed meant that the record was not being
resolved)
(4) now context switch and process pending queue... disaster strikes at some
point since xxx is on the pending queue in two places!

solution: add a "resolving" flag to each host record.  this allows us to do
away with the screwy "resolve if no one else is listening for a callback
check."

i think this should fix this crash and the other one in MoveCList.

i've also fixed a bug with the PR_WaitCondVar timeout stuff.  it basically was
never recycling the thread.  we want to recycle the idle DNS thread after the
timeout.  this is especially important on systems with GLIBC because GLIBC will
reread /etc/resolv.conf for each spawned thread.  past experience suggests that
this technique helps mozilla appear to respond to modified /etc/resolv.conf
automagically.

Comment 20

[Darin Fisher]

*** Bug 221496 has been marked as a duplicate of this bug. ***

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 134124 [details] [diff] [review]
v1 patch

>+    //--
>+    PR_Sleep(PR_SecondsToInterval(5));
>+    //--
>+

Get rid of that, and sr=bzbarsky

Comment 22

[Darin Fisher]

might be good to get this patch in to 1.6 alpha to cut down on alpha topcrashes.

Comment 23

[Darin Fisher]

fixed-on-trunk ... hope it does the trick! :-)

Comment 24

[benc]

V:
Comments in the CList bug said this is not topcrash anymore.