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.
I restarted the browser and it's still happening. My build is from mozilla-central ab137ddd3746.
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.
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
I get a crash also if I click on a username in Bugzilla and then select "Profile".
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.
Does anything appear in about:crashes?
(In reply to Bill McCloskey (:billm) from comment #6) > Does anything appear in about:crashes? No.
(In reply to Nicholas Nethercote [:njn] from comment #5) Confirmed. target="_blank" seems to be a trigger of this crash.
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
This still does not appear to be working correctly for me, although it does not crash.
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.
(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.
> 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.
9 months ago
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?
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.
Closing based on comment 16, if the original bug still occurs :njn, please let us know.