Closed
Bug 52397
Opened 24 years ago
Closed 24 years ago
N601 Crash #8 [@ nsHTTPServerListener::OnDataAvailable]
Categories
(Core :: Networking: HTTP, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla0.8
People
(Reporter: jwbaker, Assigned: darin.moz)
References
()
Details
(Keywords: crash, top100, topcrash, Whiteboard: [dogfood+])
Crash Data
Attachments
(1 file)
Linux debug build pulled 2000-09-12-19. After clicking on a link, Moz crashes.
To reproduce:
1) Start Moz
2) http://www.mozilla.org/quality/help/bugzilla-helper.html
3) click "Create a Bugzilla account"
4) click "Yes" for the cookie prompts, if any
Mozilla either crashes with this stack:
#0 0x409b671f in nsHTTPServerListener::OnDataAvailable (this=0x8578ac0,
channel=0x85c5464, context=0x869fc90, i_pStream=0x8578b78,
i_SourceOffset=0, i_Length=58) at nsHTTPResponseListener.cpp:467
#1 0x4094d574 in nsOnDataAvailableEvent::HandleEvent (this=0x86be8f8)
at nsAsyncStreamListener.cpp:400
#2 0x4094c7e7 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x86be920)
at nsAsyncStreamListener.cpp:97
#3 0x401228bf in PL_HandleEvent (self=0x86be920) at plevent.c:575
#4 0x401226d1 in PL_ProcessPendingEvents (self=0x809dad0) at plevent.c:508
#5 0x40124511 in nsEventQueueImpl::ProcessPendingEvents (this=0x809daa8)
at nsEventQueue.cpp:356
#6 0x40c1b290 in event_processor_callback (data=0x809daa8, source=6,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#7 0x40c1aecf in our_gdk_io_invoke (source=0x8180390, condition=G_IO_IN,
data=0x8164bd8) at nsAppShell.cpp:58
#8 0x40dd720e in g_io_unix_dispatch (source_data=0x81803a8,
current_time=0xbffff6a0, user_data=0x8164bd8) at giounix.c:135
#9 0x40dd8717 in g_main_dispatch (dispatch_time=0xbffff6a0) at gmain.c:656
#10 0x40dd8cdb in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#11 0x40dd8e59 in g_main_run (loop=0x8167438) at gmain.c:935
#12 0x40d07069 in gtk_main () at gtkmain.c:476
#13 0x40c1b979 in nsAppShell::Run (this=0x809ba30) at nsAppShell.cpp:335
#14 0x4069a50c in nsAppShellService::Run (this=0x809e6c8)
at nsAppShellService.cpp:378
#15 0x80553e0 in main1 (argc=2, argv=0xbffff984, nativeApp=0x0)
at nsAppRunner.cpp:958
#16 0x8055ab4 in main (argc=2, argv=0xbffff984) at nsAppRunner.cpp:1139
#17 0x403712e7 in __libc_start_main () from /lib/libc.so.6
Or asserts this assertion:
###!!! ASSERTION: NS_ENSURE_TRUE(aListener) failed: 'aListener', file
nsHTTPChannel.cpp, line 1231
###!!! Break: at file nsHTTPChannel.cpp, line 1231
Reporter | ||
Comment 1•24 years ago
|
||
Making visible.
Gagan? What's this new ApplyConversion stuff in the listener (it crashes there)?
Did somebody checked in smth. big recetly?
Comment 6•24 years ago
|
||
gagan, what is your fix? I would like to apply your fix to bug 52667 which I
suspect might be a dup of this bug.
Also, what is the hold-up with checking in the fix?
Comment 7•24 years ago
|
||
This might be a dup of 52667. Would like to try out gagan's fix for that bug to
see if it fixes this one.
Comment 8•24 years ago
|
||
Oops, ignore the second of my two comments above. That one was meant to be put
in the other bug report.
Comment 9•24 years ago
|
||
Another place that seems to duplicate this bug is http://www.maximumlinux.com;
just go to the main page, then go to any other page. The "onUnload" event
handler opens a new window, and this causes the crash; loading the page
by entering it into the URL bar works just fine. Oddly, if Mozilla can't
load the new page, it just freezes, instead of crashing.
Comment 10•24 years ago
|
||
I saved the MaximumLinux testcase to my local filesystem, and tested it off
of there. With this setup, Mozilla crashes regardless of whether or not
the page for the popup-window can be loaded. It gives the following
assesrtions and stack trace:
###!!! ASSERTION: don't do that: 'Not Reached', file
nsChromeProtocolHandler.cpp, line 434
###!!! Break: at file nsChromeProtocolHandler.cpp, line 434
we don't handle eBorderStyle_close yet... please fix me
WEBSHELL+ = 5
###!!! ASSERTION: no script global object: 'mScriptGlobalObject != nsnull', file
nsXULDocument.cpp, line 5635
###!!! Break: at file nsXULDocument.cpp, line 5635
###!!! ASSERTION: don't do that: 'Not Reached', file
nsChromeProtocolHandler.cpp, line 434
###!!! Break: at file nsChromeProtocolHandler.cpp, line 434
Document file:///usr/home/matt/develop/mozilla/notes/ loaded successfully
WEBSHELL+ = 6
Enabling Quirk StyleSheet
Setting content window
*** Pulling out the charset
JavaScript strict warning:
chrome://navigator/content/navigator.js line 433: reference to undefined
property window.arguments
JavaScript strict warning:
chrome://navigator/content/navigator.js line 456: reference to undefined
property window.arguments
in SetSecurityButton
Program received signal SIGSEGV, Segmentation fault.
0x2b6e2b4b in nsCOMPtr<nsIStreamListener>::assign_assuming_AddRef (
this=0x8cee370, newPtr=0x8ba7e00) at ../../dist/include/nsCOMPtr.h:471
471 NSCAP_RELEASE(this, oldPtr);
(gdb) where
#0 0x2b6e2b4b in nsCOMPtr<nsIStreamListener>::assign_assuming_AddRef (
this=0x8cee370, newPtr=0x8ba7e00) at ../../dist/include/nsCOMPtr.h:471
#1 0x2b6e2bd5 in nsCOMPtr<nsIStreamListener>::assign_with_AddRef (
this=0x8cee370, rawPtr=0x8ba7e00) at ../../dist/include/nsCOMPtr.h:848
#2 0x2b6e4709 in nsCOMPtr<nsIStreamListener>::operator= (this=0x8cee370,
rhs=0x8ba7e00) at ../../dist/include/nsCOMPtr.h:583
#3 0x2b6d5170 in nsDocumentOpenInfo::RetargetOutput (this=0x8cee360,
aChannel=0x8cac710,
aSrcContentType=0x8927420 "application/http-index-format",
aOutContentType=0x0, aStreamListener=0x8ba7e00) at nsURILoader.cpp:453
#4 0x2b6d4bd6 in nsDocumentOpenInfo::DispatchContent (this=0x8cee360,
aChannel=0x8cac710, aCtxt=0x0) at nsURILoader.cpp:391
#5 0x2b6d3e45 in nsDocumentOpenInfo::OnStartRequest (this=0x8cee360,
aChannel=0x8cac710, aCtxt=0x0) at nsURILoader.cpp:233
#6 0x2b4f90a0 in nsFileChannel::OnStartRequest (this=0x8cac710,
transportChannel=0x8804050, context=0x0) at nsFileChannel.cpp:633
#7 0x2b47d964 in nsOnStartRequestEvent::HandleEvent (this=0x892b220)
at nsAsyncStreamListener.cpp:210
#8 0x2b47d1c5 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x8b8de90)
at nsAsyncStreamListener.cpp:97
#9 0x2abd7b11 in PL_HandleEvent (self=0x8b8de90) at plevent.c:575
#10 0x2abd7900 in PL_ProcessPendingEvents (self=0x80ab730) at plevent.c:508
#11 0x2abd997e in nsEventQueueImpl::ProcessPendingEvents (this=0x80ab708)
at nsEventQueue.cpp:356
#12 0x2b761a7b in event_processor_callback (data=0x80ab708, source=8,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#13 0x2b761665 in our_gdk_io_invoke (source=0x821f988, condition=G_IO_IN,
data=0x83824d0) at nsAppShell.cpp:58
#14 0x2b93f8da in g_io_unix_dispatch ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#15 0x2b940f96 in g_main_dispatch ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#16 0x2b941561 in g_main_iterate ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#17 0x2b941701 in g_main_run ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#18 0x2b862fdc in gtk_main ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#19 0x2b7621fa in nsAppShell::Run (this=0x810fa30) at nsAppShell.cpp:335
#20 0x2b2141be in nsAppShellService::Run (this=0x8108eb0)
at nsAppShellService.cpp:407
#21 0x8055b1e in main1 (argc=1, argv=0x7ffff494, nativeApp=0x0)
at nsAppRunner.cpp:958
#22 0x8056291 in main (argc=1, argv=0x7ffff494) at nsAppRunner.cpp:1139
Comment 11•24 years ago
|
||
This crash made it to the talkback topcrash list today, adding topcrash and [@
nsHTTPServerListener::OnDataAvailable] for topcrash tracking.
Keywords: topcrash
Summary: Crashing in nsHTTPServerListener::OnDataAvailable → Crashing in [@ nsHTTPServerListener::OnDataAvailable]
Comment 13•24 years ago
|
||
Not holding PR3 for this change. If there's a super-safe patch you have to fix
the top crasher for PR3, please bring to PDT, but otherwise, we can wait for
RTM. Marking nsbeta3- and adding rtm nomination.
Keywords: rtm
Whiteboard: [nsbeta3+] → [nsbeta3-]
Reporter | ||
Comment 14•24 years ago
|
||
Not holding for topcrash? This crash makes mozilla essentially unusable for my
day-to-day needs. I have stopped using Mozilla because of this crash.
Comment 15•24 years ago
|
||
Comment 16•24 years ago
|
||
Ooops, the bug is still there; sorry. I'd found this new testcase:
1) Go to http://www.druglibrary.org/frames2/drugsense.htm
2) Click on the link there
And it was consistently crashing with the stacktrace for this bug. The
crash went away for a while, then came back.
Interestingly, if you you go directly to the page linked to in the testcase,
http://www.mapinc.org/, Mozilla is just fine. But clicking on the testcase
link opens up the URL in a new window, and the crash happens.
Also, I've found that while the crash is caused because mChannel is NULL
at this point:
(void) (mChannel->GetApplyConversion(&bApplyConversion));
it isn't NULL when OnDataAvailable() is entered, and the places where
mChannel can be set never assign a NULL value to it. This looks lik it might
be a case of memory trampling, except that it the crash is so conistent.
Comment 17•24 years ago
|
||
I've found that for my latest testcase, the crash is probably
happening because nsHTTPServerListener::OnDataAvailable() is being
called *recursively*; if you'll note the stack trace I'm going to
attach, you'll see that each time that nsHTTPServerListener::OnDataAvailable()
is invoked, it's invoked with the exact same value for "this".
As far as I can tell, what's happening is:
1) nsHTTPServerListener::OnDataAvailable() is invoked, which then
invokes FinishedResponseHeaders().
2) Once the thread gets into FinishedResponseHeaders(), it tries to
open up a new window, since the target for the link isn't the
current window.
3) This causes any current native events to be dispatched.
4) This leads to nsHTTPServerListener::OnDataAvailable() being called
again, for the exact same listener.
5) All the data from that connection is slurped up.
6) OnStopRequest() request is called, setting the mChannel member of
the nsHTTPServerListener instance to NULL via NS_IF_RELEASE().
7) Things finish up, and FinishedResponseHeaders() returns control to
nsHTTPServerListener::OnDataAvailable().
8) nsHTTPServerListener::OnDataAvailable() merrily proceeds along it's
way, but mChannel is now NULL, so it's screwed.
NOTE: The line numbers for the stack trace aren't entirely correct,
because of all the debugging statements I've added.
Comment 18•24 years ago
|
||
Comment 19•24 years ago
|
||
OnDataAvailable is expected to be called multiple times and the calls aren't
really identical-- the offsets/lengths are changing. So the behaviour you are
seeing is ok. Vidur recently checked in some changes today (evening) that relate
to the async reflow for layout and have a possible effect on this bug. I'd
suggest we recheck this bug with those changes in.
Comment 20•24 years ago
|
||
I know OnDataAvailable() is supposed to be called multiple times, but
it still seems to me that it should never be able to indirectly invoke itself
on the same instance. As far as I can tell, it's this indirect recursion
that's causing the crash.
Comment 21•24 years ago
|
||
I crash here often when opening a new window. For example, from mail/news
clicking on a link or other times when using "Open link in new window..."
Here's the patch that I've been using without any problems that I know of. I
have a sneaking suspicion it's not quite right:
Index: nsHTTPResponseListener.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp,v
retrieving revision 1.129
diff -u -r1.129 nsHTTPResponseListener.cpp
--- nsHTTPResponseListener.cpp 2000/09/05 21:22:33 1.129
+++ nsHTTPResponseListener.cpp 2000/10/01 18:12:25
@@ -462,7 +462,7 @@
rv = NS_BINDING_ABORTED;
}
- if (NS_SUCCEEDED(rv) && i_Length) {
+ if (NS_SUCCEEDED(rv) && i_Length && mChannel) {
PRBool bApplyConversion = PR_TRUE;
(void) (mChannel->GetApplyConversion(&bApplyConversion));
Comment 22•24 years ago
|
||
*** Bug 54859 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
adding myself to the cc list.
Comment 24•24 years ago
|
||
this is beta3-? it's a topcrash! cc'ing others from a dupe bug
Comment 25•24 years ago
|
||
amen to that, pink.
I'm on the mtbf (mean time between failure) team. this bug qualifies.
gagan, I'd be happy to start debugging and working on a fix for rtm.
Comment 26•24 years ago
|
||
*** Bug 55102 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
dogfood+ from dup bug 55102
Keywords: dogfood
Whiteboard: [nsbeta3-] → [nsbeta3-][dogfood+]
Assignee | ||
Comment 28•24 years ago
|
||
Our bug results from nested event queues being broken in XPCOM.
Depends on: 54371
Assignee | ||
Comment 29•24 years ago
|
||
*** Bug 54597 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•24 years ago
|
||
*** Bug 52734 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 31•24 years ago
|
||
*** Bug 52061 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 32•24 years ago
|
||
*** Bug 52949 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 33•24 years ago
|
||
*** Bug 42624 has been marked as a duplicate of this bug. ***
Comment 34•24 years ago
|
||
I hit this bug withing 1/2 of browsing cnet and abcnews. Mostly links that cause
a window to pop up and content gets targetted to that cause this for me.
This has got to be rtm+ P1
Comment 35•24 years ago
|
||
*** Bug 52913 has been marked as a duplicate of this bug. ***
Comment 36•24 years ago
|
||
*** Bug 52628 has been marked as a duplicate of this bug. ***
Comment 37•24 years ago
|
||
*** Bug 53163 has been marked as a duplicate of this bug. ***
Comment 39•24 years ago
|
||
Alright I am setting this P1 and need info. After we verify that the changes for
the dependent bug indeed fix this, then we can close this. For most part it
appears that we wouldn't have to change much in HTTP so there may not be a need
for a rtm+/rtm++ to mark this fixed.
Priority: P2 → P1
Whiteboard: [nsbeta3-][dogfood+] → [nsbeta3-][dogfood+][rtm need info]
Assignee | ||
Comment 40•24 years ago
|
||
*** Bug 53555 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 41•24 years ago
|
||
*** Bug 53355 has been marked as a duplicate of this bug. ***
Comment 42•24 years ago
|
||
*** Bug 55023 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
*** Bug 55045 has been marked as a duplicate of this bug. ***
Comment 44•24 years ago
|
||
If you need more test cases, this was my test page for finding spoting the bug.
http://www.zoned.net/~xkahn/crash.html
Comment 45•24 years ago
|
||
*** Bug 54987 has been marked as a duplicate of this bug. ***
Comment 46•24 years ago
|
||
Note additional test case in duplicate Bug #52949.
Comment 47•24 years ago
|
||
Note the testcase in bug 52628 (which has been marked as a duplicate of this
bug). It is seven lines of HTML and crashes mozilla upon load each time. There
is also a description (by me) in the bug describing why this happens.
Assignee | ||
Comment 48•24 years ago
|
||
*** Bug 55029 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 49•24 years ago
|
||
*** Bug 52277 has been marked as a duplicate of this bug. ***
Comment 50•24 years ago
|
||
I have applied the recent checkin to plevent.c, but I do NOT have the other
three patches. With just the plevent fix, I am now locking up where I never
locked up before. When I go to a secure site I get a window appear about the
certificate that's being presented by the remote server. When I click on the
NEXT button at the bottom of this window, the buttons all disappear but the
window remains there and the browser is locked. This is reproducible. If I
revert back to the previous libxpcom then this window is dismissed just fine and
there is no lockup.
Comment 51•24 years ago
|
||
Just so you know, I don't completely have security working in the OpenVMS
version, so this potentially could be some other problem, but I really don't
think so, since I am getting a lot further than the first dialog (with the
previous xpcom).
Also I only have a debug version at this point, so I haven't/can't test with
non-debug.
Assignee | ||
Comment 52•24 years ago
|
||
*** Bug 54783 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
It seems to me that the part fixes of bug 54371 were the only reason this was
crashing. And since dougt landed those (yesterday) all these crasher have
disappeared. I am hence marking this fixed. Thanks to dougt, darin, danm -- bye
bye crasher-bug!
Assignee | ||
Comment 54•24 years ago
|
||
*** Bug 52314 has been marked as a duplicate of this bug. ***
Comment 55•24 years ago
|
||
in what builds should we expect to see this fix?
Comment 56•24 years ago
|
||
sorry forgot to add that- this should be fixed on both the trunk and the branch
(per dougt's comments on his checkin for bug 54371)
Comment 57•24 years ago
|
||
*** Bug 55177 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 58•24 years ago
|
||
*** Bug 52314 has been marked as a duplicate of this bug. ***
Comment 60•24 years ago
|
||
*** Bug 56005 has been marked as a duplicate of this bug. ***
Comment 61•24 years ago
|
||
Reopening bug, this crash is still happening with the official RTM build on
Linux and is the #8 topcrasher with RTM on Windows...so changing OS to All. The
stack trace is about the same as before:
Incident ID 21984337
nsHTTPServerListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp,
line 469]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 406]
nsStreamListenerEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 581]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 517]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1051]
KERNEL32.DLL + 0x2222f (0xbff9222f)
0x00658b54
Although the original steps to reproduce no longer seem to cause a crash, a lot
of talkback reports have been submitted for this crash. Most of the entries
show the following two locations in the code at the top of the stack trace:
Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp
line : 454
and
Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp
line : 469
I have not been able to reproduce, but here are a few URLs and comments from the
talkback entries:
URL: About.com
URL: I
URL: jackpot.com
URL: real.com
URL: www.apple.com URL: www.bellsouth.net URL: www.email.com URL: www.juston.com
URL: www.yahoo.com Comment: i was browsing the adult website
Comment: entered a nokia site to develope my own cell phone cover design. This
thing is really unstable. when may I expect a reply?
Comment: why are you having so much trouble with this new netscape i like it but
it keeps locking up / and i keep getting an error message. i dont like that ..
Comment: Closing out from the web.
Comment: Closed a pop up window
Comment: i tried to change the skin
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Updated•24 years ago
|
Summary: Crashing in [@ nsHTTPServerListener::OnDataAvailable] → RTM Crash #9 [@ nsHTTPServerListener::OnDataAvailable]
Comment 62•24 years ago
|
||
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Status: REOPENED → NEW
Component: Networking → Networking: HTTP
Target Milestone: --- → M19
Updated•24 years ago
|
Target Milestone: M19 → mozilla0.8
Comment 63•24 years ago
|
||
This is also the #8 topcrash for RTM release on Linux. Changing OS to All.
Here are a couple of URLs and Comments from Linux users:
URL:(23133463) www.sfgate.com
Comment: (23133463) seems to crash the browser every single time I open it!
URL:(23155254) register.com
Comment: (23140452) location bar won't accept <enter> so tried CTL+L / open location
OS: Linux → All
Updated•24 years ago
|
Comment 64•24 years ago
|
||
*** Bug 63585 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 65•24 years ago
|
||
Looks to me like 54371 fixed this... marking as dupe.
*** This bug has been marked as a duplicate of 54371 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 66•24 years ago
|
||
missed the later comments on this bug... reopening. sounds like there is
something extremely subtle going on here... investigating possible causes.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 67•24 years ago
|
||
The bug 62643 seems to be a dupe of this one.
Comment 68•24 years ago
|
||
Jpatel: this seems like a different bug. I recently added additional check for a
null pointer which might have fixed that. Could you verify with a more recent
build. It definitely is not this bug since this bug deals with the problems
relating to events going out of sync. I am closing this as fixed again- pls.
open a new one if you see problems with the sfgate.com site(s) which work fine
for me.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 69•24 years ago
|
||
changing summary to N601 for tracking. gagan, this crash is still happening with
N601...but doesn't show up for any recent trunk builds. so i'm assuming the
problem has been fixed since the N601 release...if it pops up again in any form,
i will open a new bug. sorry about the confusion.
Summary: RTM Crash #9 [@ nsHTTPServerListener::OnDataAvailable] → N601 Crash #8 [@ nsHTTPServerListener::OnDataAvailable]
Assignee | ||
Comment 70•24 years ago
|
||
Reopening to track landing this patch on the N6 branch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 71•24 years ago
|
||
Marking FIXED (again)... seems the 6.0 branch is dead.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 72•23 years ago
|
||
Verifying to get off the most frequent bug radar. After an HTTP rearch, this bug
is well and truly dead.
Gerv
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsHTTPServerListener::OnDataAvailable]
You need to log in
before you can comment on or make changes to this bug.
Description
•