497355 - Assertion failure: STOBJ_GET_CLASS(obj) != &js_BlockClass, at /Users/moztest/comm/main/src/mozilla/js/src/jsscope.cpp:79

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mark Banner (:standard8)]

Attachment: Assertion stack

Running a debug build of latest-1.9.1 Thunderbird with the glodaquilla extension installed, I'm seeing:

Assertion failure: STOBJ_GET_CLASS(obj) != &js_BlockClass, at /Users/moztest/comm/main/src/mozilla/js/src/jsscope.cpp:79

which is then causing aborts.

Some info:
comm-central revision: d1a9b79cf5c2
mozilla-central revision: 9732452737d8
glodaquilla 0.2: https://addons.mozilla.org/en-US/thunderbird/addon/9873

I'm sending a message in the background and I think this assertion happens when its downloading a message and is going to display it.

Stack from "call DumpJSStack();" in gdb:

0 setPropertyAtoms(aProperties = [xpconnect wrapped nsISupportsArray @ 0x1d11c4c0 (native @ 0x1d029640)], aFolder = [xpconnect wrapped nsIMsgFolder @ 0x1d182760 (native @ 0x133d37b0)]) ["file:///Users/moztest/comm/main/tb/mozilla/dist/ShredderDebug.app/Contents/MacOS/modules/folderUtils.jsm":82]
    addAtom = [function]
    atomSvc = undefined
    Ci = [object nsXPCComponents_Interfaces @ 0x1e8b7d20 (native @ 0x1d476870)]
    Cc = [object nsXPCComponents_Classes @ 0x1330df70 (native @ 0x1d4cf3f0)]
    this = [object ChromeWindow @ 0x1c552a10 (native @ 0x1c5513e0)]
1 ftvItem_getProperties(aProps = [xpconnect wrapped nsISupportsArray @ 0x1d11c4c0 (native @ 0x1d029640)]) ["chrome://messenger/content/folderPane.js":1361]
    this = [object Object]
2 ftv_getRowProperties(aProps = [xpconnect wrapped nsISupportsArray @ 0x1d11c4c0 (native @ 0x1d029640)], aIndex = 0) ["chrome://messenger/content/folderPane.js":578]
    this = [object Object]

gdb backtrace attached.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #0)
> Stack from "call DumpJSStack();" in gdb:
> 
> 0 setPropertyAtoms(aProperties = [xpconnect wrapped nsISupportsArray @
> 0x1d11c4c0 (native @ 0x1d029640)], aFolder = [xpconnect wrapped nsIMsgFolder @
> 0x1d182760 (native @ 0x133d37b0)])
> ["file:///Users/moztest/comm/main/tb/mozilla/dist/ShredderDebug.app/Contents/MacOS/modules/folderUtils.jsm":82]
>     addAtom = [function]
>     atomSvc = undefined
>     Ci = [object nsXPCComponents_Interfaces @ 0x1e8b7d20 (native @ 0x1d476870)]
>     Cc = [object nsXPCComponents_Classes @ 0x1330df70 (native @ 0x1d4cf3f0)]
>     this = [object ChromeWindow @ 0x1c552a10 (native @ 0x1c5513e0)]

http://hg.mozilla.org/comm-central/file/f1fcff5eb061/mailnews/base/util/folderUtils.jsm#l82

> 1 ftvItem_getProperties(aProps = [xpconnect wrapped nsISupportsArray @
> 0x1d11c4c0 (native @ 0x1d029640)])
> ["chrome://messenger/content/folderPane.js":1361]
>     this = [object Object]

http://hg.mozilla.org/comm-central/file/f1fcff5eb061/mail/base/content/folderPane.js#l1361

> 2 ftv_getRowProperties(aProps = [xpconnect wrapped nsISupportsArray @
> 0x1d11c4c0 (native @ 0x1d029640)], aIndex = 0)
> ["chrome://messenger/content/folderPane.js":578]
>     this = [object Object]

http://hg.mozilla.org/comm-central/file/f1fcff5eb061/mail/base/content/folderPane.js#l578

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Gary: is that meant to say that these things are mail-specific, and shouldn't block the release of Firefox 3.5?

Comment 3

[Mike Shaver (:shaver emeritus)]

Unlikely to be mail-specific, but hard to tell without a smaller test case.  Given that it uses let, I wouldn't block on it for 1.9.1, though I'd definitely take a fix for it in 1.9.1.1 for tbird and other add-on authors.

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #2)
> Gary: is that meant to say that these things are mail-specific, and shouldn't
> block the release of Firefox 3.5?

