717521 - Moving the map in Bing Maps locks my X11

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Julien Wajsberg [:julienw]]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0a2) Gecko/20120110 Firefox/11.0a2
Build ID: 20120110042006

Steps to reproduce:

I went to Bing Maps (link from the Bing homepage): http://www.bing.com/maps/?v=2&cp=43.50529205553157~4.723239421844476&lvl=10&dir=0&sty=h&where1=Plage%20de%20Piemanson%2C%20Bouches-du-Rh%C3%B4ne%2C%20France&FORM=hphot4&mkt=fr-fr

Then I tried to move the map.


Actual results:

My X locked down. The mouse could still move, but the cursor stayed the same everywhere and I could not do any action on either Firefox or my Window Manager (like clicking on the cross to stop Firefox, or switching desktops, etc.)

I could kill X using "ctrl alt pr.screen k" and then X restarted, which is different than other bugs I had before (though this difference could be because I also upgraded my system since then).

Sorry, I have not much more information; I tried to run Firefox and redirecting its output to a file, there was no interesting output (only one line), same for the X log file.

My driver is "nouveau" so this doesn't support hardware accelerations.


Expected results:

Nothing :-)

Comment 1

[Matthias Versen [:Matti]]

This is basically http://timeless.justdave.net/blog/143/ if your X server really died.

Comment 2

[Julien Wajsberg [:julienw]]

Yes, I really do thing the problem is in the nouveau driver, but, well, I don't know where to begin with.

Comment 3

[Matthias Versen [:Matti]]

is X starting to work again if you kill the Firefox process via commandline ?

Comment 4

[Julien Wajsberg [:julienw]]

I couldn't test this this morning but will test it asap.

Comment 5

[Julien Wajsberg [:julienw]]

X works again when I kill Firefox.

However, it was kind enough to give me a stacktrace :

[2802460.875] 0: /usr/bin/Xorg (xorg_backtrace+0x37) [0xb76ef197]
[2802460.875] 1: /usr/bin/Xorg (mieqEnqueue+0x185) [0xb76cd5f5]
[2802460.875] 2: /usr/bin/Xorg (0xb756a000+0x4fd35) [0xb75b9d35]
[2802460.875] 3: /usr/bin/Xorg (xf86PostMotionEventM+0xf9) [0xb75f7fa9]
[2802460.875] 4: /usr/bin/Xorg (xf86PostMotionEventP+0x86) [0xb75f80a6]
[2802460.875] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6225000+0x2cee) [0xb6227cee]
[2802460.875] 6: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6225000+0x3e0d) [0xb6228e0d]
[2802460.875] 7: /usr/bin/Xorg (0xb756a000+0x78791) [0xb75e2791]
[2802460.875] 8: /usr/bin/Xorg (0xb756a000+0x9ff62) [0xb7609f62]
[2802460.875] 9: (vdso) (__kernel_sigreturn+0x0) [0xb754c400]
[2802460.875] 10: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb73d8000+0x15fa2) [0xb73edfa2]
[2802460.875] 11: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb73d8000+0x1153a) [0xb73e953a]
[2802460.875] 12: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb73d8000+0x4f48b) [0xb742748b]
[2802460.875] 13: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (pixman_image_composite32+0x433) [0xb73ddc63]
[2802460.875] 14: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (pixman_image_composite+0xa6) [0xb73dddb6]
[2802460.875] 15: /usr/lib/xorg/modules/libfb.so (fbComposite+0x201) [0xb6fd9ab1]
[2802460.875] 16: /usr/lib/xorg/modules/libexa.so (0xb6fa8000+0x12c13) [0xb6fbac13]
[2802460.875] 17: /usr/lib/xorg/modules/libexa.so (0xb6fa8000+0xf070) [0xb6fb7070]
[2802460.875] 18: /usr/bin/Xorg (0xb756a000+0x10c7fb) [0xb76767fb]
[2802460.875] 19: /usr/bin/Xorg (CompositePicture+0x21e) [0xb766929e]
[2802460.876] 20: /usr/bin/Xorg (0xb756a000+0x10473c) [0xb766e73c]
[2802460.876] 21: /usr/bin/Xorg (0xb756a000+0xffb91) [0xb7669b91]
[2802460.876] 22: /usr/bin/Xorg (0xb756a000+0x3b6b7) [0xb75a56b7]
[2802460.876] 23: /usr/bin/Xorg (0xb756a000+0x292aa) [0xb75932aa]
[2802460.876] 24: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb7205e46]
[2802460.876] 25: /usr/bin/Xorg (0xb756a000+0x295e9) [0xb75935e9]

