Re: GNUstep and valgrind

[amon]

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

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
saying.

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
objects.

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    |
| amon@vnl.com       "Data Systems for Deep Space and Time"     |
+---------------------------------------------------------------+