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-Thread: 103376,c4cb2c432feebd9d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!h48g2000cwc.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: Finalization Date: 21 Nov 2006 09:22:03 -0800 Organization: http://groups.google.com Message-ID: <1164129723.785937.76470@h48g2000cwc.googlegroups.com> References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <2006052509454116807-gsande@worldnetattnet> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1164129729 26469 127.0.0.1 (21 Nov 2006 17:22:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 21 Nov 2006 17:22:09 +0000 (UTC) User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: h48g2000cwc.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news2.google.com comp.lang.ada:7613 Date: 2006-11-21T09:22:03-08:00 List-Id: Philippe Tarroux wrote: > >This is broken. You allocate a new vector in Process, then a shallow copy > >of is made in "return 0." Then O is destructed and as a result Finalize > >kills that vector. The caller receives the shallow copy object with a > >dangling pointer in the filed X. > > > > > But I don't undestand why it works for the first 7 iteration of the loop > and crashes only at the 8th. Because that's what dangling pointer bugs do. You've deallocated some data, but somewhere else in your program you still have a pointer to the data. This pointer is now invalid. However, from a machine-instruction standpoint, most of the data still exists at the address, so if you try to access the data at that address, it will still be successful until something else happens to cause the program to allocate new data at the same address. Now, if you use your invalid pointer, you'll get the wrong data, which could cause your program to crash, or could just cause incorrect data to be read that causes erroneous results that you can't figure out. Or worse, you could use your invalid pointer to *write* data into memory... I once had a problem (when using C, but Ada isn't too much better at preventing this) where I used a dangling pointer to write data, and it ended up writing over data that belonged to the memory allocator, and---much worse---it overwrote an address with another legitimate address, which meant that the memory allocator didn't crash right away but instead eventually caused things to go haywire several dozen allocations later. Bugs like this can take days to track down. So the bottom line is, dangling pointer bugs are VERY NASTY, and if there's one in your code (as there is in your example), fix it. Don't worry about why it isn't causing a crash or why it's taking a while to cause one. Just do it. Even if your program seems to be working. Anyway, the "classic" simple way to deal with this sort of problem is to override the Adjust routine: procedure Adjust (O : in out Obj) is begin if O.X /= null then O.X := new Vector' (O.X.all); end if; end Adjust; This is the simplest approach, but it may or may not be wasteful in the context of your application; reference counters are another way, and there are doubtless other ways to skin the cat. But you definitely need to do something to eliminate the dangling pointer problem. -- Adam