Checking links sometimes crashes, sometimes succeeds wrongly

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
P2
major
RESOLVED WORKSFORME
16 years ago
16 years ago

People

(Reporter: Akkana Peck, Assigned: Darin Fisher)

Tracking

(Blocks: 1 bug, {crash})

Trunk
mozilla0.9.8
x86
Linux
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
I'm suddenly getting flaky returns using nsURIChecker, which used to work fine.
 Sometimes it crashes in asyncOpen on a valid url; if it doesn't crash, then
when checking http://www.mozilla.org/nonexistant.html, it calls OnStartRequest
with an http request status of 200 (should be 404 or something similar).

This possibly should be two separate bugs; let me know if I should split them
up.  Send it back to me if I'm doing something wrong in nsURIChecker (but this
used to work and the nsURIChecker code hasn't changed).

To reproduce: use a build from this afternoon or later (I checked in some fixes
to ComposerCommands.js), edit a file which contains links to
http://www.mozilla.org/nonexistant.html
http://www.mozilla.org/unix/customizing.html
(I'll attach the document I've been using so you can just edit that),
then do Debug->Check Links.

When it crashes, here's the stack trace:
#0  0x405868c1 in kill () at ../../../dist/include/string/nsAFlatString.h:68
#1  0x40299aa7 in pthread_setconcurrency () at eval.c:41
#2  0x4029bd31 in sem_destroy () at eval.c:41
#3  0x402980f4 in pthread_mutex_unlock () at eval.c:41
#4  0x40264923 in PR_Unlock (lock=0x8642f8c) at ptsynch.c:210
#5  0x40265340 in PR_ExitMonitor (mon=0x8642f88) at ptsynch.c:535
#6  0x408ce623 in nsSocketTransport::AsyncRead (this=0x8675198, 
    aListener=0x8663974, aContext=0x0, aOffset=0, aCount=4294967295, aFlags=3, 
    aRequest=0xbfffc7fc) at ../../../dist/include/xpcom/nsAutoLock.h:209
#7  0x40918215 in nsHttpConnection::ActivateConnection (this=0x8663970)
    at ../../../../dist/include/xpcom/nsCOMPtr.h:650
#8  0x40917544 in nsHttpConnection::SetTransaction (this=0x8663970, 
    transaction=0x86efb88, caps=1 '\001') at nsHttpConnection.cpp:118
#9  0x409120f9 in nsHttpHandler::InitiateTransaction_Locked (this=0x815e300, 
    trans=0x86efb88, ci=0x86895c8, failIfBusy=0) at nsHttpTransaction.h:72
#10 0x4090fdc7 in nsHttpHandler::InitiateTransaction (this=0x815e300, 
    trans=0x86efb88, ci=0x86895c8) at nsHttpHandler.cpp:393
#11 0x4091f582 in nsHttpChannel::Connect (this=0x86dfb20, firstTime=1)
    at nsHttpHandler.h:77
#12 0x4092a7aa in nsHttpChannel::AsyncOpen (this=0x86dfb20, 
    listener=0x86e0f18, context=0x0) at nsHttpChannel.cpp:1955
#13 0x408daed0 in nsURIChecker::AsyncCheckURI (this=0x86e0f10, 
    aURI=0x86e0540 "http://www.mozilla.org/unix/customizing.html", 
    aObserver=0x86d96b8, aCtxt=0x0, aRequestRet=0xbfffcd40)
    at ../../../dist/include/xpcom/nsCOMPtr.h:650

[ ... ]
(Reporter)

Comment 1

16 years ago
Created attachment 59961 [details]
Edit this file, then Debug->Check Links

Comment 2

16 years ago
http
Assignee: neeti → darin
Component: Networking → Networking: HTTP
QA Contact: benc → tever

Updated

16 years ago
Blocks: 91388

Comment 3

16 years ago
oops! wrong dependency bug
Blocks: 108296
No longer blocks: 91388

Updated

16 years ago
Blocks: 114926
(Assignee)

Comment 4

16 years ago
-> 0.9.8
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: crash
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
(Reporter)

Updated

16 years ago
Depends on: 115140
(Reporter)

Comment 5

16 years ago
I wonder if we might have been trying to access the wrong uri at some point? 
The uri ref object needs the patch in bug 115318, and after applying that patch,
I don't seem to be seeing the netlib crashes any more (in the few tests I've
run).  I'd be interested to hear whether anyone else sees them after applying
that patch.
(Assignee)

Comment 6

16 years ago
akk: can we close this bug?
(Reporter)

Comment 7

16 years ago
I don't seem to be seeing it any more.  Charley, is it working for you with the
patch in bug 115318?  If so, we can close this bug, and can I ask you two for a
review/sr for the 115318 patch?
(Assignee)

Comment 8

16 years ago
marking WORKSFORME per akkana's comments.  please reopen if the problem re-
appears.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.