Closed
Bug 14049
Opened 25 years ago
Closed 25 years ago
CRASHER - javascript: runs JS on wrong thread's JSContext
Categories
(Other Applications Graveyard :: Venkman JS Debugger, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M11
People
(Reporter: harishd, Assigned: dougt)
References
Details
Type javascript:'some text' ,in the URL bar, and you should see the following
crash:
js_Lock(JSThinLock * 0x0147c2e8, long 13902112) line 577 + 39 bytes
js_AtomizeString(JSContext * 0x01064430, JSString * 0x01ccfa30, unsigned int 2)
line 466 + 24 bytes
js_AtomizeChars(JSContext * 0x01064430, unsigned short * 0x014eeb58, unsigned
int 6, unsigned int 0) line 540 + 19 bytes
js_GetToken(JSContext * 0x01064430, JSTokenStream * 0x014ee8d0) line 901 + 36
bytes
js_Parse(JSContext * 0x01064430, JSObject * 0x020da6b0, JSTokenStream *
0x014ee8d0, JSCodeGenerator * 0x01ccfbc0) line 212 + 13 bytes
CompileTokenStream(JSContext * 0x01064430, JSObject * 0x020da6b0, JSTokenStream
* 0x014ee8d0, void * 0x02096b40, int * 0x00000000) line 2183 + 21 bytes
JS_CompileUCScriptForPrincipals(JSContext * 0x01064430, JSObject * 0x020da6b0,
JSPrincipals * 0x00e9d238, unsigned short * 0x028c3920, unsigned int 8, char *
0x00000000, unsigned int 0) line 2261 + 23 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x01064430, JSObject * 0x020da6b0,
JSPrincipals * 0x00e9d238, unsigned short * 0x028c3920, unsigned int 8, char *
0x00000000, unsigned int 0, long * 0x01ccfcd0) line 2612 + 33 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x027aa8c0, const nsString & {""
hello""}, nsIPrincipal * 0x00e9d230, char * 0x00000000, unsigned int 0, nsString
& {""}, int * 0x01ccfd28) line 172 + 66 bytes
nsJSInputStream::Eval() line 155 + 53 bytes
nsJSInputStream::Available(nsJSInputStream * const 0x0281f670, unsigned int *
0x01ccff18) line 96 + 8 bytes
nsFileTransport::Process() line 503 + 42 bytes
nsFileTransport::Run(nsFileTransport * const 0x028c3eb4) line 418
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x00e65d30) line 563 + 12
bytes
nsThread::Main(void * 0x00e65d60) line 102 + 18 bytes
_PR_NativeRunThread(void * 0x00e65da0) line 379 + 13 bytes
_threadstartex(void * 0x00e65120) line 212 + 13 bytes
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Target Milestone: M11
Updated•25 years ago
|
Priority: P3 → P1
Comment 2•25 years ago
|
||
Oop, need to proxy from necko threads to ui thread to muck with a DOM JSContext.
/be
Updated•25 years ago
|
Summary: CRASHER - javascript: → CRASHER - javascript: runs JS on wrong thread's JSContext
Comment 3•25 years ago
|
||
*** Bug 14144 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Assignee: brendan → warren
Status: ASSIGNED → NEW
Comment 5•25 years ago
|
||
Hey, rpotts helped point the finger: you changed nsInputStreamChannel so URIs
like javascript:'hi' and about:blank all go through thread-crossing file input
control flow. This is ineffeciently unnecessary for about:, but for javascript:
it's fatal as the stack shows. Can you unregress easily, or give me some help
on fixing this? Thanks,
/be
Comment 6•25 years ago
|
||
No can do. Changing nsInputStreamChannel to pump the data from the file
transsport thread was done to fix Bug# 10273. I didn't realize that it was going
to cause the inadvertent effect on the js protocol, but now I would suggest
marshaling the execution back to the mozilla thread. Maybe the evaluation can be
done there on the mozilla thread before the input stream is given to the
input stream channel.
Comment 7•25 years ago
|
||
First principles: you broke it, you fix it. Seriously, I don't see why JS urls
(or about: for that matter) need to cross a thread boundary once, let alone
twice for JS as you're proposing. Why can't JS evaluate the path part
synchronously in the webshell, ASAP, and the browser get on with its life?
/be
Comment 8•25 years ago
|
||
While I agree with peterl in general about avoiding mixed async/sync model, is
there no way we can harmonize for our model so that NS_OpenURI appears async,
but javascript: URLs are evaluated ASAP without thread-crossing?
/be
Comment 10•25 years ago
|
||
*** Bug 9020 has been marked as a duplicate of this bug. ***
Comment 11•25 years ago
|
||
hi tever!
Comment 12•25 years ago
|
||
is this going to be fixed anytime soon? javascript: urls are used all over the
place.... must be preventing lots of people from using this as dogfood.
Comment 13•25 years ago
|
||
Really? I thought javascript: urls were rarely (if ever) used. Only when the
ambitious user types them into the location bar.
Updated•25 years ago
|
Assignee: warren → brendan
Comment 14•25 years ago
|
||
BTW, Brendan's working on this...
Comment 15•25 years ago
|
||
*** Bug 15650 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 16•25 years ago
|
||
Not crashing anymore!! Is this bug FIXED?
FYI: Tested with Oct. 23rd build.
Updated•25 years ago
|
Assignee: brendan → dougt
Comment 17•25 years ago
|
||
Dougt did the work -- he should close if this is truly fixed for good.
/be
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 18•25 years ago
|
||
yup. javascript: urls are now evaluated on the primordial thread which happens
to be the js/dom thread.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 19•25 years ago
|
||
Verified fixed, and tested with "javascript:alert(navigator.userAgent).
Updated•20 years ago
|
Product: Core → Other Applications
Updated•6 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•