ОС - Manjaro 15.12 (OpenRC) GTK+ - 3.18.9-1 QT - 4.8.7-7
Помогите пожалуйста разобраться с утечками. Пишу программу, хотел проверить все ли ресурсы я высвобождаю. Взял valgrind и заметил что даже GTK примеры с офф сайта показывают утечку. Вот пример с сайта GTK только без комментариев:
#include <gtk/gtk.h>
static void
print_hello (GtkWidget *widget,
gpointer data)
{
g_print ("Hello World\n");
}
static void
activate (GtkApplication *app,
gpointer user_data)
{
GtkWidget *window;
GtkWidget *grid;
GtkWidget *button;
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "Window");
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
grid = gtk_grid_new ();
gtk_container_add (GTK_CONTAINER (window), grid);
button = gtk_button_new_with_label ("Button 1");
g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL);
gtk_grid_attach (GTK_GRID (grid), button, 0, 0, 1, 1);
button = gtk_button_new_with_label ("Button 2");
g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL);
gtk_grid_attach (GTK_GRID (grid), button, 1, 0, 1, 1);
button = gtk_button_new_with_label ("Quit");
g_signal_connect_swapped (button, "clicked", G_CALLBACK (gtk_widget_destroy), window);
gtk_grid_attach (GTK_GRID (grid), button, 0, 1, 2, 1);
gtk_widget_show_all (window);
}
int
main (int argc,
char **argv)
{
GtkApplication *app;
int status;
app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
status = g_application_run (G_APPLICATION (app), argc, argv);
g_object_unref (app);
return status;
}
И вот что выдаёт valgrind:
==24833== Memcheck, a memory error detector
==24833== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24833== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24833== Command: ./a.out
==24833==
** (a.out:24833): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
==24833==
==24833== HEAP SUMMARY:
==24833== in use at exit: 1,609,694 bytes in 18,691 blocks
==24833== total heap usage: 147,225 allocs, 128,534 frees, 11,600,341 bytes allocated
==24833==
==24833== LEAK SUMMARY:
==24833== definitely lost: 1,792 bytes in 4 blocks
==24833== indirectly lost: 6,480 bytes in 275 blocks
==24833== possibly lost: 4,471 bytes in 50 blocks
==24833== still reachable: 1,493,103 bytes in 17,524 blocks
==24833== of which reachable via heuristic:
==24833== length64 : 6,512 bytes in 104 blocks
==24833== newarray : 2,160 bytes in 55 blocks
==24833== suppressed: 0 bytes in 0 blocks
==24833== Rerun with --leak-check=full to see details of leaked memory
==24833==
==24833== For counts of detected and suppressed errors, rerun with: -v
==24833== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Если я правильно трактую вывод, то как минимум 1,792 bytes потеряны. Здесь в ответах разъясняют почему так получается, если я правильно для себя перевёл ответ, то утечки в gtk есть и будут, но это не проблема, т.к. по завершению работы вся память будет возвращена системе. Так ли это, на сколько это критично, значит ли что освобождением ресурсов в gtk программах можно вообще не озабочиваться? И есть ли хорошая альтернатива?
Аналогичная ситуация получилась с Qt:
#include <QApplication>
#include <QLabel>
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QLabel hello("Hello world!");
hello.show();
return app.exec();
}
Вывод valgrind:
==25664== Memcheck, a memory error detector
==25664== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==25664== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==25664== Command: ./hello
==25664==
==25664==
==25664== HEAP SUMMARY:
==25664== in use at exit: 1,719,534 bytes in 15,419 blocks
==25664== total heap usage: 57,953 allocs, 42,534 frees, 12,142,263 bytes allocated
==25664==
==25664== LEAK SUMMARY:
==25664== definitely lost: 3,936 bytes in 15 blocks
==25664== indirectly lost: 12,890 bytes in 512 blocks
==25664== possibly lost: 4,390 bytes in 49 blocks
==25664== still reachable: 1,446,678 bytes in 13,824 blocks
==25664== of which reachable via heuristic:
==25664== length64 : 7,064 bytes in 80 blocks
==25664== newarray : 6,152 bytes in 39 blocks
==25664== suppressed: 0 bytes in 0 blocks
==25664== Rerun with --leak-check=full to see details of leaked memory
==25664==
==25664== For counts of detected and suppressed errors, rerun with: -v
