190001 - crashes [@ nsHttpConnection::CloseTransaction]

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This looks like a regression from bug 176919 based on when it started showing up
in talkback.

nsHttpConnection::CloseTransaction   13 
BBID range: 16335992 - 16415669
Min/Max Seconds since last crash: 47 - 31898
Min/Max Runtime: 848 - 31898
Crash data range: 2003-01-18 to 2003-01-20
Build ID range: 2003011804 to 2003012008
Keyword List : 
Stack Trace: 

	 nsHttpConnection::CloseTransaction
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp 
line 452]
	 nsHttpConnectionMgr::OnMsgCancelTransaction
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp 
line 685]
	 nsHttpConnectionMgr::OnSocketEvent
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp 
line 755]
	 nsSocketTransportService::Run
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsSocketTransportService2.cpp 
line 540]
 
 	Source File :
c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp line
: 452
     (16404741)	URL: monster.com
     (16402407)	URL: monster.com
     (16398762)	URL: monster.com
     (16398762)	Comments: marking messages junk  
     (16354212)	Comments: looking for a mail in the income folder
     (16335992)	URL: tfproject.org
     (16335992)	Comments: Changing forums.

Comment 1

[Darin Fisher]

this is definitely fallout from bug 176919.  investigating...

Comment 2

[Darin Fisher]

it would appear that we are in a situation where the nsHttpTransaction is
holding the last reference to the nsHttpConnection.  nsHttpTransaction::Close
releases the transaction's ownership of the connection, breaking the reference
cycle between the two.  after calling Close on its transaction, the connection
releases its reference to the transaction.  it would seem that the crash occurs
while trying to call mTransaction->Release() on line 452.  by design, this
problem should be avoided by having the connection manager own a reference to
all connections all the time.  there must be race somewhere.  hmm...

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The line numbers in Windows talkback stacks are usually off by one.  It's
probably crashing on mTransaction->Close(reason), although looking at the
disassembly (and registers) will allow you to tell for sure.

Comment 4

[R.K.Aa.]

Crashes on Linux too.

#0  0x408cf5f8 in nsHttpConnection::CloseTransaction(nsAHttpTransaction*,
unsigned) () from libnecko.so
#1  0x408d15a2 in
nsHttpConnectionMgr::OnMsgCancelTransaction(nsHttpTransaction*, unsigned) ()
   from libnecko.so
#2  0x408d1883 in nsHttpConnectionMgr::OnSocketEvent(unsigned, unsigned, void*)
() from libnecko.so
#3  0x408a7002 in nsSocketTransportService::Run() () from libnecko.so
#4  0x40544dfd in nsThread::Main(void*) () from libxpcom.so
#5  0x400b04ed in _pt_root () from libnspr4.so
#6  0x400da981 in pthread_start_thread () from /lib/i686/libpthread.so.0
#7  0x400daa85 in pthread_start_thread_event () from /lib/i686/libpthread.so.0
(gdb)

Comment 5

[Darin Fisher]

hmm... the last instance of this crash was on the 21st.  i wonder if this crash
isn't somehow related to the pipe corruption bug (bug 189689).  i doubt it, but
maybe.

Comment 6

[R.K.Aa.]

stack in comment 4 was from a Linux trunk CVS build from today

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

There are 2 reports in talkback from the 22d.  It does seem to be less frequent,
though.

Comment 8

[Darin Fisher]

i'm starting to suspect that this might be a pipelining specific crash.

R.K.Aa: did you have pipelining enabled when you hit this crash?

Comment 9

[R.K.Aa.]

to comment 8: Yes.

Comment 10

[Jay Patel [:jay]]

According to Talkback data, there haven't been any crashes submitted since 1/22
Trunk builds.  Is anyone still seeing this?  R.K.Aa:  Are you still able to
crash with the latest Trunk builds?

Comment 11

[R.K.Aa.]

to comment 10: Dunno.
I caught the crash accidentally when trying to get a stack on another crasher.
I don't know what i did to provoke it.

Comment 12

[Jan Carpenter]

There are 5 incidents reported between the 27th and 28th.  One from build
NetscapeMozillaTrunkLinuxIntel2003012722  and 4 from build
NetscapeMozillaTrunkWin322003012508 

and 43 crashes on the topcrash report.  
COMMENTS/URLs:
    (16553996)	Comments: reading mail  
     (16535109)	Comments: Closing tabs I'd finished with........
     (16482155)	Comments: just closed a browser window
     (16472275)	URL: www.scheissndreck.de
     (16470405)	URL: www.scheissndreck.de
     (16470405)	Comments: NOthing
     (16446959)	Comments: had several tabs opened. HTTP Pipelining was enabled
     (16428284)	URL: www.interdiscount.ch
     (16404741)	URL: monster.com
     (16402407)	URL: monster.com
     (16398762)	URL: monster.com
     (16398762)	Comments: marking messages junk  
     (16354212)	Comments: looking for a mail in the income folder
     (16562761)	URL: www.hani.co.kr
     (16450769)	Comments: Wow  even reading about the spellchecker is crashing
moz now. I was reading a mail on the spellchecker channel  and ......
     (16335992)	URL: tfproject.org
     (16335992)	Comments: Changing forums.
 

Comment 13

[Darin Fisher]

ok, i was able to repro this by doing the following:

1- enable pipelining (not sure if this matters yet)
2- load a slow page with lots of images
3- press back/forward very quickly

i captured a HTTP log, which will hopefully help pinpoint the problem.

Comment 14

[Darin Fisher]

Attachment: v1 patch

turns out that if a transaction is canceled on the UI thread while it is being
restarted on the socket thread, we can get into a situation where the
transaction cancelation is processed first followed by a dispatch of the
transaction.  the subsequent dispatch is way wrong and ends up causing this
crash.	pipelining makes this crash occur more often, but it should be possible
to trigger it while pipelining is disabled.

Comment 15

[Jay Patel [:jay]]

Adding testcase keyword since Darin found reproducible steps and making this
topcrash+.

Comment 16

[Darin Fisher]

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

simple fix for this nasty back/forward crash.

Comment 17

[Darin Fisher]

fixed-on-trunk

Comment 18

[Darin Fisher]

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

Comment 19

[benc]

VERIFIED:

darin, do you have a specific page or connection type you want me to use (as
described in "2- load a slow page with lots of images") ?

If so I'll make sure to look specifically at that situation.

I break ongoing transfers w/ back a lot as part of my general surfing style, and
I have not seen this problem in the ~1.4a and ~1.4b testing I've been doing.

Comment 20

[Darin Fisher]

images.google.com is usually a good source since it normally takes a little
while before all the images load.