From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!yy9MKEJN2ULhWGfnfq4v5w.user.gioia.aioe.org.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Alternative for Gnat Studio Date: Thu, 25 Feb 2021 18:10:05 +0000 Organization: Aioe.org NNTP Server Message-ID: References: <602e608e$0$27680$e4fe514c@news.kpn.nl> <60379b69$0$20345$e4fe514c@news.kpn.nl> NNTP-Posting-Host: yy9MKEJN2ULhWGfnfq4v5w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) X-Notice: Filtered by postfilter v. 0.9.2 Cancel-Lock: sha1:k2Csh9Dztmjbi7BoFGOcwYsrR/I= Xref: reader02.eternal-september.org comp.lang.ada:61446 List-Id: ldries46 writes: > My problem has become more acute. Till now I avoided the debugging > option in the GNAT 2020 Community edition by badding print statements > within the normal running program but now I have an error mentioned > somewhere within the Ada. Unbounded_Strings which is used on a lot of > positions in the program. The only way I know to detect wher the > problem is is using the debug option with several brakpoints and as > possible shifting these around to find this error but uding the debu > option just makes the program coming to the "program does not > react". If you can possibly bear it, you should try the command line. I don't know what that would look like on Windows (unless you're using Cygwin? which is Unix-y). Sample program: pragma Assertion_Policy (Check); procedure Raiser is procedure Inner (N : Natural) is pragma Assert (N > 5); begin Inner (N - 1); end Inner; begin Inner (10); end Raiser; Now, I'm sure you've built with a proper GPR, but to simplify the example: gnatmake -g -O raiser.adb Here, this produces the executable "raiser" in the current directory, but if your GPR specifies the Object_Dir and not the Exec_Dir the executable (in your case "raiser.exe") ends up in the Object_Dir, drat it. A very simple debugging session, assuming that the command "gdb" runs OK might look like: $ gdb raiser GNU gdb (GDB) 7.10 for GNAT Community 2020 [rev=52ea9f0a422c99f69e7e6c44a04e654ceebc42e3] Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. See your support agreement for details of warranty and support. If you do not have a current support agreement, then there is absolutely no warranty for this version of GDB. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin17.7.0". Type "show configuration" for configuration details.For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from raiser...done. Stop on any exception (gdb) catch exception Catchpoint 1: all Ada exceptions Run to the start of the program (gdb) start Temporary breakpoint 2 at 0x100001f54: file raiser.adb, line 9. Starting program: /Users/simon/tmp/raiser [New Thread 0x2303 of process 71543] Temporary breakpoint 2, raiser () at raiser.adb:9 9 Inner (10); Carry on (gdb) continue Continuing. Oops! (note, gdb knows to stop at the point in my code where the exception was raised, rather than down in the details of the runtime system calls) Catchpoint 1, SYSTEM.ASSERTIONS.ASSERT_FAILURE (raiser.adb:4) at 0x0000000100001f17 in raiser.inner (n=5) at raiser.adb:4 4 pragma Assert (N > 5); Print a backtrace of how we got here (gdb) backtrace #0 <__gnat_debug_raise_exception> ( e=0x1000142e0 , message=...) at s-excdeb.adb:43 #1 0x00000001000038ed in ada.exceptions.complete_occurrence (x=0x1004040c0) at a-except.adb:931 #2 0x00000001000038fd in ada.exceptions.complete_and_propagate_occurrence ( x=0x1004040c0) at a-except.adb:942 #3 0x0000000100003952 in <__gnat_raise_exception> ( e=0x1000142e0 , message=...) at a-except.adb:984 #4 0x0000000100004c13 in system.assertions.raise_assert_failure (msg=...) at s-assert.adb:46 #5 0x0000000100001f17 in raiser.inner (n=5) at raiser.adb:4 #6 0x0000000100001f3c in raiser.inner (n=6) at raiser.adb:6 #7 0x0000000100001f3c in raiser.inner (n=7) at raiser.adb:6 #8 0x0000000100001f3c in raiser.inner (n=8) at raiser.adb:6 #9 0x0000000100001f3c in raiser.inner (n=9) at raiser.adb:6 #10 0x0000000100001f3c in raiser.inner (n=10) at raiser.adb:6 #11 0x0000000100001f65 in raiser () at raiser.adb:9 Look at the code at frame 8 (#8 in the backtrace) (gdb) frame 8 #8 0x0000000100001f3c in raiser.inner (n=8) at raiser.adb:6 6 Inner (N - 1); Print a variable (gdb) print n $1 = 8 (gdb)