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
_______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
