Starting Debug SeaMonkey with autoconfig file gives Assertion failure: (cx)->requestDepth || (cx)->thread == (cx)->runtime->gcThread

RESOLVED FIXED

Status

()

Core
XPConnect
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
Created attachment 286736 [details] [diff] [review]
Possible Fix

I'm filing this here as its either here or Preferences and this looks like a core bug which has a solution similar to bug 397319 which is also filed in xpconnect.

Problem in debug builds of SeaMonkey trunk.

In greprefs/all.js define
pref("general.config.obscure_value", 0);
pref("general.config.filename", "mozilla.cfg");

add a mozilla.cfg file to you SeaMonkey bin directory:
//
try {
  lockPref("mailnews.start_page.url", "chrome://messenger-region/locale/region.properties");
}
catch (e) {
  displayError("boo", e);
}


Now start SeaMonkey and get:
WARNING: XPCOM objects created/destroyed from static ctor/dtor: 'gActivityTLS != BAD_TLS_INDEX && NS_PTR_TO_INT32(PR_GetThreadPrivate(gActivityTLS)) == 0', file /mozilla/master/mozilla/xpcom/base/nsTraceRefcntImpl.cpp, line 1028
+++ JavaScript debugging hooks installed.
*** Registering components in: Apprunner
Assertion failure: (cx)->requestDepth || (cx)->thread == (cx)->runtime->gcThread, at /mozilla/master/mozilla/js/src/jsapi.c:2895
./run-mozilla.sh: line 131: 11458 Trace/breakpoint trap   "$prog" ${1+"$@"}

This may apply to Firefox as well, a release build that I tried didn't have the problem but that may have been out of date.

The stack is:
#0  JS_Assert (s=0x400f4128 "(cx)->requestDepth || (cx)->thread == (cx)->runtime->gcThread", file=0x400f4100 "/mozilla/master/mozilla/js/src/jsapi.c", ln=2895) at /mozilla/master/mozilla/js/src/jsutil.c:63
#1  0x4005a2b6 in JS_NewObject (cx=0x815ccb8, clasp=0x41b20ec0, proto=0x0, parent=0x0) at /mozilla/master/mozilla/js/src/jsapi.c:2895
#2  0x41b1c0a8 in CentralizedAdminPrefManagerInit () at /mozilla/master/mozilla/extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp:162
#3  0x41b14f4f in nsReadConfig::readConfigFile (this=0x814d988) at /mozilla/master/mozilla/extensions/pref/autoconfig/src/nsReadConfig.cpp:188
#4  0x41b153db in nsReadConfig::Observe (this=0x814d988, aSubject=0x8147390, aTopic=0x419e4564 "prefservice:before-read-userprefs", someData=0x0) at /mozilla/master/mozilla/extensions/pref/autoconfig/src/nsReadConfig.cpp:141
#5  0x401ad21c in nsObserverList::NotifyObservers (this=0x8274b14, aSubject=0x8147390, aTopic=0x419e4564 "prefservice:before-read-userprefs", someData=0x0) at /mozilla/master/mozilla/xpcom/ds/nsObserverList.cpp:128
#6  0x401ae675 in nsObserverService::NotifyObservers (this=0x8147400, aSubject=0x8147390, aTopic=0x419e4564 "prefservice:before-read-userprefs", someData=0x0) at /mozilla/master/mozilla/xpcom/ds/nsObserverService.cpp:181
#7  0x419dd76e in nsPrefService::NotifyServiceObservers (this=0x8147390, aTopic=0x419e4564 "prefservice:before-read-userprefs") at /mozilla/master/mozilla/modules/libpref/src/nsPrefService.cpp:295
#8  0x419ddff6 in nsPrefService::ReadUserPrefs (this=0x8147390, aFile=0x0) at /mozilla/master/mozilla/modules/libpref/src/nsPrefService.cpp:218
#9  0x419dec07 in nsPrefService::Observe (this=0x8147390, aSubject=0x0, aTopic=0x40162270 "profile-do-change", someData=0x401626e0) at /mozilla/master/mozilla/modules/libpref/src/nsPrefService.cpp:200
#10 0x401ad21c in nsObserverList::NotifyObservers (this=0x8274cf4, aSubject=0x0, aTopic=0x40162270 "profile-do-change", someData=0x401626e0) at /mozilla/master/mozilla/xpcom/ds/nsObserverList.cpp:128
#11 0x401ae675 in nsObserverService::NotifyObservers (this=0x8147400, aSubject=0x0, aTopic=0x40162270 "profile-do-change", someData=0x401626e0) at /mozilla/master/mozilla/xpcom/ds/nsObserverService.cpp:181
#12 0x4015105e in nsXREDirProvider::DoStartup (this=0xbfc5b41c) at /mozilla/master/mozilla/toolkit/xre/nsXREDirProvider.cpp:789
#13 0x4014b232 in XRE_main (argc=1, argv=0xbfc5b674, aAppData=0x804c958) at /mozilla/master/mozilla/toolkit/xre/nsAppRunner.cpp:3009
#14 0x08048b45 in main (argc=1, argv=0xbfc5b674) at /mozilla/master/mozilla/suite/app/nsSuiteApp.cpp:99

