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

[Rhialto]

On Wed 16 Mar 2016 at 19:55:45 +0100, Detlef Graef wrote:
> (socket-impl-openssl.cc:425:gnutls_close) gnutls close 0x7f195810cc90
> (data-impl.cc:127:save_state) data-impl dtor saving xov, newsrc...
> 
> (pan:18844): GLib-CRITICAL **: Source ID 4538 was not found when
> attempting to remove it
> *** Error in `pan/gui/pan': corrupted double-linked list:
> 0x00000000014ff6f0 ***
> ======= Backtrace: =========
> /lib64/libc.so.6(+0x77da5)[0x7f198cd56da5]
> /lib64/libc.so.6(+0x7ee23)[0x7f198cd5de23]
> /lib64/libc.so.6(+0x807a8)[0x7f198cd5f7a8]
> /lib64/libc.so.6(cfree+0x4c)[0x7f198cd62cac]
> pan/gui/pan(_ZN3pan8DataImplD1Ev+0x7a4)[0x4e5e64]
> pan/gui/pan(main+0xf0d)[0x45e9cd]
> /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f198ccff580]
> pan/gui/pan(_start+0x29)[0x460a09]
> 
> I haven't had a closer look at this at the moment, but it seems it
> happens after:
> 
> (data-impl.cc:127:save_state)

Hm, somewhat near there I did find a memory leak, but my potential fix
for that would not included in what you're running, right?

https://github.com/Rhialto/pan2/commit/9ab061771fcea7a31d8722fcd7e98d6b3c002958

I've been looking at a few more of those valgrind memory leaks, but I
get the impression that there is a lot of memory leaking in
libfontconfig and/or libcairo and/or libpangocairo and/or libpangoft2
and/or libpango and/or libgtk-x11. Pan probably can't do much about
that. Rather annoying that Ubuntu has seemingly stripped most of those
libraries so that we can't see the function names in the stack trace.

A large number of the stack traces are much like the one below. I've
needed to increase the length of the trace, since the first 12 are
simply not in Pan at all. Finally all the way at the bottom we get to
the constructor of BodyPane, BodyPane::BodyPane(...) (body-pane.cc:1823).
From what I see, Pan cleans up what it allocates (line 1823 is
  gtk_container_add (GTK_CONTAINER(_scroll), _text);
my line numbers may differ due to extra debugging stuff I put in).

Below this one I've put what I think is a false positive, and why.
But it is only a "possibly lost" one.

6,488 (512 direct, 5,976 indirect) bytes in 1 blocks are definitely lost in 
loss record 11,083 of 11,133
   at 0x4C2DD9F: realloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x700B8EA: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0)
   by 0x700C0B9: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0)
   by 0x700C3DF: FcPatternAddInteger (in 
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0)
   by 0x5E2A191: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.2)
   by 0x594A41F: ??? (in 
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.3600.8)
   by 0x6633851: ??? (in /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.3600.8)
   by 0x6857528: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x68587B7: pango_itemize_with_base_dir (in 
/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x686082D: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x68626E7: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x59470FB: ??? (in 
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.3600.8)
   by 0x685CC6E: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x686046E: pango_layout_line_get_extents (in 
/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x686268E: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x6862939: ??? (in /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.3600.8)
   by 0x521D6DC: gtk_text_layout_get_line_display (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x521E779: gtk_text_layout_get_cursor_locations (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x5229FE6: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x522A0D0: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x522A96C: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x6A9D014: g_closure_invoke (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AAF60D: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AB7DFB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AB812E: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x5289C83: gtk_widget_set_scroll_adjustments (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x51D1B56: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x6AA0116: g_cclosure_marshal_VOID__OBJECTv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6A9D243: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AB7A45: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AB812E: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x4802BA: pan::BodyPane::BodyPane(pan::Data&, pan::ArticleCache&, 
pan::Prefs&, pan::GroupPrefs&, pan::Queue&, pan::HeaderPane*) 
(body-pane.cc:1823)

FALSE POSITIVE:

496 bytes in 1 blocks are possibly lost in loss record 10,553 of 10,974
   at 0x4C2DD9F: realloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x6D2F637: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
   by 0x6AB9A78: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6ABF36C: g_type_register_static (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6A9E4AD: g_enum_register_static (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x527FBBA: gtk_progress_bar_style_get_type (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x51AA045: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
   by 0x6ABD2CC: g_type_class_ref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AA3E1C: g_object_newv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x6AA45A3: g_object_new (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
   by 0x4C82A4: pan::ProgressView::ProgressView() (progress-view.cc:34)
   by 0x465801: pan::GUI::GUI(pan::Data&, pan::Queue&, pan::Prefs&, 
pan::GroupPrefs&) (gui.cc:326)
   by 0x475E56: main (pan.cc:1096)

the GtkProgressBar is a GInitiallyUnowned

This *seems* to be a false positive, because

in ProgressView::ProgressView ():
  _progressbar (gtk_progress_bar_new ()),
  which is attached to 
  _root (gtk_event_box_new ()),

GUI :: root_realized_cb (GtkWidget*, gpointer self_gpointer)
  allocates 3 ProgressViews and attaches the _root (via v->root())
  to _taskbar, to status_bar, to _root. _root is available via root().

In pan.cc:main() a GUI is allocated, and a window, and GUI->root() is
connected to said window in run_pan_in_window().
    gtk_container_add (GTK_CONTAINER(window), gui.root());
At the end, the window is destroyed and the global ref deleted:
    gtk_widget_destroy (GTK_WIDGET(window));

-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