467744 - crash @gdk_window_new from moz_drawingarea_create_windows after GdkWindow 0x???????? unexpectedly destroyed

Status: RESOLVED DUPLICATE of bug 263160

(Core :: Widget: Gtk, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081124 SeaMonkey/1.1.13
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081124 SeaMonkey/1.1.13

Hitting the <SEND> key in Gmail, results in a <Sending...> message.  After that, before the Inbox is redrawn Firefox 3.0.3pre has a segmentation fault and dies.

The email is transmitted successfully to the Gmail server.  The bug may be in attempting to redraw the Inbox window while Javascript is still active on the mail-send window because the error:
 "Gdk-WARNING **: GdkWindow 0x38c4e6f unexpectedly destroyed
seems to appear in the firefox.log file immediately prior to
Command terminated by signal 11

It should be noted that the "unexpectedly destroyed" bug is extensively documented in the *very* old Bug #263160.  This bug also duplicates Bug #461656.  The same SegFault occured after a Gmail send yesterday and once about a week or so ago.  A new bug is being filed because all of the trace & log files are different.


Reproducible: Sometimes

Steps to Reproduce:
1. Run an old (large) firefox session (~78 windows; ~1038 tabs) -- which as Bug #396375 documents can take a long time to restart.
 
2. Use the browser for a day (this time) to a week+ (previous instances)
3. Send an email message in gmail (not too complicated, perhaps 1/2 a page, no attachments, a little bit of <B> formatting).

SegFault happens. Other Gmails have been sent from the same instance without causing the segfaults.  But there may be timing associated issues with what the machine is doing, what Firefox is doing and what X is doing.  X tends to be quite busy (20-40% of the CPU) with a large number of Windows/Tabs open.  This may contribute to slowing down the responsiveness of Firefox Javascript threads.
Actual Results:  
Firefox Segfaults and if one has it setup right produces a large core dump.

Expected Results:  
Firefox should never Segfault.

It should be noted that this bug started appearing with 3.0.3 -- the problem never seemed to occur with Firefox 2.0.x though I have not worked extensively to confirm this.  The "window unexpedtedly destroyed" errors did occur in 2.0.X but did not result in SegFaults.  Most "window unexpectedy destroyed" errrors do not result in SegFaults.

An additional possibility is that Gmail has changed its Javascripts.  The Gmail Javascript appears to have become larger over the past 1-2 years and has more capabilities.  Strongly recommend saving the "current" gmail scripts and determining how they may be loaded to avoid future changes to the scripts which may change the nature of the problem.

I would also like to have specific documentation in this bug regarding which files/functions are supposed to (a) stop and destroy all executing threads/windows associated with a window (and wait until that completes) when window destroy operation is attempted.  Worst case I would add a "sleep(10)" after any attempt to stop a thread in a window being destroyed to see if the problem goes away.

If the problem is due to an interaction between gtk/gdk/glib and Firefox's use thereof then at least the "window unexpectedly destroyed" part of this bug is likely to not be library specific (because the bug has existed over many versions of those libraries on my system).

It may be necessary to file a bug with gtk.org or freedesktop.org with back-pointers to the Firefox bugs to get someone with enough expertise in these libraries to explain precisely what happens when programs attempt to operate on destroyed windows (because in my book if you have asynchronous threads attempting such operations that is a pretty good recipe for disaster).

Comment 1

[Robert Bradbury]

Attachment: Log file for firefox output (stdout/stderr)

Includes "window unexpectedly destroyed" errors.

Comment 2

[Robert Bradbury]

Attachment: Complete load library log for Firefox 15931

Shows which libraries are loaded from /opt/libdbg (subset of C libraries compiled for debugging) and /usr/LOCAL/lib/firefox-3.0.3pre (Firefox libraries compiled for debugging).

Comment 3

[Robert Bradbury]

Attachment: Complete listing of /opt/libdbg

Complete listing of /opt/libdbg which contains the C and gtk/gdk/glib libraries (plus a handful of others) compiled for debugging.  These are included in LD_LIBRARY_PATH before running Firefox so one can get useful strack traces.  One can see the precise versions using the symbolic links.

Not all libraries are compiled for debugging but the primary libraries which seem to be related to the problems I have encountered over several years are.  In general the libraries are versions of the "current" Gentoo Linux source releases.

Comment 4

[Robert Bradbury]

Attachment: GDB trace of various critcal parameters during core dump

Here is the gdb trace of the core dump with firefox 3.0.3 pre.

I am not sure of all of the information you might require but can should be able to produce it if you request it.

I could upload the files if you provide an FTP area, but the core dump itself is  ~1.4 GB and the firefox binaries perhaps ~150MB so it might take a while.  It might be better to simply create a ssh login so that you could use my machine "as is".

Though my limited read of the core dump is that it was having a problem in "mozdrawingarea.c" in moz_drawingarea_create_windows() and calls to gdkwindow.c:gdk_window_new() which is exactly what it would be doing after destroying the gmail compose & send window and redrawing it as the Inbox listing window.  This is also exactly what I would expect to have be a problem if the old window was not fully destroyed before the new window was being created if there is not proper locking on the "active" window lists.

Now the problem may be in the gdk/gtk window locking code (and multi-threaded applications) which is why I suggested that you are really going to need someone who understands how those libraries work.  I've tried going through the code to a limited extent and IMO it would require several days of dedicated effort to get up-to-speed.

Comment 6

[Robert Bradbury]

It looks like I may finally understand this.  I had an instance where Firefox did a core dump without Gmail being involved (I had a tab which failed to load a URL and was either attempting to delete it or return it to the default home page).

It did a SEGVIO core dump with similar characteristics to those found with Gmail.

I've managed to learn enough GDB that I can kind of work through the core dumps (and the trace will subsequently be attached) but here is what appears to be the problem:

nsWindow::NativeCreate()
  calls widget/src/gtk2/mozdrawingarea.c:moz_drawingarea_new()
    calls widget/src/gtk2/mozdrawingarea.c:moz_drawingarea_create_windows()
      calls gdk_window_new() (=IA__gdk_window_new())

        This calls:
	   window = _gdk_window_new (parent, attributes, attributes_mask);
        which detects that "parent" has been marked as destroyed, presumably
	by a separate asynchronous call to
	  _gdk_window_destroy_hierarchy() which sets private->destroyed = TRUE

	This is checked for in gdk/x11/gdkwindow-x11.c:_gdk_window_new()
        using the GDK_WINDOW_DESTORYED(parent) macro.

        While gdk_window_new() checks to make sure (parent != NULL) it does
	not check (window != NULL) thus GDK_WINDOW_OBJECT() which presumably
	translates into g_type_check_instance_cast() is passed a NULL and
	gets back a NULL (which it assigns to "private").

	Thus the statement
	  private->redirect = parent_private->redirect
	results in a SEGVIO due to private being NULL.

   This can possibly be considered a bug in gdk_window_new (not making sure
   the parent window is "undestroyed" before using it).  It can also be
   considered a *BUG* in Mozilla/Firefox because it seems to be attempting
   to create a new "child" window for a window being destroyed (perhaps
   asynchronously).

This seems to be consistent with my experience of when and where the
problem crops up (one sees a "GdkWindow 0xXXXXXXXX unexpectedly destroyed"
warning) just before one gets an orphan window being created (if one is lucky)
or a SEGVIO and a core dump (if one is unlucky).

Could somebody *please* who understands window creation & deletion
interactions please fix the locking so that windows are not created
as children of windows in the process of being destroyed?

In the meantime I'm going to modify my gdk_window_new() so the code is
  if (parent != NULL && window != NULL) ...

Lord only what Mozilla/Firefox will do if gdk_window_new() returns "NULL".
From the looks of mozdrawingarea.c and mozcontainer.c they always expect
gdk_window_new() to work and make subsequent gdk_window_set_user_data() calls.
Looks like people haven't considered the possibility that one could run out
of memory or swap space in which new windows can be created... (Wait until
somebody tries running this on an Android Phone...)

Comment 7

[Robert Bradbury]

Attachment: GDB trace showing key elements of gdk_window_new problem

As pointed out in the attachment this is a somewhat edited GDB trace but I think I have diagnosed the problem correctly (see Comment #6).

Comment 8

[Robert Bradbury]

This bug has been filed also as Gnome Bug #563592 (@ bugzilla.gnome.org) with
references to the related Firefox bugs.  It is suggested that the
Mozilla/Firefox developers of the gtk2 utilities should interact with the Gnome
gdk/gtk developers to determine how window creation & deletion should be
"locked" to prevent such activities from interfering with each other.

Either that and/or the Mozilla/Firefox developers need to do a complete code
review to make sure they are not assuming the success of library functions
which may infrequently fail (esp. under high stress/load situations).

Comment 9

[Karl Tomlinson (:karlt)]

Thank you for the analysis.

The patch in bug 451341 may help here, or at least catch the problem with
destroyed windows earlier.  It may require some hand editing to apply to 3.0,
or you can use 3.1beta1 or 3.1beta2 (which is going through QA right now),
which already have the patch applied.

(In reply to comment #6)
> nsWindow::NativeCreate()
>   calls widget/src/gtk2/mozdrawingarea.c:moz_drawingarea_new()
>     calls widget/src/gtk2/mozdrawingarea.c:moz_drawingarea_create_windows()
>       calls gdk_window_new() (=IA__gdk_window_new())
> 
>         This calls:
>        window = _gdk_window_new (parent, attributes, attributes_mask);
>         which detects that "parent" has been marked as destroyed, presumably
>     by a separate asynchronous call to
>       _gdk_window_destroy_hierarchy() which sets private->destroyed = TRUE

Have you checked the value of the destroyed field to confirm this theory?
I think this would be available through

  p ((GdkWindowObject*)parent)->destroyed

> Looks like people haven't considered the possibility that one could run out
> of memory or swap space in which new windows can be created...

g_object_new typically uses glib memory allocation functions that abort on
failure and so never return NULL.  This doesn't provide any mechanism for
recovery but it is always a safe (non-exploitable) crash.

Comment 10

[Robert Bradbury]

Well I had already recompiled the GDK/GTK libraries with the suggested change (and possibly a C compiler upgrade) from the old libraries so GDB doesn't seem to load them so as to get the correct stack trace again.

But if I assume the original strack trace (posted) was correct and try:
  p ((GdkWindowObject *)0x7f2ee5e0)->destroyed
it *does* print "$1 = 1".  So I read that as a strong indication that
  parent->destroyed = TRUE.
which in my framework gives more support to the case that one thread is trying to create windows while another thread is destroying them and there may be lingering cases where that breaks the libraries if locking isn't handled at higher levels.

I did look briefly at Bug #451341 and it doesn't appear to be the same bug (do you get a "window unexpectedly destroyed" warning?) but I'll have to study it further.  In the meantime, I'll start running on firefox-3.0.6pre with the patched gdkwindow.c tomorrow (CVS does not seem to give me firefox-3.1).  I will also note for the record that "--disable-strip-libs" still appears to be unfixed  when installing firefox (firefox-bin is unstripped but all the libraries are stripped) so some by-hand copying from the build directories to the install directories is required if one expects "robust" traces.

Comment 11

[Robert Bradbury]

I've got 7 firefox core dumps (mostly in the range 1.2-1.6 GB -- good thing I've got some large disks :-)) for Firefox 3.0.3 dating back 6+ weeks and even though the stack traces don't quite read properly because I've recompiled the gtk/gdk libraries the frame tracing still pretty much works and one can determine what the parent argument to gdk_window_new() is.

For 5 of those core dumps the parent->destroyed flag is set to 1.  This pretty much seals it from my perspective that (a) there are still some latent bugs in libgdk/libgtk/libglib involving multi-threaded manipulation of the data structures; and(or?) (b) Firefox/Mozilla/et al are not doing a very good job making sure the threads don't step on each other.  Lord knows what a mess there is going to be when the 6 & 12 core CPUs start arriving in 2010.

Comment 12

[Karl Tomlinson (:karlt)]

(In reply to comment #11)
> For 5 of those core dumps the parent->destroyed flag is set to 1.

Thanks for checking that out.


(In reply to comment #10)
> which in my framework gives more support to the case that one thread is trying
> to create windows while another thread is destroying them and there may be
> lingering cases where that breaks the libraries if locking isn't handled at
> higher levels.

All Mozilla/GDK interaction happens on one thread.  The only possibility of
other threads being involved would be if plugins were manipulating windows on
another thread, but that seems unlikely.

However, it does sound like a window that has been destroyed is being used
while creating a child window.

> I did look briefly at Bug #451341 and it doesn't appear to be the same bug

It was the patch, rather than the bug, that I was referring to.
The patch includes better cleaning up of destroyed nsWindows, so as not to
hold dangling pointers to destroyed GdkWindows, and assertions that may catch
some flaws in the window hierarchy.

It would be interesting to know whether Mozilla's window structures know/think
that the native window is destroyed.  If you have sufficient debug information
for any crash, would you mind checking this, please?

The best way to do this would be to first run the following command:

(gdb) set print object on

Note that there are two different stacks here, so two different commands would
be required to get the information.  In one stack, nsWindow::NativeCreate has
aParent, but not aNativeParent:

#7  0x08245015 in nsWindow::NativeCreate (this=0x9bacce00, aParent=0x9b9c6ef0, aNativeParent=0x0,
    aRect=@0xbfc3ff74, aHandleEventFunction=0x846ee1a <HandleEvent>, aContext=0x54952580, aAppShell=0x0,
    aToolkit=0x0, aInitData=0xbfc3ff5c) at nsWindow.cpp:3244

(gdb) f 7
(gdb) p aParent->mIsDestroyed

In the other stack, nsWindow::NativeCreate has aNativeParent, but not aParent:

#7  0x08245015 in nsWindow::NativeCreate (this=0x66e6bdf0, aParent=0x0, aNativeParent=0x7f2ee5e0, aRect=@0xbfef3b64, 
    aHandleEventFunction=0x846ee1a <HandleEvent>, aContext=0x620386d0, aAppShell=0x0, aToolkit=0x0, aInitData=0xbfef3b4c)
    at nsWindow.cpp:3244

#10 0x082806a6 in DocumentViewerImpl::MakeWindow (this=0x6b18e0e0, aSize=@0xbfef3c70) at nsDocumentViewer.cpp:2259

(gdb) f 10
(gdb) p mParentWidget->mIsDestroyed

> (CVS does not seem to give me firefox-3.1).

3.1 version control is handled by mercurial, or a source tarball is available
at

http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.1b2/source/

> will also note for the record that "--disable-strip-libs" still appears to be
> unfixed  when installing firefox (firefox-bin is unstripped but all the
> libraries are stripped) so some by-hand copying from the build directories to
> the install directories is required if one expects "robust" traces.

It would be good to file a bug on this if there is not one already.

I'm not sure if I understand the issue fully, but you can run firefox directly
from the dist/bin build directory.

Comment 13

[Robert Bradbury]

Ok, bearing in mind that only one thread should be manipulating the windows; the question would be what happens with "mouse clicks"?  Because in most cases I have noticed the problem taking place when I request (via a mouse) that a window be destroyed.  Is the mouse operating via a different thread?  (Compared with say a window refresh command generated from HTML or Javascript)  [What we want to get at here is any and all "destroy" / "redraw" / "create" windows commands and know how they are being invoked.

Is there any documentation for Firefox with respect to "what threads do what"?
If not I would view that as a severe missing piece.

Side note: I do not be able to build the current beta (Bug #469493), so progress in that direction seems to be blocked until they have a 3.1 beta distribution which will build under Linux.

(I am very intolerant with respect to things which only work under Wndows.)

If you wish to contribute you might most various config options which do indeed work under Linux.

Now, with respect to this specific bug. I have seen the "unexpectedly destroyed" error under Linux with the most up-to-date libraries including my fix to what I suspect caused the SEGVIO.  So it seems to indicate that windows manipulation has still not been sufficiently constrained within Firefox.  The only good thing  might be (and I stress "might") be that my proposed fix prevents the SEGVIO.  We  still need to determine where attempts are being made to manipulate deleted windows (at the Firefox level before they get to the glib level).

Comment 14

[Karl Tomlinson (:karlt)]

(In reply to comment #13)
> Is the mouse operating via a different thread?

There is no "mouse" thread within Mozilla.  The mouse events come through the kernel and the X server (which is a separate process), and are delivered to the SeaMonkey process as X events.

There is potential for race conditions between the SeaMonkey process and the X server, as X server events and actions are asynchronous, but I won't speculate on the cause of the problem based on the current information. 

> Side note: I do not be able to build the current beta (Bug #469493), so
> progress in that direction seems to be blocked until they have a 3.1 beta
> distribution which will build under Linux.
> If you wish to contribute you might most various config options which do indeed
> work under Linux.

I use the following and run the executable in the dist/bin directory:

ac_add_options --disable-optimize --enable-debug --disable-installer --disable-libxul
ac_add_options --enable-extensions=" gnomevfs"
ac_add_options --enable-ogg
ac_add_options --with-system-jpeg=/usr
ac_add_options --with-system-lcms=/usr
ac_add_options --with-system-zlib=/usr
ac_add_options --enable-startup-notification

Comment 15

[Karl Tomlinson (:karlt)]

I saw the same kind of crash as described in comment 6 with Firefox 3.0.7 following a link for an identifier search at mxr.mozilla.org.
The parent GdkWindow for gdk_window_new is the same window that was previously
"unexpectedly destroyed" .  Its refcount is still 1 held by the MozDrawingArea for which it is the inner_window and its nsWindow is not destroyed.

I saw a few earlier "unexpectedly destroyed" messages from GDK when opening links in background tabs for other pages, but they did not result in a crash.  (This crash happened following a link in the same tab.)

All (~4) unexpectedly destroyed windows were inner_window leaves in the GdkWindow tree, which looked intact.  Each of the associated nsWindows were of type child, had no nsWindow parent, were 3 nsWindows below what looked like the first (zeroth) nsWindow for a tab, and had the size and position of the document window.  The only child nsWindows with no parent that I know of come from DocumentViewerImpl::MakeWindow().

The crash happens because a window that seems to have been destroyed without its nsWindow's initiation or GDK's initiation gets used as the parent in gdk_window_new().  So the root cause seems to be whatever destroyed the window (unexpectedly), which is still a mystery.

Comment 16

[Karl Tomlinson (:karlt)]

It is likely that this will be fixed in 1.9.0.10 as I haven't seen any
"unexpectedly destroyed" messages since applying the patch from bug 451341, and this will be applied for Gecko 1.9.0.10.

If you see the same kind of crash with 1.9.1 beta 4 (Firefox 3.5 beta 4) or trunk or 1.9.0.10, then please reopen.

Comment 17

[Karl Tomlinson (:karlt)]

I got some "unexpectedly destroyed" messages recently, even with the patch from 451341.  The messages were later followed by this crash.

Comment 18

[Karl Tomlinson (:karlt)]

What's happening here is:

1) GDK creates a GdkWindow which is a record of an X window.  The XID for the
   X window is recorded on the GdkWindow.  So that X events can be traced from
   the X window XID to the GdkWindow, the GdkWindow is recorded in a hash
   table keyed by XID (and another reference is added to the GdkWindow).

2) The GdkWindow is destroyed (but not deleted).  This calls XDestroyWindow
   with the associated XID, and so the server sends a DestroyNotify event and
   deletes the X window.  (One reference to the GdkWindow will not be removed
   until the DestroyNotify event is received.)

3) GDK creates a second GdkWindow, which uses XCreateWindow.  XCreateWindow
   returns an XID equal to the XID associated with the previous window.  This
   new GdkWindow is recorded against the XID in the table, removing the entry
   pointing to the first GdkWindow (without removing a reference to the first
   GdkWindow).

4) GDK processes X events, including the DestroyNotify event for the first
   window.  The XID in the event is translated to a GdkWindow using the table,
   but this now returns the second GdkWindow.  This GdkWindow was not
   expecting a DestroyNotify event and so a warning "GdkWindow %#lx
   unexpectedly destroyed" is emitted.  A reference is removed from this
   second GdkWindow, and it is marked as destroyed (even though the X window
   has not been destroyed.

So the first GdkWindow is leaked, and when the second GdkWindow (marked
destroyed) gets used as a parent for gdk_window_new, the result is the crash
described in comment 6.

I hope the X server is always sending the DestroyNotify event before making
the XID available again.  In the situation that I saw, the event was sitting
in the queue after XCreateWindow was called at step 3.  (I hope it was in the
queue before the XCreateWindow call.)

Comment 19

[Karl Tomlinson (:karlt)]

Filed http://bugzilla.gnome.org/show_bug.cgi?id=581526

Comment 20

[D. Hugh Redelmeier]

I suspect that I'm seeing this too.  But I don't have an idea how to tell.

I'm running Fedora 10's firefox-3.0.10-1.fc10.x86_64

I did run the "firefox --sync" command under the script command, so I have a list of the output.  And I have a core file.

Firefox crashes for me ever week or so.  It used to crash more frequently until the  generate_xid bug was fixed https://bugs.freedesktop.org/show_bug.cgi?id=20254

The last thing printed before the segfault was
  (firefox:3824): Gdk-WARNING **: GdkWindow 0x44f4e45 unexpectedly destroyed

GDB says that the segfault happened here:
  #3  0x0000003da7434d4d in IA__gdk_window_new (parent=0x82fabe0, attributes=<value optimized out>, attributes_mask=<value optimized out>) at gdkwindow.c:381

I will attach the typescript showing the stdout & stderr of firefox and gdb output including a traceback.

Is there any additional information that I should gather?

Comment 21

[D. Hugh Redelmeier]

Attachment: typescript of crashing firefox

the gmail site was not the trigger of this crash.

Comment 22

[Karl Tomlinson (:karlt)]

Yes, that's the same issue, thanks Hugh.
I think we have enough information about what is happening in Mozilla and GTK2.
I don't know whether this should be fixed in GTK, Xlib, or Xserver.

Comment 23

[Robert Bradbury]

I can confirm that sometime between gtk+-2.14.3 and gtk+-2.16.1 the gtk developers changed gdk/gdkwindow.c to check for window == NULL, the code, mow lines 379-380 reads:
  window = _gdk_window_new (parent, attributes, attributes_mask);
  g_return_val_if_fail (window != NULL, window);

So if my experience is to serve as an example (esp. regarding stack traces provided), then this should fix the SEGVIO part of this problem.  It may not fix the "window unexpectedly destroyed" part of the problem, or the detached window problem which as Karl's analysis shows are a bit more complicated.  But at least the fix may end crashing Firefox.  So if one wants to avoid the crashes one had best be running a recent release of the gtk+ libraries.

However, as Karl's analysis shows the Firefox code may be stressing gtk/gdk enough that one could trip over other lurking problems of a different nature. so its clearly a case of "buyer beware".

Comment 24

[Robert Bradbury]

I wanted to comment that this bug is *NOT* fixed in Firefox 3.0.11 (current Gentoo release).  This is presumably the major component to soon be "3.5 production" (something which really shouldn't happen until this long existing bug is resolved).  I've got NINE "GdkWindow 0x.... unexpectedly destroyed" messages on my current Firefox console (along with a slew of other gdk_window_set/show/move/hide... assertion failures) from a "large" firefox session (71 windows / 850 tabs) that is currently consuming 30-60% of my CPU doing essentially nothing.  As mentioned previously this shows up most frequently (for me) on a machine which either has a very large (and CPU wasting) Firefox session and/or Firefox running simultaneously with system builds (Gentoo emerge's) which compete for CPU time causing Firefox and/or X to lose the CPU.  (This is on a single core Pent. IV Prescott.)

I had to laugh at the recent 3.5 review I read that commented that the "new" and "improved" Firefox 3.5 could handle a lot more windows/tabs without problems (but what do reviewers know...).

Comment 25

[Alexandre Pereira Nunes]

3.5 was released and, surprise, surprise:
firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

(firefox-bin:11131): Gdk-WARNING **: XID collision, trouble ahead

Comment 26

[D. Hugh Redelmeier]

I too am using 3.5 (Fedora 11's firefox-3.5-1.fc11.x86_64).  I'm running it with --sync which, I thought, would prevent these problems, but it does not.

Here is the first chunk of what appeared on stdout or stderr.  There is more.  These are all the messages printed, up to a point in time.  I don't know how they are related -- the session lasted some days.  I ended the session when FF seemed unable to finish displaying a page.

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xatom != None' failed

(firefox:3192): Gdk-WARNING **: XID collision, trouble ahead

(firefox:3192): Gdk-WARNING **: GdkWindow 0x44f263c unexpectedly destroyed

(firefox:3192): Gdk-WARNING **: XID collision, trouble ahead

(firefox:3192): Gdk-WARNING **: GdkWindow 0x44f2607 unexpectedly destroyed

Comment 27

[D. Hugh Redelmeier]

I should have mentioned that Fedora 11 includes the fix for xcb_generate_id
  https://bugs.freedesktop.org/show_bug.cgi?id=20254

Comment 28

[Martin Mokrejs]

I got with freshly started seamonkey browser, before even going to any web page, this crash as well on Gentoo Linux:

(gecko:20280): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xa
tom != None' failed

(gecko:20280): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xa
tom != None' failed

(gecko:20280): Gdk-CRITICAL **: gdk_x11_xatom_to_atom_for_display: assertion `xa
tom != None' failed
/usr/libexec/mozilla-launcher: line 119: 20280 Segmentation fault      (core dum
ped) $(type -P aoss) "$mozbin" $xulparams "$@"
seamonkey-bin exited with non-zero status (139)


Also seen in other sessions the "XID collision, trouble ahead" messages.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090731 SeaMonkey/1.1.17

Comment 29

[Martin Mokrejs]

And partially resolved stacktrace is:

(gdb) where
#0  0xb7ef7424 in __kernel_vsyscall ()
(gdb) where
#0  0xb7ef7424 in __kernel_vsyscall ()
#1  0xb7cf2d5e in raise () from /lib/libpthread.so.0
#2  0xb5d28ff4 in ?? () from /usr/lib/seamonkey/components/libprofile.so
#3  0x0000000b in ?? ()
#4  0xb5d2578b in nsProfileLock::FatalSignalHandler (signo=-1211125772) at nsProfileLock.cpp:206
#5  <signal handler called>
#6  0xb7b923a7 in gtk_widget_event_internal (widget=0x0, event=0xbfd1405c) at gtkwidget.c:4766
#7  0x0000008d in ?? ()
#8  0x00000004 in ?? ()
#9  0x00000020 in ?? ()
#10 0x08b96a88 in ?? ()
#11 0x00000034 in ?? ()
#12 0x080940b0 in ?? ()
#13 0x00000000 in ?? ()
(gdb)

Comment 30

[Robert Bradbury]

Note that the recent reports, perhaps comment #25, but certainly comment #26 thru comment #29 may (or may not) be a different bug.  See Bug #507910.  It is critical that people document the versions of libgdk/gtk/glib that they are using on their system to diagnose these 3 problems (xatom conversion, XID collision and Window unexpectedly destroyed) as I am aware of partial fixes for at least the last two which I have had in my library sources at some point (but may have lost during recent upgrades).  Please cite the Gnome Bugs database where appropriate.

Comment 31

[Martin Mokrejs]

(In reply to comment #29)

I have a Gentoo system, witch gtk+2.16.5, glib-2.20.4.

$ equery belongs libgdk.so
 * Searching for libgdk.so ... 
x11-libs/gtk+-1.2.10-r12 (/usr/lib/libgdk.so -> libgdk-1.2.so.0.9.1)
$

Hope this helps somebody.

Comment 32

[Karl Tomlinson (:karlt)]

This was caused by the same issue as caused bug 263160.