14049 - CRASHER - javascript: runs JS on wrong thread's JSContext

Status: VERIFIED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect, P1)

Description

[harishd]

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

Comment 1

[brendan-obsolete]

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

Comment 2

[brendan-obsolete]

Oop, need to proxy from necko threads to ui thread to muck with a DOM JSContext.

/be

Comment 3

[brendan-obsolete]

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

Comment 4

[vidur (gone)]

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

Comment 5

[brendan-obsolete]

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

[Warren Harris]

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

[brendan-obsolete]

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

[brendan-obsolete]

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 9

[Norris Boyd]

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

Comment 10

[brendan-obsolete]

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

Comment 11

[cbegle]

hi tever!

Comment 12

[Alec Flett]

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

[Warren Harris]

Really? I thought javascript: urls were rarely (if ever) used. Only when the
ambitious user types them into the location bar.

Comment 14

[Warren Harris]

BTW, Brendan's working on this...

Comment 15

[rogerl (gone)]

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

Comment 16

[harishd]

Not crashing anymore!!  Is this bug FIXED?

FYI: Tested with Oct. 23rd build.

Comment 17

[Brendan Eich [:brendan]]

Dougt did the work -- he should close if this is truly fixed for good.

/be

Comment 18

[Doug Turner (:dougt)]

yup.  javascript: urls are now evaluated on the primordial thread which happens
to be the js/dom thread.

Comment 19

[John Unruh]

Verified fixed, and tested with "javascript:alert(navigator.userAgent).