Closed
Bug 10456
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] [BLOCKER] External entity loading should be asynchronous
Categories
(Core :: Networking, defect, P1)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: morse, Assigned: nisheeth_mozilla)
References
Details
(Whiteboard: Blocking all valid XML parsing; blocking QA of XHTML support)
Select menu item edit/wallet/wallet-contents. Get a crash with the following
stack trace.
NTDLL! 77f76274()
nsDebug::Error(const char * 0x0a270ab8, const char * 0x0a270a80, int 150) line
195 + 13 bytes
nsHTTPChannel::OpenInputStream(nsHTTPChannel * const 0x0ac27090, unsigned int 0,
int -1, nsIInputStream * * 0x0012be24) line 150 + 21 bytes
wallet_FetchFromNetCenter(char * 0x0ad438e4, char * 0x0ad438d4) line 1340 + 20
bytes
wallet_FetchFieldSchemaFromNetCenter() line 1390 + 15 bytes
wallet_Initialize() line 1624
WLLT_PreEdit(nsAutoString & {...}) line 2175
nsWalletlibService::WALLET_PreEdit(nsWalletlibService * const 0x0ac2f540,
nsAutoString & {...}) line 99 + 9 bytes
WalletEditorImpl::GetValue(WalletEditorImpl * const 0x0ab30f50, char * *
0x0012c060) line 94 + 16 bytes
XPTC_InvokeByIndex(nsISupports * 0x0ab30f50, unsigned int 4, unsigned int 1,
nsXPTCVariant * 0x0012c060) line 135
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x0a22d550,
nsXPCWrappedNative * 0x0ab30270, const XPCNativeMemberDescriptor * 0x0ab302e8,
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long *
0x00ef6cc0, long * 0x0012c268) line 511 + 44 bytes
WrappedNative_CallMethod(JSContext * 0x0a22d550, JSObject * 0x00ef41d8, unsigned
int 0, long * 0x00ef6cc0, long * 0x0012c268) line 130
js_Invoke(JSContext * 0x0a22d550, unsigned int 0, unsigned int 0) line 654 + 26
bytes
js_Interpret(JSContext * 0x0a22d550, long * 0x0012ca90) line 2228 + 15 bytes
js_Invoke(JSContext * 0x0a22d550, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x0a22d550, long * 0x0012d274) line 2228 + 15 bytes
js_Invoke(JSContext * 0x0a22d550, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x0a22d550, long * 0x0012da58) line 2228 + 15 bytes
js_Invoke(JSContext * 0x0a22d550, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x0a22d550, long * 0x0012e23c) line 2228 + 15 bytes
js_Invoke(JSContext * 0x0a22d550, unsigned int 1, unsigned int 2) line 670 + 13
bytes
js_InternalCall(JSContext * 0x0a22d550, JSObject * 0x00e85798, long 15680024,
unsigned int 1, long * 0x0012e37c, long * 0x0012e384) line 747 + 15 bytes
JS_CallFunctionValue(JSContext * 0x0a22d550, JSObject * 0x00e85798, long
15680024, unsigned int 1, long * 0x0012e37c, long * 0x0012e384) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0ac285a0) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012e538, nsIDOMEvent * * 0x0012e4a0, unsigned int 3, nsEventStatus &
nsEventStatus_eIgnore) line 959 + 21 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0a22ca24,
nsIPresContext & {...}, nsEvent * 0x0012e538, nsIDOMEvent * * 0x0012e4a0,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2744
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x0a247e54, nsIDocumentLoader *
0x0a246030, nsIChannel * 0x0a171590, int 0, nsIDocumentLoaderObserver *
0x0a247e54) line 2963 + 34 bytes
nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x0a246030, int 0)
line 1100
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x0a246034, nsIChannel *
0x0a171590, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 1025
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0ac28490) line
284
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0ac28494) line 149 + 12 bytes
PL_HandleEvent(PLEvent * 0x0ac28494) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a60360) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x083504a6, unsigned int 49404, unsigned int 0,
long 10879840) line 932 + 9 bytes
USER32! 77e71268()
00a60360()
I assume this happens with the Necko build only? What builds - trunk and branch
was this tested on?
Reporter | ||
Updated•25 years ago
|
Severity: normal → blocker
Reporter | ||
Comment 2•25 years ago
|
||
This bug is a blocker right now because it prevents wallet from being used.
Raising severity.
BTW, you won't observe the problem with builds made last night or today. In my
own private tree I have temporarily bypassed the call to
wallet_FetchFromNetcenter and then accidentally checked in my file containing
that change. As soon as the tree opens I will check in a new version without
the change.
In answer to Jan's question, this is happening with Necko build only. It is
being tested on builds made from the tip but by using NECKO=1 in the build.
Reporter | ||
Updated•25 years ago
|
Priority: P3 → P1
Summary: Error on OpenInputStream → [BLOCK] Error on OpenInputStream
Comment 3•25 years ago
|
||
Gagan, does http support sync IO yet?
Reporter | ||
Comment 8•25 years ago
|
||
Can someone give me an estimate as to when this bug will get fixed? It is a
serious bug that is preventing any useage or testing of wallet. Yet the bug is
still marked as "new" although it was reported five days ago.
Reporter | ||
Comment 10•25 years ago
|
||
This bug appears to be related to bug 11016 although I'm not prepared to say at
this time that the two bugs are duplicates. I'll leave that up to the necko
team to decide.
Reporter | ||
Comment 11•25 years ago
|
||
This bug may appear to be fixed, but it is not. I just checked in a work-around
that is avoiding the crash but it is full of memory leaks and it does not work
on the mac.
For the purpose of testing this bug, go to the file
extensions/wallet/src/wallet.cpp and comment out the #define NEWFETCH line.
That will remove my work-around and make the bug reappear.
Comment 12•25 years ago
|
||
No sync in HTTP as yet.
Updated•25 years ago
|
Summary: [BLOCK] Error on OpenInputStream → Error on OpenInputStream for http channel
Comment 13•25 years ago
|
||
Changing title since this is no longer a blocker due to workaround.
Steve, please report any leaks you've found separately. Thanks.
Reporter | ||
Comment 14•25 years ago
|
||
The leaks I was referring to are not in necko but rather in the temporary patch
that Andreas provided.
Reporter | ||
Comment 15•25 years ago
|
||
*** Bug 11340 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 16•25 years ago
|
||
*** Bug 11356 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•25 years ago
|
||
*** Bug 11356 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Summary: Error on OpenInputStream for http channel → Implement OpenInputStream for http channel
Comment 18•25 years ago
|
||
Is this still an M9 blocker? Or can it be moved to an M10 feature...
Reporter | ||
Comment 19•25 years ago
|
||
What do define as a blocker? It blocked one of the wallet features (downloadig
of mapping tables from server) and, as a consequence, I had to disable that
feature from wallet for M9.
Comment 20•25 years ago
|
||
And hence, this can be moved off to M10. Right ?
Comment 21•25 years ago
|
||
Sounds good for move to M10. paulmac, please make sure to release note that this
feature is disabled.
Comment 22•25 years ago
|
||
*** Bug 10703 has been marked as a duplicate of this bug. ***
Comment 23•25 years ago
|
||
Wallet shouldn't depend on this right. Even if necko fixed this, we decided that
wallet will implement async update of the file instead of sync. So I am removing
this from any wallet list.
Steve correct me if I am wrong.
Assignee | ||
Comment 24•25 years ago
|
||
*** Bug 11948 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Severity: blocker → critical
Comment 25•25 years ago
|
||
m11
Updated•25 years ago
|
Target Milestone: M10 → M11
Comment 26•25 years ago
|
||
This is blocking one of my projects, as parsing of valid XHTML files is hosed
until this bug can be fixed.
Comment 27•25 years ago
|
||
[Oops, accidentally nuked dependencies...]
Comment 28•25 years ago
|
||
I don't know anything about xhtml, but for it to use OpenInputStream, it must be
running on some other thread besides the main, mozilla, thread. Is that the
case?
Updated•25 years ago
|
Severity: critical → blocker
Summary: Implement OpenInputStream for http channel → [BLOCKER] Implement OpenInputStream for http channel
Whiteboard: Blocking QA of XHTML support → Blocking all valid XML parsing; blocking QA of XHTML support
Comment 29•25 years ago
|
||
The problem is the XML parser needs a blocking read to parse the DTD of the
document. All valid XML documents have DTDs. Therefore, it is currently TOTALLY
IMPOSSIBLE to view valid XML documents on the web, as blocking reads do not work
by http.
In bug 11948, nisheeth wrote:
: [For valid XML documents, the XML parser] attempts to access a DTD file on a
: remote host. This is currently not working because Necko does not support
: synchronous file loading. Once Rick Potts fixes bug 10456, this will [work].
I'm increasing the priority to blocker. This is a major beta blocker since XML
parsing is supposed to be one of our main "selling" points!
If the problem is in the XML parser implementation (i.e, XML shouldn't be
using this call to get the DTD), then tell nisheeth...
Comment 30•25 years ago
|
||
Why is the XML handling of DTD files any different than that of HTML for linked
scripts and style sheets?
In HTML, these linked files are downloaded asynchronously (but with the parser
blocked) to allow UI feedback. If the XML parser did a blocking read on the UI
thread *all user feedback would stop*.
Nisheeth, can XML handle its DTD files the same way that <SCRIPT SRC=foo.js> is
done by HTML? I think that this is the right solution...
Assignee | ||
Updated•25 years ago
|
Assignee: rpotts → nisheeth
Assignee | ||
Comment 31•25 years ago
|
||
I wasn't on the cc list. Sorry for not responding to your question earlier,
Rick.
I agree with Rick that DTD loading should be asynchronous. The decision to make
it synchronous was made by the intl folk who implemented the external DTD load
feature; they probably thought that this was OK because their DTD files were
always resident on the local disk.
I'm putting this on my plate for M11...
Assignee | ||
Comment 32•25 years ago
|
||
*** Bug 15027 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: [BLOCKER] Implement OpenInputStream for http channel → [BLOCKER] External entity loading should be asynchronous
Assignee | ||
Comment 33•25 years ago
|
||
Updating summary to reflect the true nature of what we are blocked on.
Assignee | ||
Updated•25 years ago
|
Summary: [BLOCKER] External entity loading should be asynchronous → [DOGFOOD] [BLOCKER] External entity loading should be asynchronous
Comment 34•25 years ago
|
||
Please explain how this is blocking XML parsing. We will look at in PDT daily
mtg tomorrow to decide PDT+ or PDT- based on new comments.
Comment 35•25 years ago
|
||
This prevents any XML file with a DOCTYPE with an http URL (such as the ones for
XHTML) from loading. That is, any *valid* XHTML file won't load.
I modified all my DOM test XML files by removing the DOCTYPE, but not everyone
will do that...
Assignee | ||
Comment 36•25 years ago
|
||
I have changes in my tree that fix this. We are only going to load external
DTDs when the DTD is referred to with a chrome url. This is because external
DTD loading is an "internal" feature that we need for doing entity substitution
in mozilla. We do not want to expose external DTD loading as a general XML
feature because doing so takes our XML parser a "not quite validating" parser
and we end up with a non-standards-compliant XML implementation. We'd rather
restrict mozilla's XML parser to be non-validating so that we remain standards
compliant.
Assignee | ||
Comment 37•25 years ago
|
||
Actually, I should say that my changes will fix the "XHTML page not loading
bugs" that are related to this bug. The problem that DTD loading is synchronous
remains. But, for now, that problem is lower priority because chrome urls will
map to file urls which do support synchronous access.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 38•25 years ago
|
||
The fix is checked in. Marking as such.
Assignee | ||
Comment 39•25 years ago
|
||
I've opened up bug 17236 on myself to track making chrome url'd DTD loads
asynchronous.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 40•25 years ago
|
||
verified with pages from http://www.xhtml.org using 10/29 build
Comment 41•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
You need to log in
before you can comment on or make changes to this bug.
Description
•