[petsc-users] Starting in debugger

[Sanjay Govindjee]

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 <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/0cd3e2c8/attachment.html>