[petsc-users] Starting in debugger

[Barry Smith]

  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 <s_g at berkeley.edu> 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 <s_g at berkeley.edu> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220417/11856445/attachment-0001.html>