401500 - crash [@ PR_EnumerateAddrInfo] out of focus (auto-refresh?)

Status: VERIFIED DUPLICATE of bug 337418

(NSPR :: NSPR, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102802 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102802 SeaMonkey/2.0a1pre

SeaMonkey was out of focus (and had been for some time) when suddenly "Crash! Bang! Boom!" Breakpad came up. The only recent "action" that I can imagine was not by me, but by some web page (either tinderbox.mozilla.org or mail.google.com) refreshing itself.

View Breakpad report at: http://crash-stats.mozilla.com/report/index/0c7cdd0f-85b4-11dc-ae01-001a4bd43ef6?date=2007-10-29-00

Reproducible: Didn't try

Actual Results:  
crash

Expected Results:  
no crash

Additional info: Stack of crashing thread

0  	PR_EnumerateAddrInfo  	 mozilla/nsprpub/pr/src/misc/prnetdb.c:2092
1 	nsDNSRecord::GetNextAddr(unsigned short, PRNetAddr*) 	mozilla/netwerk/dns/src/nsDNSService2.cpp:116
2 	nsSocketTransport::RecoverFromError() 	mozilla/netwerk/base/src/nsSocketTransport2.cpp:1231
3 	nsSocketTransport::OnSocketDetached(PRFileDesc*) 	mozilla/netwerk/base/src/nsSocketTransport2.cpp:1548
4 	nsSocketTransportService::DetachSocket(nsSocketTransportService::SocketContext*) 	mozilla/netwerk/base/src/nsSocketTransportService2.cpp:159
5 	nsSocketTransportService::DoPollIteration(int) 	mozilla/netwerk/base/src/nsSocketTransportService2.cpp:649
6 	nsSocketTransportService::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) 	mozilla/netwerk/base/src/nsSocketTransportService2.cpp:491
7 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:477
8 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
9 	nsSocketTransportService::Run() 	mozilla/netwerk/base/src/nsSocketTransportService2.cpp:533
10 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:490
11 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
12 	nsThread::ThreadFunc(void*) 	mozilla/xpcom/threads/nsThread.cpp:254
13 	_pt_root 	mozilla/nsprpub/pr/src/pthreads/ptthread.c:221
14 	libpthread-2.5.so@0x5111

Comment 1

[Tony Mechelynck [:tonymec]]

see also http://crash-stats.mozilla.com/report/list?range_unit=months&query_search=signature&query_type=exact&signature=PR_EnumerateAddrInfo&query=PR_EnumerateAddrInfo&range_value=3

(crash stats for "exactly PR_EnumerateAddrInfo"). The results look suggestive to me.

Comment 2

[timeless]

brother. the problem is related to your network interfaces changing. and it's ancient. it happens to me about 1/2 times when i switch between home/work networks or sleep.

I was certain there was a bug for this, because I complain about it weekly, but i can't find it.

Comment 4

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
> brother. the problem is related to your network interfaces changing. and it's
> ancient. it happens to me about 1/2 times when i switch between home/work
> networks or sleep.

(In reply to comment #3)
> 
> *** This bug has been marked as a duplicate of bug 337418 ***
> 

Hm. That bug's summary says "flaky wifi connection or vpn or laptop sleeping".
- My only network connection (apart from the loopback device) is ADSL-over-Ethernet (i.e., "ifconfig" shows lo, eth0 and dsl0; the latter two are in series). Good old copper cables, no wifi. My ISP disconnects it after 36 hours continuous-on but it hadn't happened recently.
- I don't know what vpn means.
- I have a desktop tower (well, floortop actually) and AFAIK it never goes to sleep. (Sometimes I shut it down but that's different, and I always close all Mozilla apps "cleanly" before starting a shutdown). (And no power failure since long before the latest SeaMonkey restart.)

Timeless, I'll defer to your greater wisdom, though I can't help but wonder.

Comment 5

[timeless]

the stack's definitely one of a family that i get under those circumstances.

i didn't notice the Linux bit, that's different. (for the record, the link you pointed to shows this happens on Linux, Mac OS X, and Windows.)

the real signature is probably:
nsSocketTransport::RecoverFromError
nsSocketTransport::OnSocketDetached

and I wonder if this is a double release. (the refresh could certainly be a bad lifetime.)

Comment 6

[Tony Mechelynck [:tonymec]]

Yes, I noticed the multi-OS-ness. I guess I should have set this bug to OS=All by comment #2.

I also noticed several cases of tinderbox.mozilla.org and mail.google.com (plus about:blank which is harder to explain, and others) among the URLs listed. Gmail and tinderbox are (IIUC) pages which periodicaly auto-refresh forever (well, until stopped by hand or timed out). Among my 33 SeaMonkey tabs, I have 3x tinderbox, 1x gmail; I may also have had spamcop.net (which waits between 5 and 10 seconds then refreshes once and serves a different page).

Comment 7

[Tony Mechelynck [:tonymec]]

(In reply to comment #5)
> the stack's definitely one of a family that i get under those circumstances.
> 
> i didn't notice the Linux bit, that's different. (for the record, the link you
> pointed to shows this happens on Linux, Mac OS X, and Windows.)
> 
> the real signature is probably:
> nsSocketTransport::RecoverFromError
> nsSocketTransport::OnSocketDetached
> 
> and I wonder if this is a double release. (the refresh could certainly be a bad
> lifetime.)
> 

See bug 337418 comment #18 ("nsDNSRecord might get out of sync with nsRecord -> addr_info if...") and notice at #1 in this crash's stack, nsDNSRecord::GetNextAddr

Wan-Teh has a "hunch" that (s)he's on the right track, and so do I.

I'm saying your dupe was "the right thing" => VERIFIED.