Ludovic Brenta wrote: > Running gnat-gps under valgrind revealed many, many errors. One > seemed related to #400876 and #400883, which I was investigating at > the time; it looked like a double deallocation problem: > > ==25342== Address 0x9F3D820 is 48 bytes inside a block of size 840 free'd > ==25342== at 0x4A1B46D: free (vg_replace_malloc.c:233) > ==25342== by 0x435A39: __gnat_free (s-memory.adb:82) > ==25342== by 0x70929A: vfs__unchecked_free (vfs.adb:458) > ==25342== by 0x6F4A7C: directory_tree__read_directory > (directory_tree.adb:1161) > ==25342== by 0x6F3A13: directory_tree__read_directory > (directory_tree.adb:1115) > ==25342== by 0x6F7869: directory_tree__file_append_directory > (directory_tree.adb:1309) > ==25342== by 0x6FD1F2: directory_tree__refresh (directory_tree.adb:1713) > ==25342== by 0x6F8F61: directory_tree__initialize (directory_tree.adb:1434) > ==25342== by 0x6F81AF: directory_tree__gtk_new (directory_tree.adb:1368) > > Removing just the call to VFS.Unchecked_Free which triggers the error > solves only part of the problem, as GPS hangs when I click on OK or > Close in the file selector. > > Turning VFS.Unchecked_Free into a no-op introduces memory leaks, but > makes the problems described in both bugs disappear. That's what the > patch below does. > > Kevin, could you please try it and report back? I don't think this > patch solves the problem, it just prevents it from being triggered.
I'll be happy to. But I have a question: 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? 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. I would hope that GNAT would provide the means to determine why the allocator believes the memory chunk in question is still in use... -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
