[petsc-users] Starting in debugger

Sun Apr 17 21:01:13 CDT 2022

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/aef739e7/attachment-0001.html>