[Ekiga-devel-list] Call history view bug, GmCellRendererBitext and gtk+
Hi, this is the tale of a bug hunt. It doesn't end as well as I would like. A strange bug, in fact: at startup, Eugen only sees one line per entry in his call history ; it becomes better only later. At startup, Julien (me) has one line and a half par entry (and it doesn't get better later because of the infamous clutter crash). The common problem is that two full lines should be there. So there might be something wrong with the initial population of the view, so the first thing is to try to print what data the call history view receives ; and the answer is : the engine part works! Only the view is to blame. So what exactly do we use to display that information, since obviously that is where the fault lies? The GmCellRendererBitext class, which is inheriting from GtkCellRendererText. If there's only one and a half line per entry, then that means that entries are overlapping, and that points to a problem with the get_size in that code. But why does it fail in the call history view and not in the roster view? In both case, our renderer is to the right of a pixbuf renderer. But in the roster view, the images are quite big images, while in the call history, those images are quite small. So in both cases, the size of our renderer in wrong, but in the roster, the presence of the big images means the lines are tall enough and there is no overlapping anyway. So I just had to fix the size computation. Unfortunately it turns out our gm_cell_renderer_bitext_get_size method wasn't called, ever. It's deprecated in gtk+ 3.something! There is some provision in the code to still call the obsolete api, but it apparently doesn't work. So yesterday I just added a few methods of the new api to detect the sizes, and committed that because it fixed the display problem (yes, I ran ekiga, and no, I didn't test calling because of the clutter crash). That made Eugen unhappy: I had added dozens of lines of code... and now it crashed after a while! Indeed, I was able to reproduce the crash. So today I made another try, this time trying to rework the code to be much, much simpler. In fact, I removed much of the code, trying to use as much as possible the underlying GtkCellRendererText class to avoid any problem. The code is simpler code, but even yesterday's code shouldn't have crashed, and did ; the dirty secret is a two year old bug: http://bugzilla.gnome.org/show_bug.cgi?id=668779 As you can see with the sample code in comment #8, there are simple uses of the gtk+ code which can easily give crashes. The fix from yesterday (fix for the display issues) was apparently putting us in exactly the right conditions to trigger the bug. The commit I pushed today has simplified the code much, and it looks like it doesn't trigger the crash... at least not as much, but I can hardly guarantee anything. That is were things stand for now: the good news is that the display bug is gone and the code is (much) lighter and simpler... but we know there is a crashing bug lurking :-/ Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Call history view bug, GmCellRendererBitext and gtk+
On 28/02/14 15:03, Julien Puydt wrote: Hi, this is the tale of a bug hunt. It doesn't end as well as I would like. A strange bug, in fact: at startup, Eugen only sees one line per entry in his call history ; it becomes better only later. At startup, Julien (me) has one line and a half par entry (and it doesn't get better later because of the infamous clutter crash). The common problem is that two full lines should be there. So there might be something wrong with the initial population of the view, so the first thing is to try to print what data the call history view receives ; and the answer is : the engine part works! Only the view is to blame. So what exactly do we use to display that information, since obviously that is where the fault lies? The GmCellRendererBitext class, which is inheriting from GtkCellRendererText. If there's only one and a half line per entry, then that means that entries are overlapping, and that points to a problem with the get_size in that code. But why does it fail in the call history view and not in the roster view? In both case, our renderer is to the right of a pixbuf renderer. But in the roster view, the images are quite big images, while in the call history, those images are quite small. So in both cases, the size of our renderer in wrong, but in the roster, the presence of the big images means the lines are tall enough and there is no overlapping anyway. So I just had to fix the size computation. Unfortunately it turns out our gm_cell_renderer_bitext_get_size method wasn't called, ever. It's deprecated in gtk+ 3.something! There is some provision in the code to still call the obsolete api, but it apparently doesn't work. So yesterday I just added a few methods of the new api to detect the sizes, and committed that because it fixed the display problem (yes, I ran ekiga, and no, I didn't test calling because of the clutter crash). That made Eugen unhappy: I had added dozens of lines of code... and now it crashed after a while! Indeed, I was able to reproduce the crash. So today I made another try, this time trying to rework the code to be much, much simpler. In fact, I removed much of the code, trying to use as much as possible the underlying GtkCellRendererText class to avoid any problem. The code is simpler code, but even yesterday's code shouldn't have crashed, and did ; the dirty secret is a two year old bug: http://bugzilla.gnome.org/show_bug.cgi?id=668779 As you can see with the sample code in comment #8, there are simple uses of the gtk+ code which can easily give crashes. The fix from yesterday (fix for the display issues) was apparently putting us in exactly the right conditions to trigger the bug. The commit I pushed today has simplified the code much, and it looks like it doesn't trigger the crash... at least not as much, but I can hardly guarantee anything. That is were things stand for now: the good news is that the display bug is gone and the code is (much) lighter and simpler... but we know there is a crashing bug lurking :-/ Thanks, Julien, for the description and for code simplification! I will test it. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
