Liqueo de Memoria que no logro encontrar

MeduZaPaT · #1 (**permalink**) 24/01/2009, 18:30

Hola, estuve trabajando en un plugin para un proyecto que estoy desarrollando, este trabaja con la libreria dbus-glib, soy nuevo usando esta libreria y luego de romperme la cabeza vastante logre lo que necesitaba, posiblemente este mal implementada y me gustaria saberlo.
Mi programa funciona bien, excepto por un detalle, se va comiendo la memoria de a poco, 4Kb unas 10 veces por segundo, y el liqueo de memoria no lo encuentro, si alguien me puede dar una mano lo agradeceria enormemente

El problema esta aca adentro (de la funcion que adjunto), eso es llamado no mas de 10 veces por segundo, la primera vez todo va bien, pero en la segunda ya empieza da tragar memoria,
quisas me esta faltando liberar algo.

Código:

bool leetodo(bateria &Bateria,gboolean lnombres,gboolean lcarga, gboolean lestado){
	GError *el_error = NULL;
	gboolean result;
	DBusGProxy *proxy = NULL;
	proxy = get_dbus_proxy("org.freedesktop.Hal", Bateria.udi.c_str(), "org.freedesktop.Hal.Device");
	if(lnombres){
		char *nombre, *tipo, *tecnologia;
		result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
				G_TYPE_STRING, "info.product", G_TYPE_INVALID,
				G_TYPE_STRING, &nombre, G_TYPE_INVALID);
		if(error_happened(result, el_error)) Bateria.nombre = "N/A";
		else{
			Bateria.nombre = nombre;
			g_free(nombre);
		}
		el_error = NULL;
		result = dbus_g_proxy_call(proxy, "GetPropertyString", &el_error,
					G_TYPE_STRING, "battery.type",G_TYPE_INVALID,
					G_TYPE_STRING, &tipo, G_TYPE_INVALID);
		if(error_happened(result, el_error)) Bateria.tipo = "N/A";
		else{
			Bateria.tipo = tipo;
			g_free(tipo);
		}
		el_error = NULL;
		result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
					G_TYPE_STRING, "battery.reporting.technology", G_TYPE_INVALID,
					G_TYPE_STRING, &tecnologia, G_TYPE_INVALID);
		if(error_happened(result, el_error)) Bateria.tecnologia = "N/A";
		else{
			Bateria.tecnologia = tecnologia;
			g_free(tecnologia);
		}
	}
	if(lcarga){
		gint ultima, ahora;
		Bateria.carga  = 0;
		el_error = NULL;
		result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
				G_TYPE_STRING, "battery.charge_level.last_full", G_TYPE_INVALID, G_TYPE_INT, &ultima, G_TYPE_INVALID);
		if(!error_happened(result, el_error)){
			el_error = NULL;
			result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
					G_TYPE_STRING, "battery.charge_level.current",G_TYPE_INVALID,
					G_TYPE_INT, &ahora, G_TYPE_INVALID);
			if(!error_happened(result, el_error)){
				if(ultima < 1) ultima = 1;
				Bateria.carga = (ahora*100 / ultima*100) /100;
			}
		}
	}
	if(lestado){
		gboolean presente, recargable, cargando, descargando;
		el_error = NULL;
		result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
				G_TYPE_STRING, "battery.present",G_TYPE_INVALID,
				G_TYPE_BOOLEAN, &presente,G_TYPE_INVALID);
		if(!error_happened(result, el_error)){
			if(!presente) Bateria.estado  = "Missing";
			else{
				el_error = NULL;
				result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
							G_TYPE_STRING, "battery.is_rechargeable",G_TYPE_INVALID,
							G_TYPE_BOOLEAN, &recargable,G_TYPE_INVALID);
				if(!error_happened(result, el_error)){
					if(!recargable)	Bateria.estado  = "Ready";
					else{
						el_error = NULL;
						result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
								G_TYPE_STRING, "battery.rechargeable.is_charging",G_TYPE_INVALID,
								G_TYPE_BOOLEAN, &cargando,G_TYPE_INVALID);
						if(!error_happened(result, el_error)){
							if(cargando) Bateria.estado  = "Charging";
							else{
								el_error = NULL;
								result = dbus_g_proxy_call(proxy, "GetProperty", &el_error,
											G_TYPE_STRING, "battery.rechargeable.is_discharging",G_TYPE_INVALID,
											G_TYPE_BOOLEAN, &descargando, G_TYPE_INVALID);
								if(!error_happened(result, el_error)){
									if(descargando) Bateria.estado  = "Working";
									else Bateria.estado  = "Ready";
								}
							}
						}
					}
				}
			}
		}
	}
	if (proxy != NULL) g_object_unref(proxy);
	return true;
}

