Ludovic Brenta wrote:
Valgrind flagged directory_tree.adb:1161 as deallocating memory that was already freed. Removing that one line didn't solve the problem, though; I had to change _all_ calls to VFS.Unchecked_Free into no-ops before the symptoms (crashes) disappeared. So, yes, we do need to investigate.
The crashes disappeared in 4.0.1-3 for me as well, so you're definitely on the right track here.
I'll play around with the source and see if I can get somewhere.
GNAT does provide a facility called "debug storage pools", but using that facility would be a major undertaking. We'd have to create one pool for each (non-derived) access type, and associate the access type with it. That would allow us to detect memory leaks (but so does valgrind). Unfortunately, it would most probably cause the memory corruption to not take place anymore, so we wouldn't be able to track it down.
Hmm...for this we might be able to limit ourselves to one type to start with, presumably whatever the root for File_Array_Access happens to be. I don't know what that type is offhand, and am not really sure where to look to find out (remember, I'm new to this). I expect the base type of that access type is defined in the GNAT libraries...
-- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
