Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(112)

Issue 159166: gtk: Two fixes for the tab leak:... (Closed)

Created:
11 years, 5 months ago by James Hawkins
Modified:
9 years, 7 months ago
Reviewers:
tony, dank
CC:
chromium-reviews_googlegroups.com, not_the_right_glider, Nirnimesh, dank, the_wrong_timurrrr, stuartmorgan, Ben Goodger (Google)
Visibility:
Public.

Description

gtk: Two fixes for the tab leak: * The tab strip handles the lifetime of the tab widget, so don't try to increase the ref count in order to destroy the widget later. * Use DeleteSoon when deleting the dragged tab in order to give gtk a chance to clean up its ref counts added during the drag operation. BUG=12863 TEST=Extensive tab dragging. No crashes and the Linux UI valgrind bot should stay green. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=21230

Patch Set 1 #

Total comments: 1
Unified diffs Side-by-side diffs Delta from patch set Stats (+4 lines, -16 lines) Patch
M chrome/browser/gtk/tabs/tab_gtk.cc View 2 chunks +0 lines, -3 lines 0 comments Download
M chrome/browser/gtk/tabs/tab_strip_gtk.cc View 1 chunk +4 lines, -1 line 1 comment Download
M tools/valgrind/memcheck/suppressions.txt View 1 chunk +0 lines, -12 lines 0 comments Download

Messages

Total messages: 3 (0 generated)
James Hawkins
11 years, 5 months ago (2009-07-21 22:38:50 UTC) #1
tony
LGTM if you are confident that there's no race here. http://codereview.chromium.org/159166/diff/1/4 File chrome/browser/gtk/tabs/tab_strip_gtk.cc (right): http://codereview.chromium.org/159166/diff/1/4#newcode835 ...
11 years, 5 months ago (2009-07-21 22:55:44 UTC) #2
James Hawkins
11 years, 5 months ago (2009-07-21 23:04:20 UTC) #3
On 2009/07/21 22:55:44, tony wrote:
> LGTM if you are confident that there's no race here.
> 
> http://codereview.chromium.org/159166/diff/1/4
> File chrome/browser/gtk/tabs/tab_strip_gtk.cc (right):
> 
> http://codereview.chromium.org/159166/diff/1/4#newcode835
> Line 835: MessageLoop::current()->DeleteSoon(FROM_HERE, tab);
> You're sure that the gtk d&d api will get to run before the tab is deleted?

Yes, the current call flow is:

(gtk signal) drag-end
TabGtk::OnDragEnd {
 -> TabStripGtk::EndDrag
  -> DraggedTabControllerGtk::EndDrag
   ...
   -> TabStripGtk::DestroyDraggedSourceTab
    -> delete tab;
}
(gtk) release drag references

And after the patch:

(gtk signal) drag-end
TabGtk::OnDragEnd {
 -> TabStripGtk::EndDrag
  -> DraggedTabControllerGtk::EndDrag
   ...
   -> TabStripGtk::DestroyDraggedSourceTab
    -> DeleteSoon(tab);
}
(gtk) release drag references
delete tab;

So basically in the UI thread, gtk gets control immediately after we return from
handling the drag-end signal and then gets back into the message loop.  There's
no way for us to jump in the middle of this flow before the references are
released.

Powered by Google App Engine
This is Rietveld 408576698