si necesitan otra funcion la pondre pero creo que el error esta alli

Muchas gracias.

MeduZaPaT · #2 (**permalink**) 27/01/2009, 11:23

viendo que nadie por aca entiende de esto, alguno sabe donde puedo postear mi problema, algun mailing list de glib o algun lugar mas especializado?

Eternal Idol · #3 (**permalink**) 27/01/2009, 18:13

Depuralo para saber en donde se reserva la memoria que segun vos no se esta liberando (no se en que te basas para decir eso) y cual es la razon por la cual no se libera.

PD. Supongo que no esperabas que nos tomaramos el trabajo de conseguir la libreria y compilar ese trozo de codigo ...

MeduZaPaT · #4 (**permalink**) 28/01/2009, 06:54

Cita:

Iniciado por Eternal Idol

Depuralo para saber en donde se reserva la memoria que segun vos no se esta liberando (no se en que te basas para decir eso) y cual es la razon por la cual no se libera.

PD. Supongo que no esperabas que nos tomaramos el trabajo de conseguir la libreria y compilar ese trozo de codigo ...

no es segun yo, sino segun el systema, lo veo con mis propios ojos que cada vez que pasa por el loop que tiene los dbus_g_proxy_call se come ~4Kb cada llamada, no lo estoy inventando.

lo depure varias veces, funciona perfecto pero se come ~4Kb de ram cada vez que pasa por una de esas funciones.

No supongo nada, solo esperaba encontrar alguien que sepa del tema y me orientara si estoy haciendo algo mal.
Tampoco espero nada, estoy aca por si alguen buena onda me quiere ayudar, mi proyecto es GPL, y podes bajar el codigo y compilarlo cuando quieras.

Eternal Idol · #5 (**permalink**) 28/01/2009, 07:08

Cita:

Iniciado por MeduZaPaT

no es segun yo, sino segun el systema, lo veo con mis propios ojos que cada vez que pasa por el loop que tiene los dbus_g_proxy_call se come 4Kb, no lo estoy inventando.

No decis donde estas viendo que pasa ni que tipo de valor es el medido exactamente ...

Cita:

Iniciado por MeduZaPaT

lo depure varias veces, funciona perfecto pero se come 4Kb de ram cada vez que pasa por una de esas funciones.

Muy bien; ahora solo te falta determinar cual es en particular la funcion (o funciones; o tal vez este el problema dentro del bucle) problematica y a que reserva se debe, 4KB de memoria suelen ser nada mas y nada menos que una pagina (la minima unidad de memoria que reserva el sistema realmente) con lo cual puede ser que este reservando 1 byte unicamente (por poner un ejemplo burdo) con una funcion/operador de alto nivel tipo malloc/new.

Cita:

Iniciado por MeduZaPaT

No supongo nada, solo esperaba encontrar alguien que sepa del tema y me orientara si estoy haciendo algo mal.

Entonces esperabas que analizaramos el codigo y obtuvieramos de el una respuesta que no pudiste encontrar depurandolo, muy bien, eso suena a algo que tal vez pueda hacer alguien que escribio esa libreria o se paso ya largo rato depurando su funcionamiento interno.

Cita:

Iniciado por MeduZaPaT

Tampoco espero nada, estoy aca por si alguen buena onda me quiere ayudar, mi proyecto es GPL, y podes bajar el codigo y compilarlo cuando quieras.

No encuentro el nombre de tu proyecto en este hilo, igual no es mi intencion depurarlo, sino a lo sumo tirar una lineas a seguir que sean utiles y puedan ayudar a resolver el problema mas rapido.

MeduZaPaT · #6 (**permalink**) 28/01/2009, 18:52

Cita:

Iniciado por Eternal Idol

Muy bien; ahora solo te falta determinar cual es en particular la funcion (o funciones; o tal vez este el problema dentro del bucle) problematica y a que reserva se debe, 4KB de memoria suelen ser nada mas y nada menos que una pagina (la minima unidad de memoria que reserva el sistema realmente) con lo cual puede ser que este reservando 1 byte unicamente (por poner un ejemplo burdo) con una funcion/operador de alto nivel tipo malloc/new.

si comento esta funcion "dbus_g_proxy_call" bye bye problema y bye bye los datos que necesito, estuve pensando que capas esas llamadas se deben hacer solo una vez y con alguna otra funcion se actualiza el dato en la variable que referencie, sino para que cuernos usamos el g_type_init () o el main_loop de glib.

