Re: [Pan-users] Pan bug 712539 and 757672

[Rhialto]

On Tue 08 Mar 2016 at 21:56:11 +0100, Petr Kovar wrote:
> Tested with fa0d4f077d4b68c6d7b3533b84735fbb6aa0cb72 and had no crashes
> after running some basic tasks such as getting new headers and downloading
> a few articles. Still got a core dump at exit but that bug is present in
> master as well...

Valgrind (from valgrind.org) is a very nice tool to find that sort of
errors: use of unallocated memory (read and write), use-after-free,
double free...  Pan has a pile of such problems. See below for an easy
one.

I have consolidated the fixes from branch filterinfo in a new branch,
filterinfo2.  I have been thinking about an additional change, in
scorefile.cc:normalize_test():

    *test = *test->_aggregates[0];

to

    FilterInfo tmp(*test->_aggregates[0]);
    *test = tmp;

but some tests didn't show any problems with the original version in
practice. (That is no guarantee of course; optimizations and new
compiler versions may change the outcome.)

The scenario I'm fearing is that possibly the old value of the
left-hand-side *test gets destructed before a copy is made of the
right-hand-side *test->_aggregates[0].  And said destruction would
include the destruction of the rhs, since it is "part" of it.

Back to Valgrind.
One problem that is easily found with Valgrind is this one:

==11396== Invalid read of size 8
==11396==    at 0x60F8885: g_type_check_instance_is_fundamentally_a (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x47709B: pan::BodyPane::clear_attachments() (body-pane.cc:1640)
==11396==    by 0x478B9E: pan::BodyPane::set_text_from_message(_GMimeMessage*) 
(body-pane.cc:1261)
==11396==    by 0x466C8A: pan::GUI::root_realized_cb(_GtkWidget*, void*) 
(gui.cc:210)
==11396==    by 0x60D4014: g_closure_invoke (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60E6060: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60EEDFB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60EF12E: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x5290F53: gtk_widget_realize (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
==11396==    by 0x5291157: gtk_widget_map (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
==11396==    by 0x52A18F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
==11396==    by 0x60D4243: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==  Address 0x16c41bc0 is 0 bytes inside a block of size 152 free'd
==11396==    at 0x4C2CE2B: free (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11396==    by 0x60F76A9: g_type_free_instance (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60D7123: g_cclosure_marshal_VOID__OBJECTv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60D4243: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60EEA45: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60EF12E: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x477087: pan::BodyPane::clear_attachments() (body-pane.cc:1639)
==11396==    by 0x478B9E: pan::BodyPane::set_text_from_message(_GMimeMessage*) 
(body-pane.cc:1261)
==11396==    by 0x466C8A: pan::GUI::root_realized_cb(_GtkWidget*, void*) 
(gui.cc:210)
==11396==    by 0x60D4014: g_closure_invoke (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60E6060: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60EEDFB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==  Block was alloc'd at
==11396==    at 0x4C2BBCF: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11396==    by 0x6366578: g_malloc (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
==11396==    by 0x637D762: g_slice_alloc (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
==11396==    by 0x637DDFD: g_slice_alloc0 (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
==11396==    by 0x60F7371: g_type_create_instance (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60D938A: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60DAC70: g_object_newv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x60DB5A3: g_object_new (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)
==11396==    by 0x51F9E72: gtk_table_new (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
==11396==    by 0x476FC1: 
pan::BodyPane::create_attachments_toolbar(_GtkWidget*) (body-pane.cc:1701)
==11396==    by 0x478B9E: pan::BodyPane::set_text_from_message(_GMimeMessage*) 
(body-pane.cc:1261)
==11396==    by 0x60D4014: g_closure_invoke (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.1)

This is a simple one because this is the source:

1639    gtk_container_remove (GTK_CONTAINER (_att_frame), _att_toolbar);
1640    if (G_IS_OBJECT(_att_toolbar)) g_object_unref(_att_toolbar);

where the object is deleted at 1639 and touched again in 1640.
 
It turns out that the manual says that gtk_container_remove() may delete
the object if the refcount drops to zero. Which seems to happen here
since I found nothing to increase it (and I presume that on allocation
in line 1701 it starts out with 1). So removing the second line would
fix this issue.

Not all are this simple, but it is a good help :)

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'

signature.asc
Description: PGP signature