Crash => critical

After banging on it for a bit, I managed to get it to crash once.

Gtk:ERROR:gtkcellrenderer.c:1722:gtk_cell_renderer_get_aligned_area: assertion failed: (aligned_area->x >= cell_area->x && aligned_area->x <= cell_area->x + cell_area->width)

This looks like a GTK+ bug or regression.

Created attachment 206260 [details]
Another backtrace, gtk+3 from git master

Committed a related fix to seahorse which limits positions of the sidebar slider. So to reproduce this, revert the following commit from seahorse:

commit fbec92a60515a8d1855cbe9fe30189c118581829
Author: Stef Walter <stefw@gnome.org>
Date:   Fri Jan 27 13:55:47 2012 +0100

    Add maximum and minimum sidebar pane position
    
    Related to: https://bugzilla.gnome.org/show_bug.cgi?id=668779

As a note when reproducing this doesn't happen every time, need to play around with it a bit before the assertion occurs (show and hide sidebar, select various keyrings, select various items).

Similar downstream bug report from Evolution 3.4.4, unfortunately without steps:
https://bugzilla.redhat.com/show_bug.cgi?id=870438

+ Trace 231095

I have the same problem with Nautilus 3.4.2 on a Gentoo Linux system. It crashes with the following error message:

**
Gtk:ERROR:gtkcellrenderer.c:1727:gtk_cell_renderer_get_aligned_area: assertion failed: (aligned_area->x >= cell_area->x && aligned_area->x <= cell_area->x + cell_area->width)
Aborted

Steps to reproduce:
1) Open Nautilus
2) Click on the "Home" directory in the Places sidebar
3) Reduce the width of the Places sidebar until it is very narrow

In all truth, I can make it crash by selecting other directories too, such as "File system" or "Trash", but it doesn't always crash. I can't really understand the exact conditions for it to crash realiably.

I'm attaching a backtrace. In order to obtain it, I recompiled nautilus, gtk+ and glib with the following Portage variables:

CFLAGS="-march=core2 -O1 -pipe -ggdb"
CXXFLAGS="-march=core2 -O1 -pipe -ggdb"
FEATURES="nostrip"

Please tell me if more informations are needed.

Created attachment 227536 [details]
GDB backtrace for Nautilus 3.4.2

I can still reproduce with 3.8.2

Here is a small test case:

1. execute it
2. click on the resize grip (bottom right corner)
3. resize the window to with -> 0 and back
4. repeat multiple times
4. after 5-20 times resizing it crashes


###################
from gi.repository import Gtk, Pango

class CellRendererTextWindow(Gtk.Window):

    def __init__(self):
        Gtk.Window.__init__(self, title="CellRendererText Example")

        self.set_default_size(150, 200)

        self.liststore = Gtk.ListStore(str, str)
        for i in range(50):
            self.liststore.append(["gtk-info", "bla"])

        treeview = Gtk.TreeView(model=self.liststore)
        treeview.set_headers_visible(False)

        renderer_text = Gtk.CellRendererPixbuf()
        column_text = Gtk.TreeViewColumn("Text", renderer_text, stock_id=0)
        column_text.set_sizing(Gtk.TreeViewColumnSizing.FIXED)
        column_text.set_fixed_width(50)
        treeview.append_column(column_text)

        sw = Gtk.ScrolledWindow()
        sw.set_policy(Gtk.PolicyType.NEVER, Gtk.PolicyType.AUTOMATIC)
        sw.add(treeview)

        self.add(sw)


win = CellRendererTextWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
Gtk.main()
###########

I found this bug while looking for why a renderer implementation in ekiga which was previously good was giving headaches.

I tried the above example with 3.10.7-1 (debian unstable), and it crashes.

In the case of ekiga, no resizing of the window is involved ; it's just that the widget's information gets updated and for some reason the size computations are off... We override get_preferred_height and get_preferred_width, and the implementation updates the parent properties before calling the parent methods to compute the size.

I'm quite surprised a two year old bug with several reports and even a minimal example is still UNCONFIRMED... Is there something I can do to help?

Created attachment 281146 [details]
Crash while using rhythmbox

Crashes while using rhythmbox on latest debian sid amd64.

Steps to reproduce:

1. Open rhythmbox -> postcast -> New downloads ( I had 5 podcasts entry as shown in the attachment 1 [details].1 )

2. Select the column divider before 'Title' column  ( attachment 2 [details].1 ). 

3. Now resize it to extreme right, so that only 'Date' column is displayed in the entire space. ( attachment 2 [details].2 ) Do not release the mouse.

4. Repeat the resize process from extreme right to extreme left ( attachment 2 [details].3 ). Do not release the mouse.

5. Keep repeating 3 and 4.

6. rhythmbox crashes.

Created attachment 281147 [details]
attachment 1 [details]

Created attachment 281148 [details]
attachment 2 [details].1

Created attachment 281149 [details]
attachment 2 [details].2

Created attachment 281150 [details]
attachment 2 [details].3

I haven't been able to reproduce the crash with the comment 8 anymore so I bisected the git repo to find the first good commit and found that this commit fixed it:
commit a3cd0ee7d8a610feff39984254306cec4a6c9c73
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Sun Jun 1 10:16:01 2014 -0400

    Revert "Use minimum/natural size semantics"
    
    This reverts commit 6d53c2339f79baa0b295ecc614f41f9daab2e132.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=731054 showed some
    major regressions caused by this commit.


So this is fixed as of GTK 3.13.3. Could someone close this bug and mark this as duplicate of bug 731054? Thanks!

I haven't seen that crash in quite some time, so sounds plausible.
Thanks for bisecting.