(In reply to comment #3)
> Unlikely to be mail-specific, but hard to tell without a smaller test case. 
> Given that it uses let, I wouldn't block on it for 1.9.1, though I'd definitely
> take a fix for it in 1.9.1.1 for tbird and other add-on authors.

Shaver is right (unlikely to be mail-specific).

Comment 5

[Kent James (:rkent)]

I think this is the crash I was seeing in my patch to bug 257415. Unfortunately though it was 90% reliable when I was working on that bug 5 days ago, I can't seem to get it to crash today - and I have not updated my tree since then. If I can get it to start crashing again, I'll work on a regression range.

Comment 7

[Mark Banner (:standard8)]

Adding tb3needs as I've seen this on branch with and without the extension installed (probably more prevalent with gloda running) and it has also been seen on trunk.

Even if it doesn't show up in release builds it is a pain for development as it aborts.

Comment 8

[Mark Banner (:standard8)]

I think this is a regression from bug 496605. I haven't had a problem with a mozilla-1.9.1 changeset just before that landed (af6a737e35c4). I'll be using that more now I think its a good changeset as that is the only way I will be able get a debug build working on the branch that isn't crashing every time I try and do things.

Therefore I think the regression range is:

http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-06-08+10%3A47%3A55&enddate=2009-06-08+10%3A47%3A57

Comment 9

[Blake Winton (:bwinton) (:☕️)]

I've run into this a bunch while running ShredderDebug, and have found that running 3.0b2 and letting it download my email will prevent the bug from re-appearing.

I don't know if that's useful information, so if there's anything else I can do to help when I run across it again, please let me know.

Comment 10

[Mark Banner (:standard8)]

I've just had the assertion occur whilst using mozilla-1.9.1 changeset af6a737e35c4. So I think bug 496605 isn't what caused it, but I think it makes it a lot worse.

Comment 11

[Boying Lu]

In my environment, This bug is related to following javascript codes ( in mail/base/content/mailWindow.js):

     this._activeProcesses.forEach(function (element) {
          if (element.state ==
              Components.interfaces.nsIActivityProcess.STATE_INPROGRESS &&
              element.percentComplete != -1) {
            currentProgress += element.percentComplete;
            ++progressCount;
          }

The related bug is bug 491013

Comment 12

[Brendan Eich [:brendan]]

Igor or Jim could field this one.

/be

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

Attachment: do not lose attributes when XDR tripping let blocks

The XDR round-tripping was losing an arguably important attribute, at least as far as I, a non-big-city-lawyer, can tell.

BindLet in jsparse.cpp js_DefineNativeProperty's with the attributes JSPROP_ENUMERATE, JSPROP_PERMANENT, and JSPROP_SHARED, but js_XDRBlockObject in jsobj.cpp js_DefineNativeProperty's leaves out JSPROP_SHARED.  JSPROP_SHARED appears to be important to js_SetPropertyHelper so that it calls js_SetSprop so that block_setProperty gets called rather than going off into the explosive weeds of js_GetMutableScope.

It's not immediately obvious to me how to test this, so I'd be very appreciative if someone on the JS team could take this from here or at least provide me with feedback on how to test this and whether the fix is really a fix or just a lucky placebo.

Thunderbird would love to code freeze for our beta 3 on tuesday, and it would be really nice to have this fix.  I have not traced what would happen in a non-debug build that does not die on the assertion; it's possible we luck out, but I think a fix would be nicer.

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

Uh, but I should say I had a thunderbird that was dying quite reliably without the patch.  Then I applied the patch and it did not die.  Then I un-applied the patch and it died.  Then I applied the patch and it did not die.

Comment 15

[Mike Shaver (:shaver emeritus)]

Comment on attachment 388043 [details] [diff] [review]
do not lose attributes when XDR tripping let blocks

asking for igor's review

Comment 16

[Mike Shaver (:shaver emeritus)]

Let's get this on the trunk, yo.

Comment 17

[Brendan Eich [:brendan]]

:asuth, thanks for the fix. You may be a small-town country lawyer but to me you are worth more than a big city lawyer.

/be

Comment 18

[Andrew Sutherland [:asuth] (he/him)]

pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/3a92866bebf3

Comment 19

[Andrew Sutherland [:asuth] (he/him)]

The trunk did not explode, marking fixed because it's on the trunk.  Will request 1.9.1.1 approval after some baking.

If anyone has a reason why we couldn't land this on the 1.9.1 branch sometime this week-ish (TB3 tentative firm code freeze is tomorrow (7/14) with target ship date of (7/21)) please let us know so we can figure out if we'll need to do any branching/build tricks.

Comment 20

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 388043 [details] [diff] [review]
do not lose attributes when XDR tripping let blocks

This has baked in a nightly.  That's not a tremendous amount of baking, but I think this is more of a correctness issue affecting chrome than a change with cascading far-reaching effects.  It would be great if this could land on the 1.9.1 branch in the near future.  We apparently do cut our own branch for Thunderbird builds, so it's not the end of the world if we have to land it on our branch for beta 3.

Comment 21

[Mike Shaver (:shaver emeritus)]

Comment on attachment 388043 [details] [diff] [review]
do not lose attributes when XDR tripping let blocks

It will need to wait until we're done with the tree for the emergency 3.5./1.9.1.1 release that's underway.  You should land on your minibranch, and then we'll come back to this for 1.9.1.2.  Thanks for the patch!

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 388043 [details] [diff] [review]
do not lose attributes when XDR tripping let blocks

a1912=beltzner

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

pushed to mozilla-1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d05d7bcc0c3b

Comment 24

[juan becerra [:juanb]]

Andrew, Mark, anyone, could you help us verify the fix? We are trying to verify this for 3.5.2 (build1) candidates.

Comment 25

[Mark Banner (:standard8)]

(In reply to comment #24)
> Andrew, Mark, anyone, could you help us verify the fix? We are trying to verify
> this for 3.5.2 (build1) candidates.

I can certainly say I've not had another instance of it since it landed on 1.9.1. As there were never any exact steps to reproduce otherwise it is kinda hard to say anything else.

Comment 26

[Josh Geenen (:pi)]

(In reply to comment #24)
> Andrew, Mark, anyone, could you help us verify the fix? We are trying to verify
> this for 3.5.2 (build1) candidates.

For a while I was able to hit this bug every time I started Thunderbird 3.0b3pre build with --enable-debug on two machines using Linux.  After manually applying the patch the problem went away.