694011 - Add-on process keeps crashing on async message

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Here is an output I see:

info: @@@@@@@@@@@@@@@@@@ jep4repl@jetpack:api-utils/chrome/notifications {"id":null,"title":"","text":"hello","iconURL":""} [object ContentFrameMessageManager @ 0x103c96c40 (native @ 0x103ed0fd0)]
WARNING: shutting down early because of crash!: file /builds/slave/h-osx64-dbg/build/dom/ipc/ContentChild.cpp, line 554
WARNING: content process _exit()ing: file /builds/slave/h-osx64-dbg/build/dom/ipc/ContentChild.cpp, line 599

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I don't quite understand why add-on process crashes, but I'm looking into this. I'll post updates once I'll have them.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

So I can't really narrow down this too much, but what I observe is that first few messages go both ways fine, but in some cases `sendAsyncMessage` crashes firefox. It could be as message from chrome to add-on so other way round.

Comment 3

[Eddy Bruel [:ejpbruel]]

Is there a specific sequence of steps that reproduces this issue? It's certainly possible that there are still some pieces of code in the remote process that I assumed to be unreachable which still rely on there being an associated <browser> element, which is now no longer there. Without further information, this would be my first guess as to what causes the problem.

One way to shed more light on this bug is to attach an instance of gdb to the remote process and obtain a stack trace at the point of crashing. You can do this yourself if you want (if you're not familiar with how to do this, ping me on irc), but I suspect you'll want to wait until next week, when I offically come back from my holiday, and I will look into it for you! ;-)

By the way, great job merging your prototype with mine! Happy to see we're making progress!

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Here is the way crash can be reproduced:

1. Use following branch of SDK: https://github.com/Gozala/addon-sdk/tree/e10s/tabs
2. Use following build of Firefox:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/holly-macosx64-debug/1317158582/
3. Run cfx with a following command (--e10s indicates that it should run in multiprocess mode):
cfx run -b your_path_to_ff --e10s

I used following add-on to test (please not that you need to use special (experimental/simple-loader) branch):
https://github.com/Gozala/jep4repl/tree/experimental/simple-loader

one you cfx is running with repl add-on in it, you can run following command to connect to the jetpack repl (rlwrap is optional):

rlwrap telnet localhost 4242

in the repl you can try to use few e10s-ified APIs:

// notifications
require('api-utils/addon/notifications').notify({ text: 'wohooo', onClick: console.log.bind(null, "I was clicked") })
// tabs
require('api-utils/addon/tabs').tabs

Usually sending few notifications and clicking some of them causes next one to crash. Although, not always. If you try to require tabs API as specified above you can just open new tabs navigate to some address, this will cause many messages to be send to the add-on process that at some point crashes it, again I can't detect any pattern here.

If you don't want to use repl addon, you could just create very simple add-on that just does following `var tabs = require('api-utils/addon/tabs').tabs`.

Comment 5

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

ejpbruel I think your change have fixed the issue, everything works like charm with all the e10s-ified code I have for now!