507910 - Gdk-CRITICAL - gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12pre) Gecko/2009071319 Firefox/3.0.12pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12pre) Gecko/2009071319 Firefox/3.0.12pre

The error is in the summary. This bug has been misreported several other places.  It seems to only be present in recent versions of Firefox/Gtk (circa June-Aug 2009?).  The error may contribute to later problems (the Gdk "XID collision" and/or Gdk "Window unexpectedly destroyed" problems -- which still seem to exist).  But it is possible to generate this error (URLs provided) and to switch back and forth between tabs and/or windows without crashing the browser.  The error appears when you switch back to a tab on a URL which exhibits the problem and the page is redrawn. Stack trace(s) of the call to g_logv() will be attached.

Reproducible: Always

Steps to Reproduce:
1. Build a recent version of Firefox (3.0.12pre from CVS in circa 090714).
2. Restart Firefox restoring a relatively large number of tabs.
3. Restore/visit the URLs which generate the error.
Actual Results:  
Gdk error appears on the Firefox "console".

Expected Results:  
Firefox should *not* generate Gdk/Gtk/Glib errors.

Problematic URLs:
http://blogs.gnome.org/metacity/2009/03/12/2270-released/
http://www.universetoday.com/2009/08/01/opportunity-spies-unusual-rock-large-meteorite/

I have listed the bug as major severity because these bugs were noticed before a sequence of XID collisions followed by Window unexpectedly destroyed Gdk errors which did result in the termination of the Firefox session.  Because Glib error reporting doesn't timestamp the errors it isn't clear whether or not they are connected but other bug reports of this problem seem to suggest that they may be.

Comment 1

[Robert Bradbury]

Attachment: gdb output from www.universetoday.com page error

Output from gdb showing stack traces.

Comment 2

[Robert Bradbury]

Attachment: Gdb output from blogs.gnome.org page error

More gdb output, it should be noted that the traces appear to involve Javascript in some way.  This is with a session which has NoScript installed and with Javascript disabled for the pages which generate the errors.  So if Javascript is running the errors would most likely be in Mozilla code -- not the web site's code.

Comment 3

[Robert Bradbury]

Attachment: Gdb output from PNAS.org page error

URL for this error appears to be:
http://www.pnas.org/content/early/2009/07/17/0905195106.abstract?etoc=
Page title (if you need to search for it) starts with:
"Long-term survival following a single treatment of kidney tumors with multiwalled carbon" ...

Also of note, this Firefox session contained 33 windows & 338 tabs and the error was not produced for most of the other pages, including some at the same web sites.

Comment 4

[Robert Bradbury]

Attachment: Sample shell script to assist in tracing Firefox Gdk errors

Given the outstanding Gdk errors in Firefox (xatom conversion, XID collision and Window unexpectedly destroyed), I thought it might be useful for people to have a script which helps produce stack traces which can help the Mozilla/Gnome/Freedesktop developers.

This is attached.  It lowers the barriers to contributing to the maintenance/fix process somewhat if people are willing to devote the disk space & CPU time to maintaining their own versions of Firefox (or convince their Linux distributors to provide "debug" releases).  Use it only if you understand it reasonably well and have adjusted it for ones own configuration.

Comment 5

[Robert Bradbury]

Bug #467744 has some related information -- comment #26 thru comment #29.

Comment 6

[Robert Bradbury]

It would appear that this is may be either an image display problem for recent gtk+ (-2.16.5) library releases or else there are problems with GIFs and PNGs released by Mozilla.  The bug can be thrown from Gimp using either "Throbber-small.gif" from the distribution or "mozilla/extensions/irc/xul/skin/images/face-rofl.png" from the sources.  Perhaps many of the other small images are problematic.

If anyone files a bug report with Gnome, please cite their bug # here.

Comment 7

[Robert Bradbury]

This bug originates from a modification to gtk+-2.16.5.  It is not specific to Firefox (gimp and other programs can generate it as well).  The precise error comes from the function gdk_x11_atom_to_xatom_for_display() in the file .../gdk/x11/gdkproperty-x11.c around line 192. "g_return_val_if_fail (atom != GDK_NOME, None);"

This is apparently a reasonable error check that generates messages in multiple programs that use Gdk.  I have seen at least one discussion that suggests that the Gdk developers view it as a unnecessary/noisy check (at least a non-CRITICAL one) that will be modified/removed in subsequent releases.

If a specific reference to the Gnome bug database or patches regarding this are known it would be useful to add them here.

Comment 8

[Christian Riechers]

Gnome bug 580511 seems to be related.
http://bugzilla.gnome.org/show_bug.cgi?id=580511

Comment 9

[H. te Loo]

Got this bug 2 times today. Firefox was both times set to offline

Comment 10

[Tyler Downer [He/Him]]

Reporter, please retest with Firefox 3.6.12 or later in a fresh profile (http://support.mozilla.com/kb/Managing+profiles). Also update your plugins (flash, adobe reader, java, quicktime, silverlight, etc.) Go to the developer's website and download the latest version from there. If you no longer see this issue, please close this bug as RESOLVED, WORKSFORME. If you do see the bug, please post a comment.

Comment 11

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Comment 12

[Robert Bradbury]

It is worth noting that to take a number of months to request a review of a bug involving the gdk/gtk/glib libraries on an active (Gentoo) system is pointless.

Gentoo Linux systems may upgrade their libraries on a "continuous" basis.  The time scale for gdk/gtk/glib library upgrades for me is probably quarterly or semi-annually.  So if you get a bug report about a gdk/gtk/glib error it should be addressed *when* the bug report is filed -- not many months later.  By then it is likely that the kernel and the libraries have been upgraded and it is quite likely that the web page(s) that caused the error may have changed.  If the error is "session" dependent (I run very complex sessions that stress the display libraries significantly greater than the typical user) it is likely that the user may have lost track of the session so "reproducing" the problem is next to impossible (which is why I didn't bother trying).

The Mozilla Development team needs to develop a better system for determining when bugs are time/context dependent and need to be addressed *when* the bug is filed.