From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6f248223d81c2ffc X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Finalization and Garbage Collection: a hole in the RM? Date: 1996/08/30 Message-ID: #1/1 X-Deja-AN: 177477893 references: organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-08-30T00:00:00+00:00 List-Id: In article , Franco Mazzanti wrote: >Are there any other holes like this one are hiding there? > >I am trying to write a roadmap to erroneous executions and other >unpredictabilities in Ada95, so for me it would be important to find all >the possible issues of this kind. Are you interested in erroneous/unpredictable stuff in general, or are you interested specifically in issues related to garbage collection? The index of the RM and AARM contains entries for "erroneous" and "bounded error" that will let you track down all the cases. Another source of unpredictability is when the run-time semantics says "arbitrary order". I don't think that's in the index, but you could use an editor to search the ascii version of the RM. As for garbage collection, I don't know of any other major pitfalls (other than interactions with finalization, I mean), and I already posted the small amount of discussion in the AARM. Another issue is that you can point into the middle of objects (via renamings, and via 'Access on components). So the last remaining pointer to an object might actually point into the middle of it, or to a slice of it. You can point to non-existent stuff -- e.g. use 'Unchecked_Access to create a pointer to a local variable, then return from the subprogram, leaving the pointer pointing past the stack top. This is not an error (assuming the pointer is never referenced later), but the pointer is still there for the gc to trip over. A still-running task is not garbage, even if there are no pointers to it, since it can reach out and do things. Interactions between tasking and gc in general (e.g. you can't just run the garbage collector when the user program is doing a "new", because some other task might be doing something else). Etc. But these all seem like solvable problems. - Bob