[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep and valgrind

From: amon
Subject: Re: GNUstep and valgrind
Date: Tue, 20 Mar 2018 19:09:14 -0500
User-agent: Roundcube Webmail/1.3.4

Much useful progress today. Some notes for anyone who might be

GSDebugAllocationList() is a very useful tool but has a
surprising (at first) undocumented side affect. I can almost
guarantee you that every initial user is going to go searching
for the reason why there are so many lost NSDataMalloc objects
happening in their code... ie, that function appears to drop
one into the pool every time it is called. This is sort of like
having a Geiger Counter that inserts extra counts but doesn't
document the expected number of them.

Using it gave me a good handle on what happens at init time. I
did not find very many actual leaks in the classes under test.
Only 2-3 of them. I was fairly careful when I wrote it in the
first place.

I found no apparent difference in the use of -release vs -drain
in my applications, which seemed to be what some folks were

I was surprised to find that pools do not seem to go away. Even
with releases, I end up the run with a bunch of extra pool

I have a handle on a baseline changeset I will need to roll
through the code. It's larger than I had hoped and it represents
a lot of work and a huge amount of post-change regression
testing, but I can not see any other way around it than to
add pools to every method of every object that touches the
GNUstep library.

Tomorrow. I'm heading out for dinner.

|   Dale Amon                  Immortal Data                    |
|   CEO             Midland International Air and Space Port    |
| address@hidden       "Data Systems for Deep Space and Time"     |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]