From looking at other bugs (397319) with the same assertion and a bit of a guess work, adding JSAutoRequest in nsJSConfigTriggers.cpp seems to fix it (attaching patch).

Not sure if this is totally the right solution, but it fixes it for me.
Attachment #286736 - Flags: superreview?(jst)
Attachment #286736 - Flags: review?(jst)
Comment on attachment 286736 [details] [diff] [review]
Possible Fix

     // Create a new JS context for autoconfig JS script
     autoconfig_cx = JS_NewContext(rt, 1024);
     if (!autoconfig_cx)
         return NS_ERROR_OUT_OF_MEMORY;
 
+    JSAutoRequest ar(autoconfig_cx);
+
     JS_SetErrorReporter(autoconfig_cx, autoConfigErrorReporter);

Might as well move the JSAutoRequest up even earlier, before the call to JS_NewContext() while you're at it (even though I don't think it really matters).

r+sr=jst with that.
Attachment #286736 - Flags: superreview?(jst)
Attachment #286736 - Flags: superreview+
Attachment #286736 - Flags: review?(jst)
Attachment #286736 - Flags: review+
(Assignee)

Comment 2

10 years ago
(In reply to comment #1)
> (From update of attachment 286736 [details] [diff] [review])
>      // Create a new JS context for autoconfig JS script
>      autoconfig_cx = JS_NewContext(rt, 1024);
>      if (!autoconfig_cx)
>          return NS_ERROR_OUT_OF_MEMORY;
> +    JSAutoRequest ar(autoconfig_cx);
> +
>      JS_SetErrorReporter(autoconfig_cx, autoConfigErrorReporter);
> Might as well move the JSAutoRequest up even earlier, before the call to
> JS_NewContext() while you're at it (even though I don't think it really
> matters).

I don't see how we can move it up even earlier - the JSAutoRequest initialising is using the value from JS_NewContext that we've just created.
Duh, of course. nm me.
(Assignee)

Comment 4

10 years ago
Comment on attachment 286736 [details] [diff] [review]
Possible Fix

Requesting approval to land this fix to starting up with an autconfig file. FF release didn't seem to need it, but debug builds of SM definitely do. Very useful for testing.
Attachment #286736 - Flags: approvalM9?
Assignee: nobody → bugzilla
Comment on attachment 286736 [details] [diff] [review]
Possible Fix

a=endgame drivers for M9
Attachment #286736 - Flags: approvalM9?
Attachment #286736 - Flags: approvalM9+
Attachment #286736 - Flags: approval1.9+
(Assignee)

Comment 6

10 years ago
Patch checked in -> fixed.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.