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