[petsc-users] Starting in debugger

Sanjay Govindjee s_g at berkeley.edu
Sun Apr 17 23:02:57 CDT 2022

Frustrating.  But thanks for trying for me.
Oddly while gdb does not fully work on my Mac, I have had reasonable 
success with it on serial runs -- symbols etc. available.  But I agree, 
it is disappointing to see Apple go down this road.  I guess that's 
another reason to return to using a Linux laptop again.


On 4/17/22 7:01 PM, Matthew Knepley wrote:
> On Sun, Apr 17, 2022 at 9:48 PM Barry Smith <bsmith at petsc.dev> wrote:
>       Why does brew support "brew install gdb" then? If it won't work
>     why don't they print a very helpful message instead of installing
>     something that does not work?
> It will build and look somewhat like it is functioning. I think no one 
> bothered to really check it out.
>    Matt
>       For example
>     $ brew install valgrind
>     valgrind: Linux is required for this software.
>     Error:valgrind: An unsatisfied requirement failed this build.
>>     On Apr 17, 2022, at 9:25 PM, Matthew Knepley <knepley at gmail.com>
>>     wrote:
>>     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/>
> -- 
> 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/24d503cc/attachment-0001.html>

More information about the petsc-users mailing list