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