Kevin Brown wrote:
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...
I've been experimenting with this.
Sure enough, changing the storage pool for File_Array_Access causes the
bug to "disappear", and the storage pool doesn't catch any errors. This
suggests that the File_Array objects that we're managing are being
stepped on from outside or, more precisely, that they *would* be if they
weren't being managed by a different storage pool.
Interestingly enough, though, it causes a Program_Error to be generated
upon exit:
raised PROGRAM_ERROR : vfs.adb:1152 range check failed
That corresponds with procedure Finalize, and in particular, this line
of code:
Value.Ref_Count := Value.Ref_Count - 1;
For that to throw a range check error, it must be attempting to
decrement it past zero. So I modified that function to throw a
Storage_Error in the event that the reference count being passed in is
less than zero already (which would suggest that the block being
referred to got zapped by something else), and to decrement the count
only if it's greater than zero (and then free it if it really is zero).
My next experiment is to put both File_Array and Virtual_File into the
same storage pool and see what happens with that.
This raises a question, though: where in the *world* is Virtual_File
*actually defined*? In vfs.ads it's merely declared as "private", but
vfs.adb doesn't seem to define it at all! How can it possibly actually
be used within vfs.adb when it's not even defined??? It doesn't seem to
be defined in any of the source files for gnat-gps. Help! I'm really
confused here...
--
Kevin Brown [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
