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 <[email protected]> wrote: > > On Sun, Apr 17, 2022 at 2:59 PM Sanjay Govindjee <[email protected] > <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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/>
