1067153 - self getter in webworker invoked on incorrect object

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[jason]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20140908190852

Steps to reproduce:

After a transient period of working correctly, calls to `self.postMessage` in a web worker fail with

```
TypeError: 'self' getter called on an object that does not implement interface WorkerGlobalScope.
```

I believe this happens after the first time that the garbage collector is run in the web worker. The self object, or something it depends on for posting messages, is probably be GC'ed when it shouldn't be.

Here's a JSBin that demonstrates the problem:

http://jsbin.com/cofore/1/edit?js,output

Watch your console, it will log the following error after a few round trips to the webworker:

```
TypeError: 'self' getter called on an object that does not implement interface WorkerGlobalScope.
```

The reason that I believe that this is a GC error is that adjusting how much memory gets allocated on every message changes how many messages can be sent before failure. (In the JSBin, try adjusting the upper limit of the for loop in the web worker code.)

You can prevent this error by closuring in `self` when the worker is created. See http://jsbin.com/cofore/2/edit?js,output which is a slight modification of the earlier JSBin.

I noticed this while working on https://www.desmos.com/calculator, which makes heavy use of web workers to keep the UI thread responsive while computing curve data.

The only other reference I've seen to this problem on the web is here: http://www.reddit.com/r/Khan/comments/2e4cof/typeerror_self_getter_called_on_an_object_that/ but it looks like it will affect practically anyone who uses web workers.

The problem first appeared in FF 33.


Actual results:

self.postMessage from a webworker becomes inoperable.


Expected results:

self.postMessage from a webworker should continue posting messages.

Comment 1

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]:

Jason, thank you for the bug report!

I can't reproduce a problem here in a current nightly (or Firefox 32 as you point out), but I do see it in a beta 33 build.

Presumably it's been fixed on trunk and we need to backport the fix to beta...  I'll try to figure out when this got fixed tomorrow.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and I can't reproduce in Aurora 34 either, so this seems to be 33-specific.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Fix range on mozilla-central nightlies: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=82df3654cd80&tochange=a91ec42d6a9c

Nothing in there is obviously jumping out at me as gc-related, though there are various bindings and xpconnect changes...

Comment 4

[Boris Zbarsky [:bzbarsky]]

One more thing before I head to bed:

When this fails, the "this" value passed to the getter is a "WorkerGlobalScopePrototype".  This is clearly bogus; the correct value to pass here is "undefined".

The call into the getter is from jitcode, so presumably this is a JIT bug of some sort.  That's why the number of loop iterations matters: it determines at what point we decide the code is hot enough to JIT.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, there are changes in that range to IonCaches for the getter case.  Specifically, bug 1033873.

And it was fixing a regression from bug 1022736, which landed for 33.

Eric, do we need to backport bug 1033873 to 33 as well?

Comment 6

[Boris Zbarsky [:bzbarsky]]

And I can confirm that applying the fix for bug 1033873 to a beta 33 tree fixes the testcase there, for what it's worth.

Comment 7

[Eric Faust [:efaust]]

Yeah, we just need to backport that fix. I agree. It looks like it should apply pretty trivially.

Comment 8

[Jan de Mooij [:jandem]]

If we backport, we also need bug 1046597...

Comment 9

[Eric Faust [:efaust]]

Attachment: Backported Fix

Approval Request Comment
[Feature/regressing bug #]: 1022736
[User impact if declined]: Correctness issues, strange JIT behavior
[Describe test coverage new/current, TBPL]: Landed in 34 already
[Risks and why]: Low: This is currently released.
[String/UUID change made/needed]: N/A

Carrying r+ from previously reviewed patches for 34, which applied unedited. This should fix the bug, and we should bring it back to 33.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2dbe6d8a5c30

Comment 11

[Ed Lee :Mardak]

We were also running into this problem of disappearing postMessages in our addon that uses ChromeWorkers. We were sending thousands of messages to multiple workers where the parent waits for acknowledgements from all, but the worker mysteriously never received some messages.

I've been trying to track down the problem the last few days and happened to bisect to find the regressing bug 1022736 as well as the fixing bug 1033873.

Looking at the regressing bug 1022736, it matches up with my bisecting:

last unregressed nightly 33
2014-06-19-03-02-03-mozilla-central
https://hg.mozilla.org/mozilla-central/rev/f78e532e8a10

first regressed nightly 33
2014-06-20-03-02-01-mozilla-central
https://hg.mozilla.org/mozilla-central/rev/bdac18bd6c74

Pushlog does indeed contain bug 1022736:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f78e532e8a10&tochange=bdac18bd6c74

Glad to see this is fixed on all versions now. :) Sorry I was so slow in tracking down the regressing and fixing bugs so that this could have been uplifted to 33 sooner. But then again, if I was slower by just a couple more days, we wouldn't have been running into this problem on Beta 33 either! ;)