[petsc-users] Starting in debugger

[Matthew Knepley]

On Sun, Apr 17, 2022 at 2:59 PM Sanjay Govindjee <s_g at berkeley.edu> wrote:

> 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.
>

I think I understand what is happening. I also tried to get gdb working on
Catalina. I built gcc _and_ gdb from scratch.
It did not work. So I used lldb to trace through the gdb source when it was
starting up. It turns out that the ELF format
is extendible, and Apple added its own undocumented extensions to symbols.
It is some kind of data structure hanging
off that only Apple knows the format for. It is the kind of asinine
corporate crap that I thought only Microsoft did, but Apple
has no problem with it here. At this point I gave up.

  Thanks,

     Matt


> 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
>
>
>
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220417/5b419b4b/attachment-0001.html>