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,a0e076952eca80d4 X-Google-Attributes: gid103376,public From: richard@curnow.demon.co.uk (Richard Curnow) Subject: Re: Ada and C++ asserts. Date: 1996/07/22 Message-ID: #1/1 X-Deja-AN: 170505991 x-nntp-posting-host: curnow.demon.co.uk references: organization: Myself newsgroups: comp.lang.ada Date: 1996-07-22T00:00:00+00:00 List-Id: In article <31EE4C88.1AAD@ubs.com> Ian Johnston writes: Ian> On any UNIX, you can look at the core dump with a debugger Ian> and get a stack trace showing not only where the core dump Ian> happened, but the chain of function calls leading up to it, Ian> along with parameter and variable values. Even on VMS, you Ian> get a stack trace showing how you arrived at the assert. Ian> What information does Ada supply about the circumstances Ian> leading to the failed assertion? With GNAT, the normal behaviour is to stop execution of the program with a "raised SYSTEM.ASSERTIONS.ASSERT_FAILURE" message. However, during development, the program can be compiled with "-g" and then run under a breakpoint debugger such as gdb. If a breakpoint is set on "system__assertions__raise_assert_failure" a stack trace can be produced whenever an exception is raised due to an assertion being failed. A little unwieldy compared to a post-mortem gdb session on a C or C++ -generated core file, but effective nevertheless. Cheers Richard -- Richard P. Curnow Stevenage, England