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 | | a...@vnl.com "Data Systems for Deep Space and Time" | +---------------------------------------------------------------+ _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
