412338 - Assertion failure: !cx->thread || cx->thread == thread, at /home/kaie/moz/head/mozilla/js/src/jscntxt.c:177

Status: RESOLVED WORKSFORME

(Core Graveyard :: Security: UI, defect)

Description

[Kai Engert [:KaiE:]]

Attachment: crash stack

I followed the STR in bug 408601:
- Go to https://verisign.com
- Add a expection for the Site
- The verisign homepage loads

Well, I did not get that crash described in that bug.

However, after the page loaded, I quit Firefox.
This results in the following assertion...

  Assertion failure: !cx->thread || cx->thread == thread, at 
  /home/kaie/moz/head/mozilla/js/src/jscntxt.c:177

... and I crash. Stack attached.

Comment 1

[Brendan Eich [:brendan]]

What was cx->thread->id? Can you find thread ids as assigned by NSPR for the running threads (info threads in gdb might give them, depending on platform; not sure but IIRC NSPR uses native thread ids on some OSes).

/be

Comment 2

[Kai Engert [:KaiE:]]

Now I got this, even earlier in the procedure:

Assertion failure: cx->thread->id == js_CurrentThreadId(), at /home/kaie/moz/head/mozilla/js/src/jsapi.c:852

Will try to answer question from comment 1 next.

Comment 3

[Kai Engert [:KaiE:]]

Attachment: crash stack for comment 2

Comment 4

[Kai Engert [:KaiE:]]

Attachment: more info from gdb for comment 2

this answers the question about the value of thread id.

Comment 5

[timeless]

your code isn't legal. 

nsIProxyObjectManager.getProxyForObject should be called on the original thread, not the second thread. The object you had wasn't thread safe and you passed it across a thread.

You have two choices:
A. get the proxy for the thread unsafe object *in advance* on the ui thread.
B. get a proxy to a threadsafe object and pass the work to it, and have it then on the ui thread operate on this potentially thread unsafe object.

Comment 6

[Kai Engert [:KaiE:]]

Tentatively marking as a duplicate of bug Bug 414745, as it talks about the same assertion.

Comment 8

[Wan-Teh Chang]

Kai, your stack trace is different from the stack trace in bug 414745.

Comment 9

[Wan-Teh Chang]

Sorry, I only saw the second stack trace.  The (first) crash stack is the same.

Comment 10

[timeless]

kaie: comment 2/comment 5 are a bug, please make sure there's a living bug for it, i really don't want my research into that to get lost.

Comment 11

[Kai Engert [:KaiE:]]

reopening to deal with comment 2 + 5

Comment 12

[Honza Bambas (:mayhemer)]

Crash stack in description and other one in comment 3 are IMO separate issues (bugs). I am unable to reproduce any of these. If it is a priority, I will dive into the code searching for possible cause. But it will probably take time.

Comment 13

[Kai Engert [:KaiE:]]

I can't reproduce either.

Is anyone still able to?

Comment 14

[Honza Bambas (:mayhemer)]

Marking WFM since no other cases seen apparently.