Kevin Brown writes: > Why are we using any unchecked deallocations at all? That seems > counter to one of the biggest reasons to use Ada: correctness > checking. > > I'd rather take the potential heap usage hit and guarantee > correctness here. Is there any way we can turn this uncheck > deallocation to a checked deallocation?
"we" is actually the upstream author, AdaCore. The only "checked" deallocation that takes place in Ada is the one for objects on the stack. For heap-allocated objects, there are only two choices: - either you use an instance of Ada.Unchecked_Deallocation (which is still safer than C's free() because it guards against double deallocation and calls any finalization routines necessary) - or you declare an access type in a nested scope and specify a Storage_Size. When the access type goes out of scope, the storage is reclaimed. In the case of GPS, not many access types can be practically defined in a nested scope. Ada allows a garbage collector, but GNAT doesn't provide one out of the box (nor does any other Ada compiler). All allocations and deallocations are therefore explicit. > If it happens that the memory is never freed then it means that > something is referring to it when it shouldn't, and that would > obviously warrant investigation in its own right. In the absence of a garbage collector, the only reason why memory isn't freed is because my patch disabled the deallocation. However I'm quite convinced that there is a dangling pointer somewhere. Since I compile with full run-time checks, no overflow could have gone unnoticed. 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. BTW, two logs from valgrind are in gnat-gps_4.0.1-3.diff.gz; one taken before the memory_corruption.patch, and the other with the patch applied. In both cases, I started gnat-gps, selected the third option from the welcome box, and clicked Browse next to it. > I would hope that GNAT would provide the means to determine why the > allocator believes the memory chunk in question is still in use... 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. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
