libwnck内存泄漏

Question

我试着编译利伯恩克导论的第一个示例

#include <libwnck/libwnck.h>
int main (int argc, char **argv)
{
    WnckScreen *screen;
    WnckWindow *active_window;
    GList *window_l;

    gdk_init (&argc, &argv);
    screen = wnck_screen_get_default ();
    wnck_screen_force_update (screen);
    active_window = wnck_screen_get_active_window (screen);
    for (window_l = wnck_screen_get_windows (screen); window_l != NULL; window_l = window_l->next)
    {
        WnckWindow *window = WNCK_WINDOW (window_l->data);
        g_print ("%s%s\n", wnck_window_get_name (window),
                window == active_window ? " (active)" : "");
    }
    wnck_shutdown();
}

使用此命令行：

gcc -o testwnck testwnck.cpp -DWNCK_I_KNOW_THIS_IS_UNSTABLE `pkg-config --libs libwnck-3.0` `pkg-config --cflags libwnck-3.0`

但是当我在“英勇”中运行时，会出现许多错误。例如：

==20365== 96 bytes in 2 blocks are possibly lost in loss record 876 of 1,019
==20365==    at 0x4C28F40: malloc (vg_replace_malloc.c:296)
==20365==    by 0x6F6E0A0: g_malloc (in /usr/lib64/libglib-2.0.so.0.4200.0)
==20365==    by 0x6F84BB5: g_memdup (in /usr/lib64/libglib-2.0.so.0.4200.0)
==20365==    by 0x6CFD364: type_iface_vtable_base_init_Wm (in /usr/lib64/libgobject-2.0.so.0.4200.0)
==20365==    by 0x6CFE5BC: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.4200.0)
==20365==    by 0x6CE79D4: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.4200.0)
==20365==    by 0x6CE7BD3: g_object_new (in /usr/lib64/libgobject-2.0.so.0.4200.0)
==20365==    by 0x6745E6B: gdk_pixbuf_new_from_data (in /usr/lib64/libgdk_pixbuf-2.0.so.0.3000.8)
==20365==    by 0x4E60681: scaled_from_pixdata (in /usr/lib64/libwnck-3.so.0.2.2)
==20365==    by 0x4E62DE7: _wnck_read_icons (in /usr/lib64/libwnck-3.so.0.2.2)
==20365==    by 0x4E57F74: get_icons (in /usr/lib64/libwnck-3.so.0.2.2)
==20365==    by 0x4E58DC6: force_update_now (in /usr/lib64/libwnck-3.so.0.2.2)

在从主函数返回之前添加对wnck_shutdown()的调用没有帮助。我能做些什么来阻止这些错误？

编辑：我也尝试过使用val差Gtk抑制文件，但是我仍然有错误。

Answer 1

如果在使用最新GLib抑制文件时仍然报告泄漏，请使用对libwnck提出一个bug，因为它很可能是libwnck本身的泄漏。

但是，我怀疑您看到的分配是GObject为每个新的类实例分配一次的类型类分配之一，这些类实例从来没有被释放过(它们本质上是运行时的一部分)。但是这很好，因为它们只有一次，当第一次使用类型时。抑制文件应该会抑制它们。