Comment 6

[Julien Wajsberg [:julienw]]

I forgot the first line, which was :

[2802460.875] [mi] EQ overflowing. The server is probably stuck in an infinite loop.

Comment 7

[Matthias Versen [:Matti]]

Please report that to you r x vendor

Comment 8

[Julien Wajsberg [:julienw]]

I just did.

However I also did additional tests: this bug doesn't happen with current Firefox 10 beta.

I saw on "about:support" that my graphic driver is blacklisted on FF10 but I'm not sure for FF11.

On FF11, I see :

WebGL Rendering: false
Hardware accelerated Windows: 0

On FF10, I see something like "Gallium driver blacklisted".

Anyway, even if my X driver has a bug, I think something should be done on Firefox side, at least blacklist something.

Please tell me if I can test with some preferences set/unset.

Comment 9

[Matthias Versen [:Matti]]

Try it with Firefox in the Firefox safemode. The safemode disables the hardware acceleration while you are in the safemode.
- http://support.mozilla.com/en-US/kb/Safe+Mode

Comment 10

[Julien Wajsberg [:julienw]]

ok, the bug happens also in Safe Mode.

Comment 11

[Julien Wajsberg [:julienw]]

Same on another Linux with an intel card (still no hw accel, the driver is too old).

I have no PC with hw accel under Linux so I can't try further, but the problem seems to be more important than expected, and it happens with Xorg 7.5 (on my Intel box) and 7.6 (on my nvidia box).

I got report of the same problem from someone using an ATI card (no hw accel).

Comment 12

[[:fabrice] Fabrice Desré]

On a Mac book pro running ubuntu (NVIDIA Corporation -- GeForce GT 330M/PCI/SSE2 -- 3.3.0 NVIDIA 280.13) I can't reproduce this bug. I have hw accel enabled

Scrolling the map is very slow and very CPU intensive, but doesn't lock X.

Comment 13

[Julien Wajsberg [:julienw]]

Fabrice, do you confirm it wasn't slow in Firefox 10 ?

Also, I saw that in my case, Xorg was taking 100% CPU. So maybe the only difference between you and me is that my computer is 8 years old and has only one core ?

Comment 14

[[:fabrice] Fabrice Desré]

I haven't checked with Firefox 10, but it's dead slow on a nightly.

Comment 15

[Julien Wajsberg [:julienw]]

Yep, I mean, if everything works like a charm in Firefox 10 for you too, maybe this could confirm we have the same problem.

And that it isn't related at all to hw acceleration.

Comment 16

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0

Confirming this with 11Beta3. 

1. Start Firefox with clean profile.
2. Load bing.maps.com
3. Move the map.

Firefox hangs on Ubuntu 11.10 for a good couple of seconds (over 20 for me every time). I reproduced this on two machines, both Ubuntu 11.10. This does not occur with Chrome or previous Firefox versions. 

Searching for a regression range.

Comment 17

[Virgil Dicu [:virgil] [QA]]

I can't reproduce with any Firefox 10. This must have regressed while 11 was in Nightly. To look over this tomorrow. Time constraints today.

Comment 18

[Julien Wajsberg [:julienw]]

Could you add some information about your video driver, type of computer (like how many cores), etc ?

I confirm that it doesn't happen for me with FF10.

Comment 19

[Virgil Dicu [:virgil] [QA]]

Last good nightly: 2011-12-19
First bad nightly: 2011-12-20

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d75ebb37080e&tochange=2afd7ae68e8b


Julian, Ubuntu 11.10 with Intel® Core™2 CPU 4400 @ 2.00GHz × 2, GeForce 8400 GS/PCI/SSE2, 64 bit system.

As previously reported, this works fine on other browsers (Opera, Chrome) and there is no info that might suggest anything wrong in about:support. Don't use hardware acceleration.

Comment 20

[Bas Schouten (:bas.schouten)]

The only thing I can see in there that might be related, however unlikely, is:

http://hg.mozilla.org/mozilla-central/rev/27cc305a5a1a

Do you think that's at all possible, roc?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, definitely.

