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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.36.177.69 with SMTP id c5mr5101089itj.36.1519510056139; Sat, 24 Feb 2018 14:07:36 -0800 (PST) X-Received: by 10.157.68.105 with SMTP id f38mr259112otj.1.1519510055994; Sat, 24 Feb 2018 14:07:35 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!o66no1295403ita.0!news-out.google.com!s63ni4150itb.0!nntp.google.com!o66no1295398ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 24 Feb 2018 14:07:35 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.171.117.31; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 71.171.117.31 References: <906cd418-adff-4eeb-9da5-7c6f7c777ff8@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM From: Jere Injection-Date: Sat, 24 Feb 2018 22:07:36 +0000 Content-Type: text/plain; charset="UTF-8" X-Received-Body-CRC: 2478577915 X-Received-Bytes: 3725 Xref: reader02.eternal-september.org comp.lang.ada:50624 Date: 2018-02-24T14:07:35-08:00 List-Id: On Friday, February 23, 2018 at 4:17:02 AM UTC-5, Simon Wright wrote: > I don't know if it helps, but running under the debugger (GCC 8.0.1, > macOS) show the first exception is > > Catchpoint 1, PROGRAM_ERROR (Main.Composite.Vectors.Implementation.TC_Check: attempt to tamper with cursors) at __gnat_debug_raise_exception ( > e=0x10003eaa0 , message=...) at s-excdeb.adb:40 > 40 s-excdeb.adb: No such file or directory. > (gdb) bt > #0 __gnat_debug_raise_exception (e=0x10003eaa0 , message=...) > at s-excdeb.adb:40 > #1 0x0000000100011cdd in ada__exceptions__complete_occurrence (x=0x1003020f0) > at a-except.adb:931 > #2 0x0000000100011ced in ada__exceptions__complete_and_propagate_occurrence ( > x=0x1003020f0) at a-except.adb:942 > #3 0x0000000100011d42 in __gnat_raise_exception ( > e=0x10003eaa0 , message=...) at a-except.adb:984 > #4 0x0000000100006f27 in main.composite.vectors.implementation.tc_check () > #5 0x0000000100008e11 in main.composite.vectors.finalize () > #6 0x000000010000fe19 in main__composite__instanceDF.7589 () > #7 0x0000000100010250 in main___finalizer.4676 () > #8 0x0000000100006c20 in main () Thanks! That confirms my initial suspicion of it being related to tamper checks, but I can't figure out how. I looked through the GNAT code and saw how they locked it in the Constant_Reference function, but I can't for the life of me figure out how calling it using: Package.Operation(Object,Params).Discriminant would work differently than Object.Operation(Params).Discriminant for that function call. I would have assumed that both styles would produce the same code. And even so, I wasn't able to figure out why the busy lock for the tamper check wasn't released in the case that generates the exception. Is it safe to say I am not doing something illegal at least? I'm copying one anonymous access type into another (in order to propagate the inner objects reference to the external object for iteration). I feel like I remember someone saying you shouldn't be able to copy anonymous access types, but perhaps in this case it is ok? I'm gonna submit this to GNAT (I think) because I feel either way it is a bug. Either I am doing something legal that results in bad code or I am doing something illegal and it isn't being caught by the compiler or runtime at the right spot (I think).