Tree Style Tab and/or Session Manager crashes Nightly [@ js::gc::StoreBuffer::isOkayToUseBuffer() ]

VERIFIED FIXED in Firefox 40



JavaScript Engine
3 years ago
3 years ago


(Reporter: Fanolian, Assigned: jorendorff)


(4 keywords)

40 Branch
crash, regression, reproducible, topcrash
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox39 unaffected, firefox40 verified)


(crash signature)


(1 attachment, 2 obsolete attachments)



3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150403030204

Steps to reproduce:

1. Install Tree Style Tab 0.15.2015030601 in a new profile in Nightly 20150403 build. Restart the browser. (

Actual results:

Nightly crashes at startup.

Nightly did not crash on 2015-04-02 build.

Crash report:

Comment 1

3 years ago
Filed a bug report at
Crash Signature: [@ js::gc::StoreBuffer::isOkayToUseBuffer() ]
Keywords: crash, reproducible

Comment 2

3 years ago
[Tracking Requested - why for this release]:


Triggered by: Bug 1138499
Blocks: 1138499
Severity: normal → critical
status-firefox39: --- → unaffected
status-firefox40: --- → affected
tracking-firefox40: --- → ?
Component: Untriaged → JavaScript Engine
Ever confirmed: true
Flags: needinfo?(jorendorff)
Keywords: regression
Product: Firefox → Core
Version: Trunk → 40 Branch

Comment 3

3 years ago
bp-53085550-34c2-4b93-8237-5b2192150403 on ubuntu14.04
OS: Windows 8.1 → All


3 years ago
Crash Signature: [@ js::gc::StoreBuffer::isOkayToUseBuffer() ] → [@ js::gc::StoreBuffer::isOkayToUseBuffer() ] [@ void js::gc::StoreBuffer::putGeneric<js::ShapeGetterSetterRef>(js::ShapeGetterSetterRef const&)]
Duplicate of this bug: 1151013

Comment 5

3 years ago
It's not a problem with just Tree Style Tab.  I don't have that extension and I crashed repeatedly trying to start the browser after a prior crash.  I had to revert to yesterday's nightly.  I do have other extensions, but I don't know if any of them could be a contributor.


Comment 6

3 years ago
Also happens with Session Manager
Summary: Tree Style Tab crashes Nightly [@ js::gc::StoreBuffer::isOkayToUseBuffer() ] → Tree Style Tab and/or Session Manager crashes Nightly [@ js::gc::StoreBuffer::isOkayToUseBuffer() ]
Flags: needinfo?(jwalden+bmo)
Duplicate of this bug: 1148371
Duplicate of this bug: 1151263
If you run this in debug mode you get the following stack snippet:
#0  0x00007ffff2ec5629 in JS::PropertyDescriptorOperations<JS::Handle<JSPropertyDescriptor> >::assertValid (this=<optimized out>) at /home/tom/projects/mozilla-inbound/js/src/jsapi.h:2600
#1  0x00007ffff2eb9287 in js::NativeDefineProperty (cx=cx@entry=0x7fffd31f75d0, obj=(js::NativeObject * const) 0x7fffd2b46100 [object Sandbox] delegate, id=$jsid("TreeStyleTabUtils"), desc_=
    {obj = (JSObject *) 0x7fffd2b46100 [object Sandbox] delegate, attrs = 81, getter = 0x7fffcd280980, setter = 0x7ffff0e9de39 <writeToProto_setProperty(JSContext*, JS::HandleObject, JS::HandleId, JS::MutableHandleValue, JS::ObjectOpResult&)>, value = JSVAL_VOID}, result=...) at /home/tom/projects/mozilla-inbound/js/src/vm/NativeObject.cpp:1287
#2  0x00007ffff2eba0ef in js::NativeDefineProperty (cx=cx@entry=0x7fffd31f75d0, obj=..., obj@entry=(js::NativeObject * const) 0x7fffd2b46100 [object Sandbox] delegate, id=..., id@entry=$jsid("TreeStyleTabUtils"), value=..., 
    value@entry=JSVAL_VOID, getter=getter@entry=0x7fffcd280980, setter=<optimized out>, attrs=attrs@entry=81, result=...) at /home/tom/projects/mozilla-inbound/js/src/vm/NativeObject.cpp:1483