(In reply to Virgil Dicu [:virgil] [QA] from comment #19)
> As previously reported, this works fine on other browsers (Opera, Chrome)

Opera and Chrome don't use X much for drawing, so they don't benefit from acceleration in X drivers but they also don't get affected nearly as much by bugs in X drivers.

Due to the extremely low quality of most X drivers, that's probably the right decision, but it's hard to change pre-GTK3 (due to the need to use X to render native widgets in GTK2).

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could probably work around this bug by disabling prerendering in some situations, but it's not clear to me exactly what that condition should be.

Comment 23

[Alex Keybl [:akeybl]]

What's the benefit to bug 702739 for Firefox desktop users? Is there anything preventing us from backing it out for FF11? Tracking and sending over to matspal in roc's absence (he r+'d bug 702739). We need to figure out what should be done here for the next FF11 beta (going to build 2/28 in less than a week).

Comment 24

[Mats Palmgren (inactive)]

I suspect Chris will be unhappy if we back it out.  If I understand the above correctly,
we still want the feature enabled for Android Fennec and B2G?  and all non-Linux
platforms?

We probably have #ifdef knobs to do that selection, but I'm not sure which.
Maybe MOZ_X11 and/or ANDROID ?

Comment 25

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This is critically important for UIs on b2g (not just Mozilla's).  Backing out bug 702739 would massively massively regress performance right before our big demo to the world.

I don't quite understand the issue here.  Is it buggy X drivers or too much prerendering or a combination thereof?

The benefit in general for desktop FF is that same as for b2g, in non-degenerate conditions: less texture/surface churn and less repainting.

Comment 26

[Mats Palmgren (inactive)]

Chris, do you know a combination of #ifdef knobs to keep it enabled for b2g and
Android, but disable it for "desktop Linux".  I feel that's my only option here
since I don't know enough about graphics to fix it.  We need at least a safe
workaround before 2/28 (per comment 23).

Comment 27

[Timothy Nikkel (:tnikkel)]

Bug 721905 indicates that Bing maps creates layers with huge visible regions. Maybe that is what is choking X here? Maybe we can put some sane limit on the size of layers that bug 702739 creates?

Comment 28

[Timothy Nikkel (:tnikkel)]

Or we could look into bug 721905 to see why that is happening in the first place.

Comment 29

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

We already restrict pre-rendering to frames that are the window size or smaller (modulo a small fudge factor).  This of course falls down if there are hundreds or thousands of window-sized frames, but so does lots of other stuff.

A layer-tree dump from bing maps would be very helpful.  Even better, one from before the badness started happening and one from after.

(In reply to Mats Palmgren [:mats] from comment #26)
> Chris, do you know a combination of #ifdef knobs to keep it enabled for b2g
> and
> Android, but disable it for "desktop Linux".  I feel that's my only option
> here
> since I don't know enough about graphics to fix it.  We need at least a safe
> workaround before 2/28 (per comment 23).

Yes, but this optimization should be globally helpful.  I'd like to find out what's falling over here.  We can keep that as a last resort I guess.

Comment 30

[Mihaela Velimiroviciu (:mihaelav)]

Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4

Reproducible also on Windows.

Comment 31

[u279076]

(In reply to Mihaela Velimiroviciu [QA] from comment #30)
> Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4
> 
> Reproducible also on Windows.

Mihaela, can you elaborate on this statement? Windows does not use X11 so I'm curious by your statement.

Comment 32

[Alex Keybl [:akeybl]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #25)
> This is critically important for UIs on b2g (not just Mozilla's).  Backing
> out bug 702739 would massively massively regress performance right before
> our big demo to the world.
> 
> I don't quite understand the issue here.  Is it buggy X drivers or too much
> prerendering or a combination thereof?
> 
> The benefit in general for desktop FF is that same as for b2g, in
> non-degenerate conditions: less texture/surface churn and less repainting.

Is b2g being demoed off of FF11? We're shipping XUL Fennec 10.0.3 in step with FF11 desktop, so that'll be unaffected as well. If we're only talking about gains in non-shipping products (and maintaining the current state on desktop), I'd prefer we just back out bug 702739.

Regardless, we'll want to choose a path that ensures this bug is resolved in time for our 2/28 beta 5 go-to-build (5 days away).

Comment 33

[Mats Palmgren (inactive)]

If you can reproduce this bug, please test mozilla-beta (Fx11) build:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-567a216a196b/

or mozilla-central (Fx13) build:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f9f8e9d356cd/

and let me know the results.  Thanks.

Comment 34

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I don't understand the "reference frame" in this code very well, but the original idea was to only prerender frames that were ~viewport size or smaller.  Should we be checking the nearest widget size here instead?  Very interested to see if your patch makes a difference.

Comment 35

[Timothy Nikkel (:tnikkel)]

The reference frame is the root root frame. It is the size of the top widget.

Comment 36

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #31)
> (In reply to Mihaela Velimiroviciu [QA] from comment #30)
> > Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4
> > 
> > Reproducible also on Windows.
> 
> Mihaela, can you elaborate on this statement? Windows does not use X11 so
> I'm curious by your statement.

STR:
1. Load www.bing.com/maps
2. Select Bird's view
3. Resize/move the map

Result:
After a few operations, firefox stops responding: cannot use the map nor any browser chrome elements

Comment 37

[Virgil Dicu [:virgil] [QA]]

(In reply to Mats Palmgren [:mats] from comment #33)
> 

Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0

Tested both builds. The issue is no longer reproducible. Tried to move, zoom in bing maps, used bird eye view, aerial view. Sometimes the map takes longer to load in aerial/bird eye view, but this also occurs on Chrome and previous Firefox versions (tried with 10).

Comment 38

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Mats Palmgren [:mats] from comment #33)
> If you can reproduce this bug, please test mozilla-beta (Fx11) build:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.
> com-567a216a196b/
> 
> or mozilla-central (Fx13) build:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.
> com-f9f8e9d356cd/
> 
> and let me know the results.  Thanks.

Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0

I cannot reproduce the issue with the try builds on Win 7.

Comment 39

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Timothy Nikkel (:tn) from comment #35)
> The reference frame is the root root frame. It is the size of the top widget.

Why does http://hg.mozilla.org/try/rev/00ec76a793da affect anything then?  We surely can't be creating widgets with dimensions > 4096 pixels ...

Comment 40

[Mats Palmgren (inactive)]

Attachment: wallpaper

Comment 41

[Timothy Nikkel (:tnikkel)]

Comment on attachment 601675 [details] [diff] [review]
wallpaper

I'd kinda like to know the answer to comment 39... but this is considered a temporary workaround until we can debug this properly and figure out what the real problem is?

Comment 42

[Mats Palmgren (inactive)]

Comment on attachment 601675 [details] [diff] [review]
wallpaper

Yeah, the first hunk is just wallpaper.  The 2nd hunk is an optimization
that can stay after we remove the wallpaper part.

Comment 43

[Timothy Nikkel (:tnikkel)]

Ok, let's split them up then, will reduce confusion for everyone.

Comment 44

[Alex Keybl [:akeybl]]

(In reply to Alex Keybl [:akeybl] from comment #32)
> Is b2g being demoed off of FF11? We're shipping XUL Fennec 10.0.3 in step
> with FF11 desktop, so that'll be unaffected as well. If we're only talking
> about gains in non-shipping products (and maintaining the current state on
> desktop), I'd prefer we just back out bug 702739.
> 
> Regardless, we'll want to choose a path that ensures this bug is resolved in
> time for our 2/28 beta 5 go-to-build (5 days away).

We've now missed the beta 5 go-to-build. We do not plan to take a forward fix for this issue. Nobody has addressed my previous comment above, so my assumption is that we plan to back out bug 702739. Please nominate ASAP.

Comment 45

[Mats Palmgren (inactive)]

Attachment: part 1, wallpaper

Comment 46

[Mats Palmgren (inactive)]

Attachment: part 2, optimization

Comment 47

[Timothy Nikkel (:tnikkel)]

Comment on attachment 601866 [details] [diff] [review]
part 1, wallpaper

r+ as a temp fix.

Comment 48

[Mats Palmgren (inactive)]

Attachment: Backout bug 702739 from mozilla-beta

This is the backout patch for mozilla-beta in case we need it.
Commit message:
"Backout bug 702739 (cset 27cc305a5a1a and 89a8e26f1df0).  r=tnikkel a=akeybl"

Comment 49

[Timothy Nikkel (:tnikkel)]

Comment on attachment 601879 [details] [diff] [review]
Backout bug 702739 from mozilla-beta

hg backout handled all of this without manual intervention except nsDisplayList.cpp. So I looked over those changes and they seemed fine.

Comment 50

[Mats Palmgren (inactive)]

Comment on attachment 601879 [details] [diff] [review]
Backout bug 702739 from mozilla-beta

[Approval Request Comment]
Regression caused by (bug #): bug 702739
User impact if declined: bad performance on some sites (probably few)
Testing completed (on m-c, etc.): none
Risk to taking this patch (and alternatives if risky): Low-risk, but very likely re-introduces the bad performance bug 702739 was meant to fix (which is particularly bad for b2g/fennec, see Chris' comments above).  The alternative is to take the wallpaper patch, which I think is quite low-risk.
String changes made by this patch: none

Comment 51

[Timothy Nikkel (:tnikkel)]

Comment on attachment 601867 [details] [diff] [review]
part 2, optimization

So the idea is that GetVisualOverflowRect is the same as MatrixTransformRect(GetVisualOverflowRectRelativeToSelf) and we avoid a call to MatrixTransformRect in the ShouldPrerenderTransformedContent case?

Comment 52

[Mats Palmgren (inactive)]

Yes

Comment 53

[Mats Palmgren (inactive)]

Comment on attachment 601867 [details] [diff] [review]
part 2, optimization

I think I'm mistaken about this being equivalent - the final overflow area
also has the contributions from nsIFrame::ComputePreserve3DChildrenOverflow
and what we want here is just the transform area.

Comment 54

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/391ac2bb95bd

Comment 55

[Alex Keybl [:akeybl]]

Comment on attachment 601879 [details] [diff] [review]
Backout bug 702739 from mozilla-beta

[Triage Comment]
Backing out to a known good state - approved for Beta 11. B2G and Fennec would see the greatest regression, but neither product is shipping off of the FF11 branch.

Comment 56

[Mats Palmgren (inactive)]

https://hg.mozilla.org/releases/mozilla-beta/rev/1a40f4e22979
https://hg.mozilla.org/releases/mozilla-beta/rev/9e043e84ffa2

Comment 57

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/391ac2bb95bd

Comment 58

[Andreas Gal :gal]

Please reopen original bug if you back this out.

Comment 59

[Mats Palmgren (inactive)]

It's only backed out on mozilla-beta (Fx11), it's not going to be backed out
anywhere else as far as I know.

Comment 60

[Andreas Gal :gal]

Comment  57 looked like the backout landed on mc hence my confusion.

Comment 61

[Mats Palmgren (inactive)]

No problem; you're absolutely right I should have updated bug 702739 with
a notice about the backout for Fx11.

Comment 62

[Julien Wajsberg [:julienw]]

Just to let you know that I tested the try build for FF13 in Comment 33 and it fixes the bug for me.

(I didn't really understand all that happened: backout of bug 702739 for FF11 and a real fix for FF13 ? What about FF12 ?)

Comment 63

[Julien Wajsberg [:julienw]]

The bug is still present in FF12 (Aurora branch).

Comment 64

[Mats Palmgren (inactive)]

Attachment: Wallpaper for Aurora (Fx12)

The trunk patch doesn't apply since "Part 1" in bug 724189 isn't on Aurora.

Comment 65

[Mats Palmgren (inactive)]

Comment on attachment 602858 [details] [diff] [review]
Wallpaper for Aurora (Fx12)

[Approval Request Comment]
Regression caused by (bug #): bug 702739
User impact if declined: bad performance on some sites (probably few)
Testing completed (on m-c, etc.): similar patch baked on trunk for a few days
Risk to taking this patch (and alternatives if risky): low risk
String changes made by this patch: none

Comment 66

[Alex Keybl [:akeybl]]

Comment on attachment 602858 [details] [diff] [review]
Wallpaper for Aurora (Fx12)

[Triage Comment]
Low risk and fixes a bug tracked/unresolved in FF12. Approved.

Comment 67

[Mats Palmgren (inactive)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4d6c44001fbf

Comment 68

[Mats Palmgren (inactive)]

Filed bug 733581 to figure out what the real problem is, per comment 39.

Comment 70

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0

Verified on Firefox 11 Beta 6 on Ubuntu 11.10. Zooming, moving the map in bing.maps works as expected. No hangs occurred. Also checked on Windows 7 and Mac OS.

Comment 72

[Julien Wajsberg [:julienw]]

verified on latest Aurora.