Yo vine aca buscando ayuda, es la primera vez que uso dbus con glib, no digo que miren el codigo o lo compilen los que nunca lo usaron, pero capas alguien ya uso esas librerias y me dice - " no flaco asi no es" o " tenes que usarla de otra manera"

Como sea si ejecuto 4 veces "dbus_g_proxy_call" se van 16Kb de ram.

como hago para ver la comida de ram:
ejecuto mi programa y espero que empiece a usar el plugin que arriba publique, cuando se ejecuta en el System Monitor veo como el tamaño de ram que esta clabado en 380kb empieza a comerse de a multiplos de 4Kb.
si lo dejo un rato largo llega a 2Mb y si lo dejo mas tiempo sigue creciendo osea no para nunca. cuando lo que deberia usar son solo 380Kb todo el tiempo.

Eternal Idol · #7 (**permalink**) 29/01/2009, 02:35

Cita:

Iniciado por MeduZaPaT

si comento esta funcion "dbus_g_proxy_call" bye bye problema y bye bye los datos que necesito, estuve pensando que capas esas llamadas se deben hacer solo una vez y con alguna otra funcion se actualiza el dato en la variable que referencie, sino para que cuernos usamos el g_type_init () o el main_loop de glib.

¿Todas las veces que la llamas aumenta en 4KB el consumo de memoria o el bucle completo consume 4KB? ¿Da error alguna de las llamadas? Una cosa que pude ver asi rapidamente es que deberias liberar el_error cuando se produce un error, ya que en ese caso no es mas un puntero nulo (a menos que lo hagas en error_happened pero entonces no tengo forma de saberlo).

Cita:

Iniciado por MeduZaPaT

Yo vine aca buscando ayuda, es la primera vez que uso dbus con glib, no digo que miren el codigo o lo compilen los que nunca lo usaron, pero capas alguien ya uso esas librerias y me dice - " no flaco asi no es" o " tenes que usarla de otra manera"

Esta bien pero lo mas probable es que nadie la haya usado jamas ...

Cita:

Iniciado por MeduZaPaT

Como sea si ejecuto 4 veces "dbus_g_proxy_call" se van 16Kb de ram.

¿En cada bucle o en cada llamada? Tenes que comprobar exactamente esto, si el problema es con cualquiera de las llamadas o con alguna/s en particular. Llamalo solo con lnombres a true (solo lcarga, etc).

PD. Asumo que tenes sobrecargado el operador = cuando asignas lo que inmediatamente vas a liberar a los campos de Bateria en lnombres o no son char * ...

MeduZaPaT · #8 (**permalink**) 29/01/2009, 12:20

Cita:

Iniciado por Eternal Idol

¿Todas las veces que la llamas aumenta en 4KB el consumo de memoria o el bucle completo consume 4KB? ¿Da error alguna de las llamadas? Una cosa que pude ver asi rapidamente es que deberias liberar el_error cuando se produce un error, ya que en ese caso no es mas un puntero nulo (a menos que lo hagas en error_happened pero entonces no tengo forma de saberlo).

En cada llamada. y si supuestamente la libero en error_happened, si no pongo el puntero en NULL salta una proteccion (quisas ahi este el error pero ni idea)

Cita:

Iniciado por Eternal Idol

Esta bien pero lo mas probable es que nadie la haya usado jamas ...

Todo Gnome, KDE y Xfce estan echos en eso y son proyectos gigantes, despues tenes mas chicos como, emesene, pidgin, o cualquier aplicacion GTK+, lo que cuentan miles de usuarios de esas librerias, es mas usado que el agua creo :S
Lo que veo que en este foro hay muchos nobatos en programacion ( o los que saben estan callados) y casi todos programan solo para windows.

Cita:

Iniciado por Eternal Idol

¿En cada bucle o en cada llamada? Tenes que comprobar exactamente esto, si el problema es con cualquiera de las llamadas o con alguna/s en particular. Llamalo solo con lnombres a true (solo lcarga, etc).

