Crash when opening a new tab




2 years ago
2 years ago


(Reporter: Martin, Unassigned)


47 Branch

Firefox Tracking Flags

(Not tracked)




2 years ago
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160723131628

Steps to reproduce:

- Open a new tab
- "Show your top sites" is turned on
- Via sync, the history contains entries never viewed with firefox on this machine
- Environment: FreeBSD 10.3, ports up-to-date (firefox-47.0.1_2,1)

Actual results:

- Because of the new history entries, some of the preview items have not been rendered
- Firefox start a plugin-container to render the missing preview items
- After several seconds, firefox and the plugin-container crash, both leaving core files
- In .xsession-errors, the following lines appear:

^G[Child 13251] ###!!! ABORT: Aborting on channel error.: file /usr/tmp/.../hal/z/SRC/FreeBSD-ports/head/www/firefox/work/firefox-47.0.1/ipc/glue/MessageChannel.cpp, line 2027
[Child 13251] ###!!! ABORT: Aborting on channel error.: file /usr/tmp/.../hal/z/SRC/FreeBSD-ports/head/www/firefox/work/firefox-47.0.1/ipc/glue/MessageChannel.cpp, line 2027

Sometimes, this works.

The crashes started appearing without at a time when no related software (libraries etc.) had been updated.

Expected results:

- The missing preview items should be rendered successfully at least as far as the related sites can be reached
- No crash should occur
- After a while, plugin-container should exit


2 years ago
OS: Unspecified → FreeBSD
Hardware: Unspecified → x86_64

Comment 1

2 years ago
Do you have a stacktrace?
Flags: needinfo?(la5lbtyi)

Comment 2

2 years ago
There're more details for this bug downstream (See Also). If this is indeed e10s issue and the reporter wants to track it down rather than disable e10s I'd suggest debugging on mozilla-central which may have more fixes.

(In reply to Loic from comment #1)
> How_to_get_a_stacktrace_for_a_bug_report

That page is mostly useless for Tier3 platforms and any distribution without prebuilt symbols. It doesn't even link how to build from source[1] where symbols are enabled by default.


Comment 3

2 years ago
@Loic: Unfortunately, with a standard FreeBSD port build I don't get symbols - so effectively no useful stack trace.

@Jan: Strange... I have

   Multiprocess Windows 	0/1 (Disabled)

But it still does spawn the plugin container (I just had a crash again: open new tab -> type "about:support" <RETURN> -> then it crashed. So the communication between firefox and plugin-container is o.k. for several seconds until the abort statement is executed.)

Another idea: In the source code I see that the abort is executed because the communication between the processes seems to go awry. Is there a possibility to turn on tracing of this communication so that I could send you a trace?

Also, given the "multiprocess windows" setting above, how would I be able to *really* turn off the usage of plugin-container for rendering empty tiles in a new tab?

Using mozilla-central: I'd rather stick with the FreeBSD ports infrastructure because I don't want to diverge too far from it. But conversely, are there any cherry-picks I could try to apply from upstream?

One more datum: I disabled all extensions -> still the same crash behavior.
Component: Untriaged → Tabbed Browser

Comment 4

2 years ago
If e10s is disabled I don't know why fetching the previews would start a plugin-container process. Maybe Drew or Mike can help figure out what's going on here?

(Without a solid hypothesis about what's wrong we don't know where this belongs and need to do further triage, so back to Untriaged it goes.)
Component: Tabbed Browser → Untriaged
Flags: needinfo?(mconley)
Flags: needinfo?(adw)

Comment 5

2 years ago
Fetching previews for the newtab page uses the background thumbnailer, which uses a remote xul:browser in the hidden window regardless of whether e10s is enabled for tabs.
Flags: needinfo?(adw)

Comment 6

2 years ago
Some more observations:

- If I have my automatic plugin-container process killer script running (it looks for plugin-container(s) every two seconds and, if it finds some, kills them) it seems that whenever I open a new tab, as many plugin-containers as there are unrendered preview tiles are being killed sequentially.

- If I change the settings for new tabs (top right of a new tab) from "show your top sites" to "show blank page" and close the new tab, a plugin-container is being spawned the first time I open a new tab (which however does not show anything). For subsequent new tabs, no plugin-container is spawned any more until I change said setting back to "show your top sites".
Flags: needinfo?(la5lbtyi)

Comment 7

2 years ago
Maybe this scenario helps.

- Of 15 preview tiles, only one, for, is not rendered.
- I open the history sidebar and remove all entries belonging to
- I stop and restart firefox (I need to do this because the changed history is not immediately reflected in newtab)
- I open a new tab. Now there is no tab any more for, instead another. All 15 are rendered.
- I close the new tab.
- I stop firefox. Note that I have firefox set to redisplay the previous tabs on restart.
- I stop my killer script.
- I empty .cache/mozilla/firefox/<profile>/thumbnails.
- I restart firefox. The previous tabs are redisplayed.
- I open a new tab. It shows 15 empty preview tiles.
- The plugin-container starts running.
- Tile by tile, all 15 previews are filled.
- I surf to and open a bunch of pages there in order to get the address high enough in the history hit list. Note that opening the page directly creates a preview tile in thumbnails.
- I close
- I close firefox.
- I again empty the thumbnails cache dir.
- I restart firefox.
- I open a new tab.
- Firefox and the plugin-container crash, presumably while trying to render the preview for

Comment 8

2 years ago
To be more precise with the last point:
- is in position 11 (eleven)
- The first 10 preview tiles are rendered sequentially. When reaching, firefox and the plugin-container crash.
- I restart my killer script.
- I restart firefox.
- The killer script is executed 5 times, for the five as-yet-unrendered tiles (amazon plus the four following it)

Comment 9

2 years ago
One more note: It seems that for, a preview tile is never created, even if I go to that address directly (and thus see the page). So my statement above that opening automatically creates a preview tile is wrong. Maybe I saw this with another address.
adw is right in comment 5 - the thumbnailer uses plugin-container with or without e10s enabled, and has so for quite a while.

What'd be most useful, I think, are some crash reports from about:crashes. I think that'd be the fastest way of knowing what's happening here.
Flags: needinfo?(mconley) → needinfo?(la5lbtyi)

Comment 11

2 years ago
about:crashes -> "The address is not valid"


2 years ago
Flags: needinfo?(la5lbtyi)
Huh. Sounds like whoever made your build of Firefox disabled crash reporting.

That's really going to make things difficult here. :/ Can you try using a binary from ?
Flags: needinfo?(la5lbtyi)

Comment 13

2 years ago
(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #12)
> Huh. Sounds like whoever made your build of Firefox disabled crash reporting.
> That's really going to make things difficult here. :/ Can you try using a
> binary from ?

I'm not super familiar with freebsd, but if this isn't possible, can you compile the firefox port with debug symbols and see if you can get the crash in gdb so we get a symbolicated crash stack? I *think* you want but as I said, not too familiar with freebsd.

Comment 14

2 years ago
I rebuilt the FreeBSD port with a different setting, namely to use the bundled cairo instead of the one from FreeBSD ports. Now rendering works and the crash seems gone.

So it is in fact a FreeBSD-specific issue; probably the option to use the port version of cairo should be removed there; it is however not the default.

Thank you all anyway for the help you provided.
Last Resolved: 2 years ago
Flags: needinfo?(la5lbtyi)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.