1098688 - Content process crashes when doing "add to calendar" from an email in Gmail with Tree Style Tab enabled

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Nicholas Nethercote [inactive]]

I just tried doing "add to calendar" for a calendar request email in Gmail, and my content processes crashed. It seems to be repeatable. Here's the output I got on the console:

> ** (plugin-container:20672): CRITICAL **: gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed
> IPDL protocol error: Handler for CreateWindow returned error code
> 
> ###!!! [Parent][DispatchInterruptMessage] Error: (msgtype=0x1E0006,name=PBrowser::Msg_CreateWindow) Processing error: message was deserialized, but the handler returned false (indicating failure)
> 
> [Parent 2640] WARNING: pipe error (3): Connection reset by peer: file ../../../ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 457
> 
> ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv

This is in a trunk build from yesterday.

Comment 1

[Nicholas Nethercote [inactive]]

I restarted the browser and it's still happening. My build is from mozilla-central ab137ddd3746.

Comment 2

[Nicholas Nethercote [inactive]]

Still happens with mozilla-central revision a52bf59965a0. It seems to be related to something in my profile -- I tried two other profiles and I can't reproduce with them.

Comment 3

[Nicholas Nethercote [inactive]]

I tried following the instruction at https://wiki.mozilla.org/Electrolysis/Debugging to debug the child. When the crash happened all I got was this:

> Program received signal SIGTERM, Terminated.
> pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> 185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
> (gdb) [Parent 411] WARNING: No docshells for remote frames!: file ../../../dom/base/nsFrameLoader.cpp, line 511

When I tried `bt` I just got this:

> #0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> Cannot access memory at address 0x7fff1f97f468

Comment 4

[Nicholas Nethercote [inactive]]

I get a crash also if I click on a username in Bugzilla and then select "Profile".

Comment 5

[Nicholas Nethercote [inactive]]

Turns out this is a bad interaction between e10s and Tree Style Tab. If I disable either, the problem goes away.

So, steps to reproduce:

- Create a new profile in an e10s-enabled build of Firefox.

- Install Tree Style Tab from http://piro.sakura.ne.jp/xul/xpi/nightly/treestyletab.xpi.

- Restart.

- Log into Bugzilla.

- Click on a user name in Bugzilla and then select "Profile" from the dropdown

- The content process crashes.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Does anything appear in about:crashes?

Comment 7

[Nicholas Nethercote [inactive]]

(In reply to Bill McCloskey (:billm) from comment #6)
> Does anything appear in about:crashes?

No.

Comment 8

[YUKI "Piro" Hiroshi]

(In reply to Nicholas Nethercote [:njn] from comment #5)

Confirmed. target="_blank" seems to be a trigger of this crash.

Comment 9

[YUKI "Piro" Hiroshi]

After these changes, the crash problem reported on comment #5 seems to be fixed for me.
https://github.com/piroor/treestyletab/commit/66f16dde502f2d4c32b3ac4f346e0c88715e32af
https://github.com/piroor/treestyletab/commit/3663519efdfcf01d6717ade70b9ce56f935fa75b
https://github.com/piroor/treestyletab/commit/ddb87ab83ad9e86bf816659c430ded0b1dde5d29

Comment 10

[rizzo.g]

This fix introduces a regression: if javascript opens all the links in a page

$('a').each(function() { window.open($(this).attr('href')); });

those links gets nested one to each other, instead of opening all as child of the parent tab.
I reverted to the previous version and confirmed that this behavior changes with the newest release.

Comment 11

[Jerod Lycett]

This still does not appear to be working correctly for me, although it does not crash.

Comment 12

[Nicholas Nethercote [inactive]]

Jerod, you've recently marked two bugs I filed relating to add-ons as WONTFIX without any explanation: this one, and bug 1042965.

In my experience, this is not how these sorts of bugs is usually handled. Can you please explain why you did this? Thank you.

Comment 13

[Jerod Lycett]

(In reply to Nicholas Nethercote [:njn] (on PTO until January 4th) from comment #12)
> Jerod, you've recently marked two bugs I filed relating to add-ons as
> WONTFIX without any explanation: this one, and bug 1042965.
> 
> In my experience, this is not how these sorts of bugs is usually handled.
> Can you please explain why you did this? Thank you.

Sorry for my slow response. It was decided that with no dev response for 21 days that these bugs will be closed as WONTFIX.

Comment 14

[Nicholas Nethercote [inactive]]

> It was decided that with no dev response for 21 days that these bugs will be closed as WONTFIX.

"It was decided" -- who decided? Closing a bug like this just because there's no response is very much not the way things normally work in this Bugzilla. Unless there is evidence that the problem has been fixed, it should remain open.

Comment 15

[Andy McKay]

Piro, it looks like the bug in comment 5 was fixed in comment 9. It then seems to change into another bug. How would like to proceed with this bug?

Comment 16

[YUKI "Piro" Hiroshi]

I couldn't reproduce the problem anymore with the latest released version of TST 0.18.2016090802 on e10s-activated Nightly 51.0a1, Ubuntu 16.04LTS. I agree turn close this bug.

Comment 17

[Andy McKay]

Closing based on comment 16, if the original bug still occurs :njn, please let us know.