Codesigning is not the issue. My gdb is properly codesigned (here are
my synopsized instructions based off the page your reference but with
out the extraneous details
http://feap.berkeley.edu/wiki/index.php?title=GDB).
I think this is one of those nutty Apple quirks. I do notice that in
the debug windows that, if I use gdb I am just looking at hex codes for
the backtrace, whereas with lldb I can see they names of the routines.
Unfortunately, lldb does not play nice with Fortran so I need gdb.
Notwithstanding, I tried everything out a Fedora box and the debugging
worked just fine -- attached properly, symbols showing, variables are
accessible.
When I get a chance, I will try a from scratch build of gdb to see if
that helps.
Thanks again for the help.
-sanjay
On 4/17/22 8:12 AM, Barry Smith wrote:
Is the error of the form?
Attaching to program:
/Users/barrysmith/Src/petsc/src/snes/tutorials/ex19, process 79461
Unable to find Mach task port for process-id 79461: (os/kern) failure
(0x5).
(please check gdb is codesigned - see taskgated(8))
/Users/barrysmith/79461: No such file or directory.
These errors have nothing to do with PETSc. It is a security feature
of MacOS that makes it difficult to have random programs access other
running programs.
There are two ways around this.
1) codesign gdb. I found some instructions on how to give gdb the
correct permissions. https://sourceware.org/gdb/wiki/PermissionsDarwin
I have not followed them since they are rather convoluted; I am
puzzled why brew doesn't automatically sign the gdb it installed.
2) Skip the codesigning. Just do -start_in_debugger -with-debug="sudo
gdb" or run ./configure with --with-debugger="sudo gdb".
When I use GDB on Mac OS 12.3.1 I get the error message from gdb
warning: unhandled dyld version (17)
This is because the brew gdb release has not been fully updated for
the latest MacOS release.
But you might not have this version of MacOS. I suggest you just try
the -with-debug="sudo gdb" and see if it works for you before
switching over to Linux.
On Apr 17, 2022, at 1:10 AM, Sanjay Govindjee <[email protected]> wrote:
Thanks Barry.
mpirun -n 2 myapp -start_in_debugger now starts up two Terminal
windows with gdb.
I still face issues [2] and [3], but I think I am going to move over
to a linux box for a bit where I can control things better.
-sanjay
On 4/16/22 8:13 PM, Barry Smith wrote:
You should be able to use -start_in_debugger -debug_terminal xterm
When I added support for Apple Terminal it seems I hardwired it
only for lldb. I've attached a patch that will make it also work for
gdb so that just -start_in_debugger should open Terminal windows
with the gdb debugger for you.
Barry
On Apr 16, 2022, at 8:17 PM, Sanjay Govindjee <[email protected]> wrote:
I would like to start up some runs in the debugger and am running
into two primary issues.
(1) seem to not be able to control which debugger is used and
(2) there are errors in the start up, lastly
(3) if I do manage to start to job in the debugger (through manual
means), then running it is a bit of roulette as to if the job will
continue in the debugger.
I have petsc-3.17 built with GCC compilers and
--with-debugger=/usr/local/bin/gdb (using a patch Barry Smith
created today).
[1] When I execute "mpirun -n 2 hellow -debugger_terminal
Terminal" or "mpirun -n 2 hellow -start_in_debugger gdb
-debugger_terminal Terminal". I am getting lldb in the debugging
windows.
[2] The second problem I am seeing is that in the window where I
have run mpirun, the job exits with an mpirun message as shown.
$ mpirun -n 2 hellow -start_in_debugger gdb -debugger_terminal Terminal
--------------------------------------------------------------------------
mpirun has exited due to process rank 1 with PID 0 on
node Sanjays-MacBook-Pro2020 exiting improperly. There are three
reasons this could occur:
1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.
2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"
3. this process called "MPI_Abort" or "orte_abort" and the mca
parameter
orte_create_session_dirs is set to false. In this case, the
run-time cannot
detect that the abort call was an abnormal termination. Hence, the only
error message you will receive is this one.
This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
You can avoid this message by specifying -quiet on the mpirun
command line.
-------------------------------------------------------------------------
[3] If I just do something like "mpirun -n 5 xterm -e
/usr/local/bin/gdb hellow"; I get gdb running in xterm which is ok
to some extent, though I prefer Terminal. However, I do run into
the problem that the order in which I issue 'run' at the (gdb)
prompt dictates if the program will launch or not. Sometimes I
guess the order correctly and the job runs, other times it just hangs.
-sanjay
