1284427 - Crash in Abort | X_CopyArea: BadDrawable (invalid Pixmap or Window parameter); 4 requests ago | mozalloc_abort | NS_DebugBreak | X11Error

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Sammy Atmadja]

This bug was filed from the Socorro interface and is 
report bp-8426fd10-0687-4ddc-9399-94d6b2160627.
=============================================================

I'm running firefox from a remote server via ssh with X forwarding, to a Cendio Thinlinc X server, which is based on (Tiger) VNC. On startup firefox usually crashes 3-4 times in a row, and eventually starts up normally. I do not experience any problems after a succesful start.

I have tried 48.0b5, same problem.

When running firefox locally (not via ssh) the problem does not occur.

Comment 1

[Karl Tomlinson (:karlt)]

Did this occur with Firefox 46?

Does changing gfx.xrender.enabled to true in about:config work around the issue?

Comment 2

[Sammy Atmadja]

(In reply to Karl Tomlinson (back 18 July :karlt) from comment #1)
> Did this occur with Firefox 46?

No, Firefox 47 was the first version with this bug.

> 
> Does changing gfx.xrender.enabled to true in about:config work around the
> issue?

I will have to try that. I'll report back soon.

Comment 3

[Sammy Atmadja]

Changing gfx.xrender.enabled to true seems to completely eliminate the
startup crashes. As a bonus, using my setup as described in the bug
description, Firefox seems much more responsive. Scrolling feels much
smoother. Playing video no longer blocks the user interface.

Comment 4

[Andrew Comminos [:acomminos]]

Can you reproduce this issue on Nightly? We've made our remote X handling quite a bit more robust recently.

Comment 5

[Sammy Atmadja]

With 50.0a1 the startup crash seems to be gone. Starting firefox over ssh a few times works, so this is by no means an exhaustive test. However, nightly feels much slower/very sluggish compared to 47 with xrender enabled. There is significant lag while scrolling. I tried opening a page containig video (youtube) to see if the user interface remained responsive, but the tab crashed after a few seconds.

Comment 6

[Andrew Comminos [:acomminos]]

Thanks for checking! The slowdown is to be expected to some degree, as drawing and composition using XRender will be inherently faster over a network due to less raster transfers.

I'm going to close this as the crash itself is gone- bug 1281817 talks about potentially using XRender over remote X.