531580 - "gtk_clipboard_get_for_display: assertion `!display->closed' failed" after closing browser

Status: RESOLVED INCOMPLETE

(Core :: Widget: Gtk, defect)

Description

[Reed Loden [:reed]]

I'm getting this assertion every time I close my browser. Regression from bug 311340.

STR:
1) Open Minefield (I used -no-remote, but I don't think that matters)
2) Homepage loads...
3) Close Minefield

(firefox-bin:16422): Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion `!display->closed' failed

(firefox-bin:16422): Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion `!display->closed' failed

Comment 1

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

I'll check what's going on here, seems to come from my patch anyway...

Comment 2

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

It comes from here:

#4  0x0000003d26e865fa in IA__gtk_clipboard_get_for_display (display=0x7ffff6b73170, selection=0x1) at gtkclipboard.c:305
#5  0x00007fffe9366b47 in nsClipboard::SelectionClearEvent (this=0x7fffdc8fc1a0, aGtkClipboard=0x7fffdb254a00)
    at nsClipboard.cpp:667
#6  0x00007fffe9366bfe in clipboard_clear_cb (aGtkClipboard=0x7fffdb254a00, user_data=0x7fffdc8fc1a0) at nsClipboard.cpp:692
#7  0x0000003d26e84a3a in clipboard_unset (clipboard=0x7fffdb254a00) at gtkclipboard.c:696
#8  0x0000003d26e86ec5 in gtk_clipboard_finalize (object=0x7fffdb254a00) at gtkclipboard.c:227
#9  0x0000003f9aa0d79f in IA__g_object_unref (_object=<value optimized out>) at gobject.c:2421
#10 0x0000003f9aa0b81e in IA__g_closure_invoke (closure=0x7fffdb26b460, return_value=0x0, n_param_values=2, 
    param_values=0x7fffd530e8e0, invocation_hint=0x7fffffffd350) at gclosure.c:767
#11 0x0000003f9aa20b43 in signal_emit_unlocked_R (node=0x7ffff6b72060, detail=<value optimized out>, 
    instance=<value optimized out>, emission_return=<value optimized out>, instance_and_params=<value optimized out>)
    at gsignal.c:3247
#12 0x0000003f9aa21ed9 in IA__g_signal_emit_valist (instance=0x7ffff6b73170, signal_id=<value optimized out>, detail=0, 
    var_args=0x7fffffffd540) at gsignal.c:2980
#13 0x0000003f9aa22423 in IA__g_signal_emit (instance=0x42a0, signal_id=17056, detail=6) at gsignal.c:3037
#14 0x0000003d2741e962 in IA__gdk_display_close (display=0x7ffff6b73170) at gdkdisplay.c:185
#15 0x00007ffff7da2d51 in MOZ_gdk_display_close (display=0x7ffff6b73170) at nsAppRunner.cpp:2530
#16 0x00007ffff7da59ec in XRE_main (argc=2, argv=0x7fffffffdf98, aAppData=0x7ffff6b1f080) at nsAppRunner.cpp:3605
#17 0x0000000000401f1f in main (argc=2, argv=0x7fffffffdf98) at nsBrowserApp.cpp:158

gtk_clipboard_get() at nsClipboard::SelectionClearEvent() causes that assertion.

Comment 3

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Looks more seriously. With this small change:

@@ -659,14 +668,10 @@
 void
 nsClipboard::SelectionClearEvent(GtkClipboard *aGtkClipboard)
 {
-    PRInt32 whichClipboard;
+    PRInt32 whichClipboard = kGlobalClipboard; 
 
     // which clipboard?
-    if (aGtkClipboard == gtk_clipboard_get(GDK_SELECTION_PRIMARY))
-        whichClipboard = kSelectionClipboard;
-    else if (aGtkClipboard == gtk_clipboard_get(GDK_SELECTION_CLIPBOARD))
-        whichClipboard = kGlobalClipboard;
-    else
+    if(whichClipboard != kSelectionClipboard && whichClipboard != kGlobalClipboard)
         return; // THAT AIN'T NO CLIPBOARD I EVER HEARD OF
 
     EmptyClipboard(whichClipboard);

it crashes every time when firefox quits and we have some data stored in clipboard. The nsClipboard object seems to be already released but mozilla tries to clear it anyway:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffec670b2e in nsClipboard::SelectionClearEvent (this=0x7fffdf909fb0, aGtkClipboard=0x7fffdcb2a900)
    at nsClipboard.cpp:677
677	    EmptyClipboard(whichClipboard);

(gdb) p* this
$1 = {<nsIClipboard> = {<nsISupports> =	{_vptr.nsISupports = 0x0}, <No data fields>}, <nsIObserver> = {<nsISupports> = {
      _vptr.nsISupports	= 0x0},	<No data fields>}, mRefCnt = {mValue = 0}, _mOwningThread = {mThread = 0x0}, 
  mSelectionOwner = {mRawPtr = 0x0}, mGlobalOwner = {mRawPtr = 0x0}, mSelectionTransferable = {mRawPtr = 0x0}, 
  mGlobalTransferable =	{mRawPtr = 0x0}, mPrivacyHandler = {mRawPtr = 0x0}}

backtrace is the same as in comment 2.

Comment 4

[Karl Tomlinson (:karlt)]

Would calling gtk_clipboard_clear() from ~nsClipboard() for each clipboard that is not empty fix this?
(It would probably be more correct to call EmptyClipboard() from ~nsClipboard() too, though I'm not aware of any problems arising from not doing that.)

Comment 5

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

It's caused because we release whole XPCOM (with the nsClipboard object) before the gdk_display_close() call at nsAppRunner.cpp.

gdk_display_close() tries to clear and release an associated GtkClipboard (and its counterpart nsClipboard object) by clipboard_clear_callback but we did so already.

Comment 6

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Attachment: patch

Clear clipboard in ~nsClipboard(). We have to check if we actually own the clipboard before a gtk_clipboard_clear() call.

Comment 7

[Karl Tomlinson (:karlt)]

Comment on attachment 415620 [details] [diff] [review]
patch

>+    if(mGlobalTransferable) {

>+    if(mSelectionTransferable) {

Just add a space between each "if" and "(".
Mozilla does control structures and functions differently.

Comment 8

[Reed Loden [:reed]]

http://hg.mozilla.org/mozilla-central/rev/37728d6606e8

Comment 9

[Steven Michaud [:smichaud] (Retired)]

This still seems to be happening, at least intermittently (or maybe
it's started happening again):

http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unittest&logfile=1281364739.1281366546.18661.gz&buildtime=1281364739&buildname=Rev3%20Fedora%2012x64%20mozilla-central%20debug%20test%20mochitest-other&fulltext=1

Comment 10

[Steven Michaud [:smichaud] (Retired)]

See bug 557456 for more examples (in the test failure logs).

Comment 11

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Okay, Will check it, I have the same setup here (F12/x86_64 if I read the log correctly).

Comment 13

[u373683]

This patch causes an intermittent clearing issue. Please fix https://bugzilla.mozilla.org/show_bug.cgi?id=1649579

Thanks.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

Haven't seen this in a while, let's re-file if we have good STR.