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,e8ed21e11160bf2f X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!feeder1.cambrium.nl!feed.tweaknews.nl!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Abstract Interface - Assertion Error From: Georg Bauhaus In-Reply-To: <1192823107.966998.188490@i38g2000prf.googlegroups.com> References: <1192730634.890947.17190@e9g2000prf.googlegroups.com> <1192747730.7885.2.camel@K72> <1192791172.611781.102970@e9g2000prf.googlegroups.com> <1192791280.586457.18280@q3g2000prf.googlegroups.com> <4718ed6e$0$16103$9b4e6d93@newsspool1.arcor-online.net> <1192823107.966998.188490@i38g2000prf.googlegroups.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1193072522.1078.32.camel@kartoffel> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Date: Mon, 22 Oct 2007 19:02:02 +0200 Organization: Arcor NNTP-Posting-Date: 22 Oct 2007 19:01:34 CEST NNTP-Posting-Host: bbd071ec.newsspool4.arcor-online.net X-Trace: DXC=2BM\0m6A[h^f8j24CD<3lP4IUKR5<8 On Fri, 2007-10-19 at 12:45 -0700, Mike.McNett wrote: > When I build the project with Assertions enabled, I get an assertion > error. If I turn off the Assertions and rebuild all, I don't get the > assertion error and everything runs as expected. When I re-enable > Assertions and rebuild, the assertion error comes back. > > The assertion I get (shown in the debugger) is: > ... in system.assertions.raise_assert_failure (msg=(null)) at s- > assert.adb:44 > 44 s-assert.adb: No such file or directory. (Adding the GNAT source directory (gcc/..../adainclude/) to GDBs search path should make the location be known to it.) > in s-assert.adb > The next best thing to do that I can think of (other than asking the library producers if this is a bug) is to try tracing this. E.g., using a dummy program main_unit that will deliberately trigger an exception in library code, $ gnatmake -s -a -g -gnata main_unit.adb -bargs -E $ ./main_unit Execution terminated by unhandled exception Exception name: PROGRAM_ERROR Message: a-cohama.adb:198 explicit raise Call stack traceback locations: 0x805f4bc 0x805d03b 0x805df9a 0x805cfa4 0x80498ca 0xb7e25eba $ addr2line -e trigger_af 0x805f4bc 0x805d03b 0x805df9a \ 0x805cfa4 0x80498ca 0xb7e25eba