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 >
