After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 482531 - firefox crashed on print preview [@IA__gdk_window_get_toplevel] [@gdk_window_is_toplevel_frozen]
firefox crashed on print preview [@IA__gdk_window_get_toplevel] [@gdk_window_...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.12.x
Other Linux
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
: 581661 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-02 10:48 UTC by Sebastien Bacher
Modified: 2009-05-15 15:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
patch by Alexander Sack to fix the bug (1.84 KB, patch)
2007-10-02 10:49 UTC, Sebastien Bacher
none Details | Review
updated patch (712 bytes, patch)
2007-10-08 20:07 UTC, Kristian Rietveld
none Details | Review
another patch (910 bytes, patch)
2007-11-09 22:42 UTC, Kristian Rietveld
committed Details | Review

Description Sebastien Bacher 2007-10-02 10:48:28 UTC
The bug has been opened on https://bugs.launchpad.net/bugs/144326

"Test case:
- Open a browser window (my home page is iGoogle -- http://www.google.com.br/ig?hl=pt-BR)
- File > Print Preview
- The browser crash.
...
  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 nsProfileLock::FatalSignalHandler
    at nsProfileLock.cpp line 206
  • #3 <signal handler called>
  • #4 IA__gdk_window_get_toplevel
    at /build/buildd/gtk+2.0-2.12.0/gdk/gdkwindow.c line 617
  • #5 gdk_window_is_toplevel_frozen
    at /build/buildd/gtk+2.0-2.12.0/gdk/gdkwindow.c line 2298
  • #6 IA__gdk_window_process_all_updates
    at /build/buildd/gtk+2.0-2.12.0/gdk/gdkwindow.c line 2438
  • #7 gdk_window_update_idle
    at /build/buildd/gtk+2.0-2.12.0/gdk/gdkwindow.c line 2288
  • #8 gdk_threads_dispatch
    at /build/buildd/gtk+2.0-2.12.0/gdk/gdk.c line 470
  • #9 g_idle_dispatch
    at /build/buildd/glib2.0-2.14.1/glib/gmain.c line 4132
  • #10 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.14.1/glib/gmain.c line 2061
  • #11 g_main_context_iterate
    at /build/buildd/glib2.0-2.14.1/glib/gmain.c line 2694
  • #12 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.14.1/glib/gmain.c line 2898
  • #13 IA__gtk_main
    at /build/buildd/gtk+2.0-2.12.0/gtk/gtkmain.c line 1144
  • #14 nsAppShell::Run
    at nsAppShell.cpp line 139
  • #15 nsAppStartup::Run
    at nsAppStartup.cpp line 151
  • #16 XRE_main
    at nsAppRunner.cpp line 2711
  • #17 main
    at nsBrowserApp.cpp line 61
  • #18 __libc_start_main
    from /lib/tls/i686/cmov/libc.so.6
  • #19 _start

Comment 1 Sebastien Bacher 2007-10-02 10:49:53 UTC
Created attachment 96504 [details] [review]
patch by Alexander Sack to fix the bug

comment from Alexander Sack who submitted the patch

"gtk 2.12 introduced gdk_window_is_toplevel_frozen (window) and makes use of it in gdk_window_process_all_updates; this introduces crashes when there are NULL pointers in update_windows list; in addition gdk_window_get_toplevel crashes when there is no TOPLEVEL ancestor.

Both cases appear to happen in this firefox "print preview" crash.

This patch adds some NULL checks to make gdkwindow more failsafe in these cases."
Comment 2 Matthias Clasen 2007-10-04 04:57:18 UTC
Kris, can you have a look at this ?
Comment 3 JP Rosevear 2007-10-08 18:23:21 UTC
Built test packages for downstream bug:
https://bugzilla.novell.com/show_bug.cgi?id=331725

They fix the problem for me, would like some verification of the gtk fix.
Comment 4 Kristian Rietveld 2007-10-08 20:07:54 UTC
Created attachment 96900 [details] [review]
updated patch

For me just applying this bit of the original patch fixes the crash.  It feels like the NULL pointers in the "tmp_list" were being caused by the gdk_window_is_toplevel() issue.

Two points of concern:
- Fixing gdk_window_get_toplevel() does make sense to me, however it concerns me a bit that this has never been hit before while iterating over a window hierarchy without a toplevel.

[- Should gdk_window_is_toplevel_frozen() return TRUE or FALSE?  FALSE does work fine.  Though you can make the argument that updating a window hierarchy without a toplevel is kind of useless and the hierarchy could be considered frozen...  When you switch to TRUE firefox will work but spit a bunch of warnings (I think because you need additional logic to get rid of stale windows in the update-list later on... ]


I think we can commit this patch as is, however a second opinion from Owen might never be bad ;)
Comment 5 Frederic Crozat 2007-10-10 12:49:31 UTC
Confirming, we have this crash too on Mandriva : http://qa.mandriva.com/show_bug.cgi?id=33579

and I can confirm Kris patch fixes the issue.
Comment 6 Tim Miao 2007-10-17 06:51:21 UTC
This crash is also visible on opensolaris nevada_75.
Comment 7 Matthias Clasen 2007-10-18 03:27:50 UTC
Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=336771
Comment 8 Kristian Rietveld 2007-11-09 22:42:20 UTC
Created attachment 98848 [details] [review]
another patch

Further debugged this with Owen and came up with this patch.  Basically mozilla is destroying windows from their paint handler, which is kind of evil.  Owen suggests that we file a bug with the gecko developers with a back trace generated by getting a global in process updates in case we come along a window with GDK_WINDOW_DESTROYED and a g_assert() in gdk_window_destroy().
Comment 9 Kristian Rietveld 2007-11-09 22:46:27 UTC
Committed r18975.
Comment 10 Brian Cameron 2009-05-15 15:06:37 UTC
*** Bug 581661 has been marked as a duplicate of this bug. ***