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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,836e7962fed7281b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-22 14:17:11 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!wn53feed!worldnet.att.net!attbi_s54.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: debugging tool? References: <_69_b.69554$KV5.45492@nwrdny01.gnilink.net> X-Newsreader: Tom's custom newsreader Message-ID: NNTP-Posting-Host: 67.161.24.134 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s54 1077488231 67.161.24.134 (Sun, 22 Feb 2004 22:17:11 GMT) NNTP-Posting-Date: Sun, 22 Feb 2004 22:17:11 GMT Organization: Comcast Online Date: Sun, 22 Feb 2004 22:17:11 GMT Xref: archiver1.google.com comp.lang.ada:5738 Date: 2004-02-22T22:17:11+00:00 List-Id: > > Is there a tool around that would scan a large program to check for > > instances of an object being accessed *after* it's been Finalized? > > Remember that Ada permits itself to finalize an object more than once. I don't mean multiple Finalize calls - that's easy. I mean accessing an object *after* it's been finalized. For instance: Main_Object : Main_Object_Type; -- Controlled type Helper_Object : Helper_Object_Type; -- also Controlled procedure Finalize(X : in out Helper_Object_Type) is ... procedure Finalize(X : in out Main_Object_Type) is begin do something that accesses Helper_Object other stuff end Finalize; At program termination things are Finalized in the reverse order of their creation. So Helper_Object gets Finalized. Then Main_Object is Finalized - but that process includes accessing Helper_Object, which has already been finalized. Perhaps it contained pointers that were deallocated so the attempt to use it *after finalization* crashes. If Helper_Object is declared *before* Main_Object, all is well. I recently ran into something like this where Helper involved a protected object and an attempt to call the protected object after it had been finalized was not good. It seems to me a fairly easy mistake to declare the helper after the main object, and it seems like a fairly simple minded source code analysis tool could detect the problem.