te respondi antes, en cada llamada a dbus_g_proxy_call (lo que son varias por bucle dependiendo de la Variable index en la funcion refresh

Cita:

Iniciado por Eternal Idol

PD. Asumo que tenes sobrecargado el operador = cuando asignas lo que inmediatamente vas a liberar a los campos de Bateria en lnombres o no son char * ...

son strings de C++ sobrecargan el operador =
lo que hago ahi es pasar el dato y liberar la memoria (o eso es lo que creo que hago)

De todas maneras gracias por las respuestas.

Eternal Idol · #9 (**permalink**) 29/01/2009, 14:30

Cita:

Iniciado por MeduZaPaT

En cada llamada. y si supuestamente la libero en error_happened, si no pongo el puntero en NULL salta una proteccion (quisas ahi este el error pero ni idea)

Bueno, depura la funcion con gdb (entra a la misma) y fijate donde se reserva esa memoria EXACTAMENTE. Agarra un tutorial o proyecto de ejemplo y comproba que no pase lo mismo y cual es la diferencia.

Cita:

Iniciado por MeduZaPaT

Todo Gnome, KDE y Xfce estan echos en eso y son proyectos gigantes, despues tenes mas chicos como, emesene, pidgin, o cualquier aplicacion GTK+, lo que cuentan miles de usuarios de esas librerias, es mas usado que el agua creo :S

Fijate entonces a ver cuantas personas de este foro trabajan en alguno de los proyectos que nombras ... puede que lo sea pero no veo muchos resultados (utiles) en Google para la funcion esta por ejemplo.

Cita:

Iniciado por MeduZaPaT

Lo que veo que en este foro hay muchos nobatos en programacion ( o los que saben estan callados) y casi todos programan solo para windows.

Hay de todo y si, por supuesto, Windows es obviamente el rey como en todos lados.

MeduZaPaT · #10 (**permalink**) 29/01/2009, 14:50

Cita:

Iniciado por Eternal Idol

Hay de todo y si, por supuesto, Windows es obviamente el rey como en todos lados.

es el rey sin corona, pero es la basura que todos usan, pero ese es otro tema en el que no quiero entrar.

Eternal Idol · #11 (**permalink**) 29/01/2009, 14:56

Cita:

Iniciado por MeduZaPaT

es el rey sin corona, pero es la basura que todos usan, pero ese es otro tema en el que no quiero entrar.

90% o mas del mercado lo dice todo, guste o no, es un hecho.

MeduZaPaT · #12 (**permalink**) 29/01/2009, 16:25

Cita:

Iniciado por Eternal Idol

90% o mas del mercado lo dice todo, guste o no, es un hecho.

bajo, menos del 80% y va a seguir bajando, para 2 años:

Predicting

So, let’s start a little guessing-game of how the operating system market share will look like in two years:

* Windows 75%
* Mac OS X 22%
* Linux 3%

para el 2015 esta pronosticado por IBM que el 60% del mercado va a ser linux.

recorda que el mac os es un unix
Volviendo al tema, leo leo y leo el manual de dbus y sigo sin saber si lo estoy usando bien o mal y el liqueo sigue ahi.

Eternal Idol · #13 (**permalink**) 29/01/2009, 16:35

No se de donde sacas esos datos pero no se parecen ni de lejos a los que se pueden ver por ejemplo en Wikipedia (4 fuentes entre 88% y 92% mas o menos) y sobre Mac OS X: "Although the second most popular operating system based on market share after Microsoft Windows, penetration is only 9.6% according to internet usage statistics compiled by Net Applications.[24] Furthermore, while the market share of Mac OS X growth is slower than Windows Vista, Mac OS X has been taking share from all Microsoft Windows OS versions combined...[25]."

En IBM tambien apostaron por OS/2 ... no es tan facil tener la bola de cristal.

Para el problema te digo lo mismo de antes:
Deja una sola llamada a dbus_g_proxy_call, depura la funcion con gdb (entra a la misma) y fijate donde se reserva esa memoria EXACTAMENTE. Agarra el tutorial que te deje antes (u otro) o un proyecto de ejemplo y comproba que no pase lo mismo y cual es la diferencia.

MeduZaPaT · #14 (**permalink**) 30/01/2009, 10:34

che eternal ¿vos y yo somos los unicos usuarios de este foro o me parece a mi?

Eternal Idol · #15 (**permalink**) 30/01/2009, 10:57

Cita:

Iniciado por MeduZaPaT

che eternal ¿vos y yo somos los unicos usuarios de este foro o me parece a mi?

No, hay mas, fijate que en otros hilos hay actividad, lo que pasa es que (al menos desde mi punto de vista) pedis algo muy especifico con lo que (probablemente) ninguno de nosotros trabajo nunca. Yo ataco el problema desde el costado de la depuracion donde tengo experiencia pero sino tampoco ...

MeduZaPaT · #16 (**permalink**) 30/01/2009, 12:05

Cita:

Iniciado por Eternal Idol

No, hay mas, fijate que en otros hilos hay actividad, lo que pasa es que (al menos desde mi punto de vista) pedis algo muy especifico con lo que (probablemente) ninguno de nosotros trabajo nunca. Yo ataco el problema desde el costado de la depuracion donde tengo experiencia pero sino tampoco ...

sos al unico al que le puedo dar las gracias por al menos tratar de ayudarme

postie en el foro de ubuntu y ahi en 1 hora ya metiraron ideas y todo, se ve que muchos usan glib