878679 - Nightly regression: zotero stalls building folder list

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Shaddy Baddah]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:24.0) Gecko/20130602 Firefox/24.0 (Nightly/Aurora)
Build ID: 20130602031240

Steps to reproduce:

Update nightly when prompted to.


Actual results:

At some point in doing so, Zotero stopped working correctly. When the Zotero add-on icon is clicked, the Zotero pane opens up, but the article list sub-pane shows the inprogress text "Loading items list..." without ever coming back. CPU usage goes to almost 100% on one core.


Expected results:

The inprogress text should appear momentarily, then the list of articles should appear.

Note, I have done a bisect and traced this information:

about:buildconfig lists the source for the last known good as:

http://hg.mozilla.org/mozilla-central/rev/c21ef3664c67

(from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-05-22-03-10-27-mozilla-central/firefox-24.0a1.en-US.win64-x86_64.zip)

and the next nightly is first know bad:

http://hg.mozilla.org/mozilla-central/rev/00b264c7cced

(from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-05-23-03-09-35-mozilla-central/firefox-24.0a1.en-US.win64-x86_64.zip)

Comment 1

[Alice0775 White]

Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2436070bf252&tochange=1add7f1eeb40

Regressed by:
1add7f1eeb40	Jan de Mooij — Bug 857845 part 3 - Remove JM JSAPI flags, memory reporters and browser prefs. r=djvj

And Error console shows:

Timestamp: 2013/06/06 5:11:25
Error: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://zotero/content/xpcom/zotero.js :: timerCallback.notify :: line 1621"  data: no]
Source File: chrome://zotero/content/xpcom/zotero.js
Line: 1621

>       Components.utils.methodjit = useJIT;

Comment 2

[Boris Zbarsky [:bzbarsky]]

This sounds like an issue that should be fixed in the addon.  Why exactly is that addon messing with the JIT settings anyway???  That has nothing to do with what it ostensibly claims to be for...

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

We asked the developer about this, and he pointed to bug 776798. Dan, can you explain why this is necessary?

Comment 4

[Simon Kornblith]

nsITimerCallbacks to XPCOM components don't get JITed, and this has a substantial performance impact for us.

I've already fixed this on our end by switching the relevant code to use setTimeout on the hidden window instead of nsITimers, which works around bug 776798 without changing Components.utils.methodjit.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Simon, does your setTimeout thing still work in Firefox 23 given bug 810644?  That changed the JSContext that gets used from the context of the window to the one associated with the callee function's global....

Comment 6

[Simon Kornblith]

bz, you're right, the setTimeout hack no longer works unless the function passed to setTimeout was created in a window. I can work around that by calling eval on the hidden window to define a function that wraps the argument to setTimeout(), but I'm not sure that's a great idea.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yeah, we just need to fix bug 776798...  It will happen, but probably not for 23.  Hopefully for 24.  :(

Comment 8

[Shaddy Baddah]

Hi. Although I haven't been able to track either from bug 776798 or others if this issue was fixed, I have noticed that the problem has gone with recent Nightly builds. I've logged a separate bug 898955 describing a zotero regression that I think is unlikely to be related to this bug. However, I thought I would "name drop" just in case there turns out to be some link (or unfinished fix here).

Comment 9

[Simon Kornblith]

This was actually our (Zotero's) issue to fix, and we fixed it in Zotero 4.0.9, which is probably why you're no longer seeing it. While building the folder list will be slower until bug 776798 is fixed, at least it will work. This bug can be closed.

Comment 10

[Till Schneidereit [:till]]

Fixed in Zotero, as per comment 9. The underlying platform issue that causes a slowdown is tracked in bug 776798.