[petsc-users] Starting in debugger

Barry Smith bsmith at petsc.dev
Sun Apr 17 20:47:45 CDT 2022 

  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?

  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 <mailto: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 detailshttp://feap.berkeley.edu/wiki/index.php?title=GDB <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 <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 <mailto: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 <mailto: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/5902a95c/attachment.html>

More information about the petsc-users mailing list