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