#3  0x00007ffff3277f90 in DefinePropertyOnObject (cx=cx@entry=0x7fffd31f75d0, obj=(js::NativeObject * const) 0x7fffd2b46100 [object Sandbox] delegate, id=..., id@entry=$jsid("TreeStyleTabUtils"), desc=
  {obj = (JSObject *) 0x7fffd2b46100 [object Sandbox] delegate, attrs = 81, getter = 0x7fffcd280980, setter = 0x0, value = JSVAL_VOID}, result=...) at /home/tom/projects/mozilla-inbound/js/src/jsobj.cpp:557

So what happens is that Tree Style Tabs uses something like Object.defineProperty(this, "TreeStyleTabUtils", {get: function() {} }).
`this` here is a sandbox with that writeToProto_setProperty JSSetterOp. Because of our weird behavior around those we take that JSSetterOp and use it as a setter instead of null. Not sure yet if this is somehow messing up the marking as well, but at least it causes this assert.
Crash Signature: [@ js::gc::StoreBuffer::isOkayToUseBuffer() ] [@ void js::gc::StoreBuffer::putGeneric<js::ShapeGetterSetterRef>(js::ShapeGetterSetterRef const&)] → [@ js::gc::StoreBuffer::isOkayToUseBuffer() ] [@ void js::gc::StoreBuffer::putGeneric<js::ShapeGetterSetterRef>(js::ShapeGetterSetterRef const&)] [@ js::NativeObject::putProperty(js::ExclusiveContext*, JS::Handle<js::NativeObject*>, JS::Handle<j&hellip;

Comment 10

3 years ago
Here's a crash report for Session Manager as well, since only crash reports for Tree Style Tab have been posted above:


Comment 11

3 years ago
I am getting this without having the add-on installed. Even with a clean profile I got it once.


Comment 12

3 years ago
All of the crash reports you just linked show that the Session Manager extension was enabled (extension ID 1280606b-2510-4fe0-97ef-9b5a22eafe30).

Comment 13

3 years ago
Indeed - Sorry - I was referring at Tree Style Tab Add-on ( I only saw after that session manager was another cause  - was early in the morning before coffee.. Sorry again :S)

Comment 14

3 years ago
Oh, no problem.  The bug was originally reported against TST and the title was only changed to include Session Manager in comment #6, after all, so I don't blame you.  Just thought I'd point it out though.
The signatures listed: one for each Win, Mac and Linux account for the top 3 crashers on Nightly.  All three are startup crashers associated with add-ons.

Highest Add-on correlations:

On Windows:
50% Tree Style Tab
50% Session Manager
44% Adblock Plus

On Mac:
52% Session Manager
47% Tree Style Tab
48% NoScript
30% Greasemonkey
24% Web Developer
24% BetterPrivacy

On Linux:
78% Tree Style Tab
55% Session Manager
38% Greasemonkey
Keywords: topcrash
I checked the Session Manager code and every object (two objects) that has a getter function also has a setter function as such I'm not sure what change in bug 1138499 is causing the problem.

Session Manager only triggers this crash if it is set to display a prompt window on startup.  I've noticed that a "sessionStartup.onceInitialized.then" call fires immediately on startup under Firefox 40.  Under Firefox 39, it waits until Session Manager's prompt is dismissed.  I'm not sure why that is or if it has anything to do with this crash.

I'm also seeing this is a Session Manager log trace when Session Manager tries to open a browser window shortly before the crash.  Again it could be a red herring.

EXCEPTION - {Window is not tracked} 
exports.loadBrowserWindow/SessionManagerWindow.updateUndoButton@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/u6016752/AppData/Roaming/Mozilla/Firefox/Profiles/n98m9xq6.test/extensions/%7B1280606b-2510-4fe0-97ef-9b5a22eafe30%7D.xpi!/bootstrap.js -> jar:file:///C:/Users/u6016752/AppData/Roaming/Mozilla/Firefox/Profiles/n98m9xq6.test/extensions/%7B1280606b-2510-4fe0-97ef-9b5a22eafe30%7D.xpi!/packages/browserWindowOverlay.js:1325:18
exports.loadBrowserWindow/SessionManagerWindow.onTabOpenClose@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/u6016752/AppData/Roaming/Mozilla/Firefox/Profiles/n98m9xq6.test/extensions/%7B1280606b-2510-4fe0-97ef-9b5a22eafe30%7D.xpi!/bootstrap.js -> jar:file:///C:/Users/u6016752/AppData/Roaming/Mozilla/Firefox/Profiles/n98m9xq6.test/extensions/%7B1280606b-2510-4fe0-97ef-9b5a22eafe30%7D.xpi!/packages/browserWindowOverlay.js:967:5
It's actually not only prompting on start up.  It's any time the Session Manager session window is opened.  I'm still tracking down what specific code is triggering the crash.
I think I found potentially what the problem is. My Session window loads three separate JavaScript files.  Each of these files uses the XPCOMUtils.defineLazyModuleGetter function to delay load a jsm module.  The problem appears to occur is the same jsm module is loaded in each of the three different files.

This got me to thinking so I tried to do the same exact XPCOMUtils.defineLazyModuleGetter function twice in a row.  That immediately causes a crash.

So for example if the following is in my a Javascript file loaded by my addon, Firefox crashes:

XPCOMUtils.defineLazyModuleGetter(this, "log", "chrome://sessionmanager/content/modules/logger.jsm");
XPCOMUtils.defineLazyModuleGetter(this, "log", "chrome://sessionmanager/content/modules/logger.jsm");

If I remove one of the lines or I change the second parameter to a different name, it won't crash.  Since XPCOMUtils.defineLazyModuleGetter simply calls XPCOMUtils.defineLazyGetter I tried the following, which also crashed:


XPCOMUtils.defineLazyGetter(this, "test", function() { return ""; }); 
XPCOMUtils.defineLazyGetter(this, "test", function() { return ""; }); 

This only happened in dialog "pop-up" windows.  If I add the above code to scripts that load in browser windows it works fine.

The problem is when I tried to make a simplified test case, it didn't crash so there must be something else involved.
I've uploaded a developers channel version of Session Manager which no longer crashes by removing "duplicate" defineLazyModuleGetter calls.

Comment 20

3 years ago
This crash is caused by a change in rev 034027f41aaf. Fix coming.
Flags: needinfo?(jorendorff)

Comment 21

3 years ago
Created attachment 8589369 [details] [diff] [review]
Fix "Assertion failure: !has(SHADOWABLE)" and subsequent GC crashes introduced in rev 034027f41aaf
Attachment #8589369 - Flags: review?(efaustbmo)


3 years ago
Assignee: nobody → jorendorff

Comment 22

3 years ago
Created attachment 8589370 [details] [diff] [review]
Fix "Assertion failure: !has(SHADOWABLE)" and subsequent GC crashes introduced in rev 034027f41aaf
Attachment #8589370 - Flags: review?(efaustbmo)


3 years ago
Attachment #8589369 - Attachment is obsolete: true
Attachment #8589369 - Flags: review?(efaustbmo)

Comment 23

3 years ago
Created attachment 8589371 [details] [diff] [review]
Fix "Assertion failure: !has(SHADOWABLE)" and subsequent GC crashes introduced in rev 034027f41aaf
Attachment #8589371 - Flags: review?(jwalden+bmo)


3 years ago
Attachment #8589370 - Attachment is obsolete: true
Attachment #8589370 - Flags: review?(efaustbmo)
Attachment #8589371 - Flags: review?(jwalden+bmo) → review+

Comment 24

3 years ago
With a little luck, the code being modified in this patch, and 150+ lines in both directions, will all be gone in a week. The axe falls in bug 1125624. I probably just jinxed it. Oh well.

Comment 25

3 years ago

Comment 26

3 years ago

Comment 27

3 years ago
Tried your try Build looks good neither Session Manager nor Tree Style Tab nor Noscript Crash anymore :)

Comment 28

3 years ago
As of now, the try server run is all green (a minor miracle), but with Windows results >1hr "overdue". I pushed it to inbound in order to get the fix into Nightly. I can't stop jinxing things somebody get help.

Comment 29

3 years ago
TST still crashing for me on Nightly (did a pull -vu and rebuild about an hour ago,) Linux.


Disabling Tree Style Tabs stops the crashing.

(Other reports generated from around the same time:
The fix is not in Nightly yet, is your build based on


3 years ago
Duplicate of this bug: 1150837

Comment 32

3 years ago
(In reply to Tom Schuster [:evilpie] from comment #30)
> The fix is not in Nightly yet, is your build based on

Ah - my apologies; no; I'm on

Comment 33

3 years ago
How high are the chances for this hitting today's nightly?
(In reply to Daniel from comment #33)
> How high are the chances for this hitting today's nightly?

It won't make today's Nightly, builds are already in progress. Maybe there will be a respin but that's up to the sheriffs.
Flags: needinfo?(jwalden+bmo)
Last Resolved: 3 years ago
status-firefox40: affected → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla40

Comment 36

3 years ago
Can confirm the latest nightly fixes the issue! 
Thanks for the fix!
Verified from crash stats as well. No crashes with builds since the fix landed.
status-firefox40: fixed → verified
tracking-firefox40: ? → ---
You need to log in before you can comment on or make changes to this bug.