X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-CMAE-Analysis:	v=2.4 cv=YI9adTKx c=1 sm=1 tr=0 ts=5fd5aaea
	a=+cj0cO56Fp8x7EdhTra87A==:117 a=Qmk11tQvjyudDBtWpjW/nA==:17
	a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=IkcTkHD0fZMA:10 a=zTNgK-yGK50A:10
	a=a1KZgU7cAAAA:8 a=Mj1Xp5F7AAAA:8 a=uP_uP1WwUrQVj0PAsm4A:9 a=QEXdDO2ut3YA:10
	a=ng0hpkU2jXKPaRTLMVYJ:22 a=OCttjWrK5_uSHO_3Hkg-:22
X-SECURESERVER-ACCT:	glimrick AT epilitimus DOT com
Subject:	Re: [geda-user] Memory leak patches
To:	geda-user AT delorie DOT com
References:	<e4ff3c96-939b-a93e-a32f-5e938b6daa63 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2011302045040 DOT 2894 AT nimbus>
	<20201130220505 DOT 0AE4282C54FD AT turkos DOT aspodata DOT se>
	<7c75ed03-456c-b408-8b50-0448f6b3a04f AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012011606400 DOT 6785 AT nimbus>
	<1b2c64b3-6a36-c1f3-dd54-bb583c6bea17 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012021253440 DOT 1262 AT nimbus>
	<475f980e-fddd-60d1-9a02-a5bc5fb5805b AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012071333290 DOT 3907 AT nimbus>
	<e6c5135f-b127-fd55-91b2-79aa357a5a07 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012081644480 DOT 3649 AT nimbus>
	<8706c896-e01a-9e6e-2bab-fe3607064093 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012111645180 DOT 13096 AT nimbus>
	<63273f86-b0fd-8835-a13e-6ab408f06dfc AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012121301180 DOT 1221 AT nimbus>
From:	"Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<4a1fbfca-3921-f674-1499-f11df8d5a58e@epilitimus.com>
Date:	Sat, 12 Dec 2020 21:47:15 -0800
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Firefox/60.0 SeaMonkey/2.53.3
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.21.2012121301180.1221@nimbus>
X-AntiAbuse:	This header was added to track abuse, please include it with any abuse report
X-AntiAbuse:	Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net
X-AntiAbuse:	Original Domain - delorie.com
X-AntiAbuse:	Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse:	Sender Address Domain - epilitimus.com
X-Get-Message-Sender-Via:	a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com
X-Authenticated-Sender:	a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com
X-Source:
X-Source-Args:
X-Source-Dir:
X-CMAE-Envelope:	MS4xfFLHLVS48+F/Mu837hSOMCNFJrxIZMLFPgjwp7MkOcnwRBRilqubpCAYS4P3/A40//RkK9DWcdK0BQxWk6dEBJoq6V6WgFpzLhmXTnpnRXHUCurg7OjM
	z8oJ6UgQIYDHzb2TRvPP5bcpzNxssOhVryb9J92xv+nUcaMhCRGFH8tOOW/7udjQaX6Rnaw/STxddaBvrh5LzbXmSDCt8YGWTJYhLx/AFSRXwYHe16DU4rHz
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Roland Lutz wrote:
> On Fri, 11 Dec 2020, Glenn (glimrick AT epilitimus DOT com) [via
> geda-user AT delorie DOT com] wrote:
>> I looked at this again. While I am sure you are correct about
>> g_object_data valgrind lists the string as definitely lost so you
>> need to find another place to free it once you are done with it.
>
> Yes, the string is lost; it is allocated and its pointer stored in the
> general-purpose "data" field of the widget.  The proper way to free it
> would be to use g_object_set_data_full with a GDestroyNotify callback
> (probably just g_free).
>
>
I just pushed the final set of commits to this branch on
http://epilitimus.com/git_repos/geda-gaf.git

After my initial commit (the one you have already seen) there is a
second batch I had done before I had your fixes to my first batch. Then
your fixes, a formatting fix, a third set of memory leak fixes and a set
of build time warning fixes. One of the fixes in the third set is the
above re-fix using  g_object_set_data_full, you can re-un-fix it if it
still doesn't pass muster. I have compiled all of these but have not
executed them, so look them over carefully. And yes there may well be
formatting errors, though I did fix those (I think) from the second batch.

There are also still a bunch of leaks, all in the gui code. I was having
a tough time figuring these out so I finally gave up. I can see where
the allocation happens but not where the free needs to go. It is
possible they are the result of library errors to the extent that parent
objects are supposed to be freeing children, etc. I can send you the
valgrind output if you are feeling really motivated. To the extent the
object lives until program termination the leaks are moot.

I'm almost cross-eyed so that's it for me for today.

Glenn

- Raw text -