GNOME Bugzilla – Bug 590690
"XID collision, trouble ahead" warnings with gdk_pixmap_foreign_new
Last modified: 2013-10-09 06:51:19 UTC
Please describe the problem: What's happening is: 1) Gecko uses gdk_pixmap_new to create a GdkPixmap, which is really a record of an X Pixmap that gets created. The GdkPixmap is recorded in a hash table keyed by XID. 2) Gecko passes the XID of the Pixmap from the GdkPixmap to libflashplayer. 3) libflashplayer calls gdk_pixmap_foreign_new_for_display to get a GdkPixmap record for the Pixmap XID (in the same process as Gecko). 4) gdk_pixmap_foreign_new_for_display creates a new GdkPixmap for the Pixmap XID and replaces the previous entry in the hash table for XID with the new GdkPixmap. This produces the "XID collision, trouble ahead" warning. I think this is mostly harmless, but when libflashplayer releases its reference to its GdkPixmap there will be no entry in the hash table and so gdk_pixmap_lookup and gdk_xid_table_lookup would return NULL for the XID, which could be unexpected as Gecko's GdkPixmap still exists. However, Gecko currently handles this. There is just a little inefficiency and some distracting warnings. I'm not really sure which part should change here. Possible solutions are: A) libflashplayer or gdk_pixmap_foreign_new_for_display could use gdk_pixmap_lookup() to check whether there is already a GdkPixmap for the same XID, and if so just add a reference to that rather than creating a new GdkPixmap. A possible issue with this is that XIDs get reused. If a GdkPixmap has previously been created with gdk_pixmap_foreign_new_for_display then gdk_pixmap_lookup() will return this GdkPixmap until its last reference is released. If the corresponding X Pixmap has been destroyed and a new Pixmap has been created with the same XID then before the last reference is released, then the old GdkPixmap should not be reused. There could be other problems with GdkPixmaps outliving their X Pixmaps anyway though, and so it is probably good practice to ensure that the foreign GdkPixmap is finalized before the X Pixmap is destroyed. This is probably the more efficient solution. B) gdk_pixmap_foreign_new_for_screen could check whether there is already a GdkPixmap for the same XID, and if so not replace the entry in the hash table with the new GdkPixmap. gdk_pixmap_lookup can also return the GdkWindow for a destroyed X Window, but that's really bug 581526 and would be easy to check for anyway. Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=497561 Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
It’s more trouble than mentioned. Here, the whole browser hangs for some 15 seconds while loading the first (but not on all the following) Flash game(s) on kongregate.com, but not with other Flash things, like on Kongregate’s front page. I get those error messages before the hang state, they stop while in it, where I only get: CLIENT: Task: Task::done() CLIENT: Task: emitting finished And after it started to react again, another bunch of XID collision messages come rushed in.
The problem is likely to be more serious for some people than others. I suspect the following will acerbate the severity which different people experience: Number of tabs open. Number of flash object on each tab. Type of flash commands used in each flash object. Using me as an example, I normally open firefox with about 15-20 tabs right from the start. Sometimes, if I've needed to shutdown my computer while doing a very heavy web surfing expedition, I might have as many as 40 tabs open. Several of the tabs I regularly have open to make heavy use of numerous flash objects with what I refer to as 'active' commands. These are commands which cause actions like menu drop downs in the flash object to appear and disappear or the autohiding of audio/video controls as a function of mouse proximity. With how I use firefox, at the present time, I cannot successfully open firefox via the normal menu or desktop links. I must open a terminal window and run firefox with a CLI command: "firefox -sync". To be able to open firefox through the usual means, I had to close the problem tabs and then save the remaining tabs as my group homepage. I did check and verify this. For now, executing 'firefox -sync' from a CLI is working for me ... but ... BTW - I see (now that I've looked) that you are also the reporter for the related mozilla bug so I won't add a comment there unless you'd like me to. i.e., if you want me to add something referencing my comment here and the video I made demonstrating the issue in action. Best regards and thank you very much.
Bumping the importance from 'minor' to 'normal' as I believe this bug is responsible for my new inability to watch content on Hulu. And, let's face it, we all need Hulu. ;-) Hulu, which uses Flash, attempts to play the show but then gives up with 'Sorry, we are unable to stream this video. Please check your Internet connection and try again.' * My connection is fine: I can play the same shows within Firefox on two systems which are not GNOME boxes. * Using older versions of Firefox and using older versions of Flash (i.e. versions in which I am certain Hulu worked just fine) has made no difference. * 'firefox -sync' makes no difference I've not found a workaround. (If anyone has one, please let me know. Thanks!)
I think the problem described in comment 3 doesn't belong to this bug.
Yeah, I've since discovered Hulu broke things for all 64-bit users. :-( Sorry for blaming this bug.
I'm running Fedora 13 alpha with Firefox 3.6.1 and 64 bit flash-plugin 10.0.45.2 and ~/.xsession-errors gets loaded with errors quite quickly. After watching about 45 minutes of flash today, I have this: [gene@Mobile-PC ~]$ ll .xsession-errors -rw-------. 1 gene gene 4303165 Mar 9 17:03 .xsession-errors [gene@Mobile-PC ~]$ grep -m 1 'firefox.*XID collision' .xsession-errors (firefox:2118): Gdk-WARNING **: XID collision, trouble ahead [gene@Mobile-PC ~]$ grep 'firefox.*XID collision' .xsession-errors | wc -lc 69282 4226202 The errors were being written rapidly to .xsession-errors while just watching the videos. This is easy to reproduce, just go to any flash intensive site, such as, http://www.adobe.com/ or watch a flash video in Firefox and watch ~/.xsession-errors grow. Gene
I am also getting sporadic instances of this warning: In my case it SEEMS to be associated with screen corruption. Javascript popup boxes are not cleared properly. The environment is Debian Lenny stable on AM64 platform running 2.6.32 kernel and GTK 2.18.6 (From Lenny backports) with self compiled Firefox 3.6. It also happens with latest Icedove from the distro. Its quite hard to reproduce, because it seems to depend on exactly what javascript is used to do popups..Whilst Flash will cause the error, it doesn't lead to any noticeable onscreen effects or performance issues, but when it happens with a popup, it leaves a blank (background colored) box instead of replacing the material behind the popup. But this isn't consistent either. It seems to get worse with time, or more browser windows open., Not sure. The way I can get it to happen, when it does, is to invoke a popup with presumably a mouseover event, and then scroll away (using the mouse WHEEL) from the created popup window. Mousing away is fine, scrolling away is not. I have confirmed this behaviour is specific at least to Linux Firefox, (Its fine on OS-X and MS XP implementations) so I deduced its something to do with Linux libraries rather than Firefox. many hours of searching have brought me here, as it SEEMS to be associated with this warning. The site that seems to do worst - though it is not the only one - is this www.rcgroups.com/electric-plane-talk-7/ if you mouse over any of the threads, a popup box appears. If you use the scroll wheel to move the screen, the popup box will disappear, mostly. Sometimes it leaves a blank background space behind. This never happens if you move the mouse away directly. This problem appeared at some time after I think a normal GTK upgrade from the Lenny distro. I have contacted the site above, and they say that nothing has changed in their javascript for over a year. I apologise for the somewhat woolly description. I have a bad feeling that it takes three specific things to reproduce this problem..a particular javascript script, used in a particular way , with Firefox, plus a full memory map somewhere in some library. And it may only be associated with 64 bit stuff as well. Happy to run tests to the best of my ability. But I am loathe to compile a sepaarte GDK here, as I cant risk instability on what is a working machine. I am NOT a linux guru, though I have been writing code for many years.. It may or may not be relevant, but there is one other error in the general video end of things: I run Intel onboard chipset, and the X logs here's one: (synaptic:6207): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `no de != NULL' failed Not sure if that has anything to do with it.
Oh, I think the severity should be 'high' in that there is no workaround, for me, and it does regularly cause irritation. Actually the correct severity level should be 'bloody irritating, but not critical' but that isn't an option.
(In reply to comment #7) > associated with screen corruption. Javascript popup boxes are not cleared > properly. I think it’s the same thing with Flash. If I scroll down, it looks like the Flash window would stay at the same place, and only gets overdrawn about half a second later. So it looks like it jumps. While the rest of the page, including the frame where the Flash should be, smoothly moves upwards > Whilst Flash will cause the error, it doesn't > lead to any noticeable onscreen effects or performance issues, Well, seems that here it does. Also on kongregate.com, when i load a page with a game for the first time, the game loads a tiny bit, and then the whole browser hangs for about a minute. If you just wait, it unfreezes again. But I think that is when those collisions happen. > If you use the > scroll wheel to move the screen, the popup box will disappear, mostly. > Sometimes it leaves a blank background space behind. Sounds similar to what I described above. > I run Intel onboard chipset, […] Not sure if that has anything to do with it. I run an ATi Radeon HD 4850. So I’d guess it’s not hardware-related.
I found some other references to pixmap corruption in Firefox with the suggestion that later builds might fix the problem. I'm compiling 3.6.2 as I write. I'll report back on whether this impacts the problem. It's a BIG compile. At least you have sort of added weight to the association between the error message and observed screen behaviour. And more or less ruled out video hardware. I hate these sort of sporadic interoperability bugs between two bits of software, with the temptation for the developers of each side to say its HIS --> problem.. :-) I have to say I don't normally play flash games - not lately anyway. I usually just watch movies and clips on it. Are you latest flash release? I'm on 10:0 r42
(In reply to comment #10) > I hate these sort of sporadic interoperability bugs between two bits of > software, with the temptation for the developers of each side to say its HIS > --> problem.. :-) Well, the rule for this kind of problem is, that unless one of them can prove it’s not his problem, it’s both sides’ problem. ;) > I have to say I don't normally play flash games - not lately anyway. I usually > just watch movies and clips on it. Then again, Kongregate is not your normal flash game site. Maybe related: The Kongregate API is the only piece of code I know that has trouble with the 64 bit version of Flash (which is officially still considered alpha, btw!) > Are you latest flash release? > I'm on 10:0 r42 10.0.45.2 here. On 64 bit.
OK., 3.6.2 is, if anything, worse. Instant corruption on starting the browser. I'll hold on upgrading the flash.. ;-)
Hmm. Not sure what's going on here..it LOOKS like its flash that triggers the warning, but once triggered, the problem affects other things than flash. But I cant find a really consistent pattern to it at all.
Leo, Comment 7 sounds like an issue with client-side windows changes. It would be best to file a separate bug report. Client-side windows were introduced in GTK+-2.18, but this bug was reported in GTK+-2.16. If putting GDK_NATIVE_WINDOWS=1 works around the problem then it's more likely a bug in GDK, but, even if you file a Mozilla bug report, I'll probably see what we can do in Mozilla. https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Widget:%20Gtk
I had it in earlier GDK as well I think. Not sure when Debian switched - current stable is 2.12 I think. I probably pulled 2.6 from the backports, and went 2.18 in the last few days, but this is older than that. Stupid question WHERE to put GDK_NATIVE_WINDOWS=1? I guess writing it on a piece of paper and sticking it in the DVD drive wont cut the mustard eh? ;-) Bear in mind I know enough to report a bug, but not the detailed internals of everything.
Aha I tried GDK_NATIVE_WINDOWS=1 as a exportable variable. It changes it. Instead of the windows leaving a grey block behind, it leaves the whole popup instead! Now I am seriously confused! Still gives XID errors.
So NATIVE equals buggy? Then how about doing the opposite, and making everything non-native?
How do I do that?
OK. Further info. XID errors are associated with a particular site I often have running. It has flash stuff. . NOT the site that does this, BUT I am wondering if the presence of these errors affects the actual behaviour on the odd site.. Of course now, its not showing any oddities..at all. I will have to wait for it to misbehave.
(In reply to comment #18) > How do I do that? I have no idea. I don’t even know what “NATIVE” means here. Maybe finding that out, would help. ;) (In reply to comment #19) > BUT I am wondering if the presence > of these errors affects the actual behaviour on the odd site.. As I said, the Kongregate API doesn’t work and the whole browser hangs for a minute. So perhaps it’s this that is the cause… > > Of course now, its not showing any oddities..at all. I will have to wait for it > to misbehave. Put a marker in your .xsession-errors, restart the browser, go to kongregate.com, choose a game and let it load fully… tada… guaranteed XID errors. At least here. (But don’t get stuck playing games all night long! ;)
OK. I think there are two or three separate issues going on, probably not related. The XID thing which is on topic here, seems flash related. My other issues are probably nothing to do with this bug. It seems I have two inter-related problems. One is that popups sometimes dont clear, and the other is that sometimes they half clear. Depending on the environment variable. In all cases I still get XID errors though. I think I'm ducking out of this bug as its not a serious issue for me. I don't have a whole night to waste playing Flash games either..been there done that..;-)
Some additional information related to my comment #6. This "fix" from http://bbs.archlinux.org/viewtopic.php?id=76527 gives insight into what's generating the messages. This bug from https://bugzilla.gnome.org/show_bug.cgi?id=590690 also provides some insight. For some reason, the flash player generates perhaps one warning per frame, around 25/second. I run firefox with standard output and error redirected to /dev/null as a workaround. Gene
I did a lot of experiments with my live system (debian testing based). Reverting xorg from 1.7.6 to 1.6.5 and nothing else the bug disappear!!
My screen corruption bug has FINALLY disappeared I think with the upgrade to latest intel video x driver. So nothing here bugwise for me any more.
The "fix" from comment #22 doesn't really give much of an insight, alas. I get those "XID collision" messages ONLY with iceweasel, not with iceape! Messages seem to stop when I disable the Flash plugin. Messages don't appear when surfing (and video-viewing) youtube. Or derstandard.at, if it comes to viewing videos. Messages only appear -- and instantaneoulsy and massively -- when I'm on one of the www.bbc.co.uk/radioX pages, X standing for 2 or 6, and actually have that tab topmost. Soon as I switch to a different tab they stop. Now as far as I can see, those bbc pages do not contain flash content. The messages fill up my .xsession-errors by several MB per session. ??? Puzzled. And yes, it is most annoying. info: iceweasel 3.5.11 and older libgtk2.0-0 2.20.1-1 and older
Upstream bug has been closed so marking this bug as obsolete. From the upstream bug: "This has been fixed/avoided by out of process plugins."