102743 - M095 Trunk Crash pressing Back or Forward on O'Reilly website [@ 0x00690073] [@ 0x612e7364][@ 0x6f642e64][@ nsStreamLoader::~nsStreamLoader][@ nsCOMPtr_base::~nsCOMPtr_base]

Status: VERIFIED FIXED

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

Description

[Steve Chapel]

Reproducability: Always

Steps to reproduce:
1. Go to the O'Reilly web site at http://www.oreilly.com/
2. Click on the "Web & Internet" Resource Center in the menu on the left.
3. Click on one of the Web Programming books.
4. Press the Back button

Expected Result: The browser goes back to the previous page.

Actual Result: Crash!

I've reproduced this many times with build 2001100203 on Windows 2000 SP2. Once, the crash happened with the Forward button rather than the Back button. It may be possible that the above steps do not cause the crash reliably, but I was always able to crash Mozilla by hitting Back a few times and Forward a few times repeatedly.

Talkback incidents:
TB36175626Q
TB36172925M
TB36164426K
TB36161816Y
TB36161811Z

Comment 1

[André Schild]

Crashes for me too on W2K build 2001100203

TB36176603K

Comment 2

[Adam Hauner]

WinNT4/2001100203-trunk same, TB36196947E.
Keyword 'crash' should be added... 

Comment 3

[Ashley Bischoff (blog at handcoding.com)]

Adding "crash" keyword, and marking NEW.

-> History:Session for initial triage, pending talkback retrieval

Comment 4

[Asa Dotzler [:asa]]

Adam's talkback:
0x0429f04f
nsStreamLoader::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 166]
nsHttpChannel::Resume
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 1623]
nsRequestObserverProxy::FireEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 266]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072] 

Steve's talkback:

0x00690073
nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 65]
nsStreamLoader::~nsStreamLoader
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.h]
nsStreamLoader::`scalar deleting destructor'
nsStreamLoader::Release
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 97]
SheetLoadData::OnStreamComplete
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 675]
nsStreamLoader::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 138]
nsHttpChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2312]
nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 177]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 457]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1307]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1624]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1642]
WinMainCRTStartup()
KERNEL32.DLL + 0x17d08 (0x77e97d08) 

Comment 5

[Ashley Bischoff (blog at handcoding.com)]

-> Networking: HTTP ?

Comment 6

[Radha on family leave (not reading bugmail)]

seems to be in networking module. cc'ing darin.

Comment 7

[Darin Fisher]

investigating for 0.9.6

Comment 8

[K Carter]

Is this the same crash I get hitting back on washingtonpost.com?  I have
submitted a couple of talkback reports but I don't know their ids.  Perhaps
search for [e-mail].  This is reproducible every time on my Win98SE. 
Go to an article.  Hit Back.  Crash.  I would have thought that this is a pretty
high profile sight to delay a milestone.

Comment 9

[Darin Fisher]

-> me

Comment 10

[Darin Fisher]

i am able to reproduce this crash everytime under linux... investigating.

Comment 11

[Darin Fisher]

in a debug build, i get the following assertion just before the crash:

###!!! ASSERTION: broken loading table: 'oldData == aLoadData', file
nsCSSLoader.cpp, line 722
###!!! Break: at file nsCSSLoader.cpp, line 722

cc'ing hyatt, hoping he may have see a connection between this assertion and
OnStreamComplete crasher.

Comment 12

[Darin Fisher]

this crash seems to happen when we're loading the CSS file from the cache... not
sure how that is related yet.

Comment 13

[Darin Fisher]

also, fwiw, i can't repro this crash on the 0.9.4 branch.

Comment 14

[Darin Fisher]

Attachment: v1.0 patch: seems to prevent the crash, but instead the CSS seems to get all messed up.

Comment 15

[Darin Fisher]

Attachment: the CSS document

Comment 16

[Darin Fisher]

OK.. now i see this error on the console:


WARNING: CSSLoaderImpl::DidLoadStyle: Load of URL
'http://web.oreilly.com/style/style2.css' failed.  Error code: 3, file 
nsCSSLoader.cpp, line 932


and, after closer inspection, ic that this CSS document is fetched via redirect.
so, this must somehow be a regression from my recent checkin to cache redirects.
(see bug 94004)

i think it'll be important to try to fix this for 0.9.5

Comment 17

[Darin Fisher]

Attachment: v1.1 patch: ok, this really fixes the problem!

Comment 18

[Darin Fisher]

Attachment: v1.2 patch: HTTP should be reporting NS_BINDING_REDIRECTED as well

Comment 19

[Darin Fisher]

Attachment: v1.3 patch: minor revisions - make sure libpr0n handles redirects correctly

Comment 20

[Darin Fisher]

hyatt: sorry to bother you with this bug... this is definitely a necko issue.

Comment 21

[Darin Fisher]

cc'ing rpotts for review

Comment 22

[Darin Fisher]

Attachment: patch: expand on comments for NS_BINDING_REDIRECTED

Comment 23

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 24

[Doug Turner (:dougt)]

should NS_BINDING_REDIRECTED be a successful code?

Comment 25

[Matthias Versen [:Matti]]

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

Comment 26

[Darin Fisher]

dougt: well.. perhaps.. but i suspect that would throw off a lot of consumers,
who simply use NS_SUCCEEDED/NS_FAILED macros.

Comment 27

[Gagan]

Comment on attachment 52729 [details] [diff] [review]
v1.3 patch: minor revisions - make sure libpr0n handles redirects correctly

r=gagan

Comment 28

[Darin Fisher]

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

Comment 29

[R.K.Aa.]

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

Comment 30

[Matthias Versen [:Matti]]

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

Comment 31

[Matthias Versen [:Matti]]

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

Comment 32

[rpotts (gone)]

Comment on attachment 52729 [details] [diff] [review]
v1.3 patch: minor revisions - make sure libpr0n handles redirects correctly

sr=[e-mail]

looks good!

Comment 33

[Darin Fisher]

fixed-on-trunk

Comment 34

[greer]

Adding a signature for talkback tracking. I'll keep an eye on this fix.

Comment 35

[R.K.Aa.]

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

Comment 36

[greer]

Not seeing nsStreamLoader::~nsStreamLoader  or  nsStreamLoader::OnDataAvailable
signatures in Trunk builds after 2001101806. Marking VERIFIED.

Comment 37

[greer]

jsut a change to the summary needed for talkback

Comment 38

[greer]

Adding the signature that talkback is looking for.

Comment 39

[Matthias Versen [:Matti]]

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

Comment 40

[Diego Biurrun]

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

Comment 41

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 42

[greer]

Copying summary info from dupes for Talkback tracking.

Comment 43

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 44

[R.K.Aa.]

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

Comment 45

[R.K.Aa.]

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