LINUX.ORG.RU

gtk+ утечка памяти


0

0

Доброго времени суток ЛОР. Есть следующий код:

void loading(GtkWidget *widget, const char* file_path, MainWin* mw)
{
	GError* error; 
        gssize n_read;
	gboolean res;
	guchar buffer[LOAD_BUFFER_SIZE];
	GInputStream* input_stream;
	GFile *file = g_file_new_for_path(file_path);

        mw->loader =    gdk_pixbuf_loader_new();
	mw->animation = gdk_pixbuf_animation_new_from_file(file_path,error);	
	input_stream = g_file_read(file, generator_cancellable , NULL);
	
	res = TRUE;
	
	while (1){
		n_read = g_input_stream_read(input_stream, buffer, sizeof (buffer),generator_cancellable,error);
		
		if (n_read < 0) {
                        res = FALSE;
                        error = NULL; 
			            gdk_pixbuf_loader_close(mw->loader,NULL);
			            g_input_stream_close(input_stream,NULL,NULL);  
                        break;
                }
	
	if (n_read == 0)
        break;
	
	if (!gdk_pixbuf_loader_write(mw->loader, buffer, sizeof(buffer), error)){
	   res = FALSE;
	   g_input_stream_close(input_stream,NULL,NULL);
	   gdk_pixbuf_loader_close(mw->loader,NULL);
       break;
	   }
	
	if (res){		

      if ( !gdk_pixbuf_animation_is_static_image(mw->animation ) )
		gtk_action_group_set_sensitive(rotation_actions, FALSE);
	  else
		gtk_action_group_set_sensitive(rotation_actions, TRUE);
        		
		mw->animation = gdk_pixbuf_loader_get_animation((mw->loader));
	    gtk_anim_view_set_anim (mw->aview,mw->animation);	
	}
  }
	g_input_stream_close(input_stream,NULL,NULL);
	gdk_pixbuf_loader_close(mw->loader,NULL);
}

Данный код загружает изображение расположенное по адресу file_path в GtkAnimView виджет. Дело в том что при каждом вызове этой функции а следовательно при епждой загрузке и отображении какого-либо изображения прибавляется память занимаемая приложением. В чем проблема вроде все позакрывал?

Спасибо



Последнее исправление: shk (всего исправлений: 1)

Во-первых, GError* всегда перед использованием надо инитить в NULL.

error = NULL;

Это что за новомодная проверка ошибки? А кто будет чистить ресурсы в случае ее возникновения?

В чем проблема вроде все позакрывал?

Ты вообще про GObject хоть что-то читал или нет? От того, что ты что-то позакрывал, толку мало. Надо еще объекты удалить, g_object_unref (). Я даже дальше логику твоего кода смотреть не стал, потому что у тебя тут уже полный ахтунг. Настоятельно советую прочитать руководство по GObject.

MuZHiK-2 ★★★★
()
Ответ на: комментарий от mono

>>P.S. а вообще, gtk+ сама по себе текучая штука.

С прямыми руками как бы ничего не течет.

MuZHiK-2 ★★★★
()
Ответ на: комментарий от MuZHiK-2

И да, я вообще не понял, зачем тебе переменная error. Ты лепишь ее к месту и не к месту, и притом совершенно неправильно. Лучше вместо нее NULL передавай.

MuZHiK-2 ★★★★
()
Ответ на: комментарий от ananas

+1

только на это беглый взор наводит мысли. в остальном вроде все ок.

Deleted
()
Ответ на: комментарий от Deleted

не совсем. основная беда gtk - многие конструкторы неявным/недокументированным образом выделяют память, которую надо освобождать. новичков это частенько вгоняет в ступор. так что в этом плане гтк достаточно текуч

ananas ★★★★★
()
Ответ на: комментарий от MuZHiK-2

> Это что за новомодная проверка ошибки? А кто будет чистить ресурсы в случае ее возникновения?

ошибок не возникало. иначе был бы сегфолт, а не утечка. потому как он передает error, а не &error

ananas ★★★★★
()
Ответ на: комментарий от ananas

>>ошибок не возникало. иначе был бы сегфолт, а не утечка. потому как он передает error, а не &error

Кстати, да. Там компилятор должен был материться. В любом случае, ТС использует GError через одно всем известное место.

MuZHiK-2 ★★★★
()
Ответ на: комментарий от ananas

не совсем. основная беда gtk - многие конструкторы неявным/недокументированным образом выделяют память, которую надо освобождать. новичков это частенько вгоняет в ступор. так что в этом плане гтк достаточно текуч

Я как делаю. Беру Gtkmm и использую RefPtr для всех обьектов, для своих и для Gtk. Будет течь?

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

c gtkmm не работал, и сложно сказать, как и что там реализовано. но учитывая отсутствие gc как в с++ вообще, так и в gtkmm в частности, и если ты не следишь за памятью сам - скорее всего будет.

ananas ★★★★★
()
Ответ на: комментарий от ananas

Это простой основаный на scope счетчик ссылок. Если все обьекты заключить в RefPtr, то можешь считать, что пишешь на Vala. ref/unref - автоматически

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

а если неявным образом используются всевозможные g_strdup_printf() сотоварищи? в подобных обертках они могут быть достаточно хитро замаскированы, и, учитывая, что доков с гулькин хрен, иной раз совсем забавные ляпсусы могут вылезти.

как пример - glibc валится нафиг при strlen(NULL). и пока я не пропатчил глибцы для избавления от этого наваждения - лаги при отладке glib/gtk приложений вылазили просто фантастические и очень трудно отлавливаемые. а с памятью зачастую еще сложнее. особенно, если ладишь на линковке с оптимизированными версиями, где нет отладочной инфы

ananas ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.