<div dir="ltr"><div dir="ltr">On Sun, Apr 17, 2022 at 2:59 PM Sanjay Govindjee <<a href="mailto:s_g@berkeley.edu">s_g@berkeley.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    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
    <a href="http://feap.berkeley.edu/wiki/index.php?title=GDB" target="_blank">http://feap.berkeley.edu/wiki/index.php?title=GDB</a>).<br>
    <br>
    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.<br>
    <br>
    Notwithstanding, I tried everything out a Fedora box and the
    debugging worked just fine -- attached properly, symbols showing,
    variables are accessible.<br>
    <br>
    When I get a chance, I will try a from scratch build of gdb to see
    if that helps.<br></div></blockquote><div><br></div><div>I think I understand what is happening. I also tried to get gdb working on Catalina. I built gcc _and_ gdb from scratch.</div><div>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</div><div>is extendible, and Apple added its own undocumented extensions to symbols. It is some kind of data structure hanging</div><div>off that only Apple knows the format for. It is the kind of asinine corporate crap that I thought only Microsoft did, but Apple</div><div>has no problem with it here. At this point I gave up.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    Thanks again for the help.<br>
    -sanjay<br>
    <pre cols="72"></pre>
    <div>On 4/17/22 8:12 AM, Barry Smith wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div><br>
      </div>
      <div>  Is the error of the form? </div>
      <div><br>
      </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">Attaching
          to program:
          /Users/barrysmith/Src/petsc/src/snes/tutorials/ex19, process
          79461</span></div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><font color="#b51a00">Unable to find Mach task port for
            process-id 79461: (os/kern) failure (0x5).</font></span></div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><font color="#b51a00"> (please check gdb is codesigned -
            see taskgated(8))</font></span></div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">/Users/barrysmith/79461:
          No such file or directory.</span></div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br>
        </span></div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br>
        </span></div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"> 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. </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><br>
      </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo">There are two
        ways around this.</div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><br>
      </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo">1) codesign
        gdb. I found some instructions on how to give gdb the correct
        permissions. <a href="https://sourceware.org/gdb/wiki/PermissionsDarwin" target="_blank">https://sourceware.org/gdb/wiki/PermissionsDarwin</a>
        I have not followed them since they are rather convoluted; I am
        puzzled why brew doesn't automatically sign the gdb it
        installed. </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><br>
      </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo">2) Skip the
        codesigning. Just do -start_in_debugger -with-debug="sudo gdb"
        or run ./configure with --with-debugger="sudo gdb". </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><br>
      </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo">When I use
        GDB on Mac OS 12.3.1 I get the error message from gdb</div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><br>
      </div>
      <div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo">
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures">warning: unhandled dyld
            version (17)</span></div>
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures"><br>
          </span></div>
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures">This is because the brew gdb
            release has not been fully updated for the latest MacOS
            release.</span></div>
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures"><br>
          </span></div>
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures">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.</span></div>
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures"><br>
          </span></div>
        <div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures"><br>
          </span></div>
      </div>
      <div><br>
        <blockquote type="cite">
          <div>On Apr 17, 2022, at 1:10 AM, Sanjay Govindjee
            <<a href="mailto:s_g@berkeley.edu" target="_blank">s_g@berkeley.edu</a>>
            wrote:</div>
          <br>
          <div>
            <div>Thanks Barry.<br>
              <br>
              mpirun -n 2 myapp -start_in_debugger now starts up two
              Terminal windows with gdb.<br>
              <br>
              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.<br>
              <br>
              -sanjay<br>
              <br>
              On 4/16/22 8:13 PM, Barry Smith wrote:<br>
              <blockquote type="cite">    You should be able to
                use -start_in_debugger -debug_terminal xterm<br>
                <br>
                   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.<br>
                <br>
                  Barry<br>
                <br>
                <blockquote type="cite">On Apr 16, 2022, at
                  8:17 PM, Sanjay Govindjee <<a href="mailto:s_g@berkeley.edu" target="_blank">s_g@berkeley.edu</a>>
                  wrote:<br>
                  <br>
                  I would like to start up some runs in the debugger and
                  am running into two primary issues.<br>
                  <br>
                  (1) seem to not be able to control which debugger is
                  used and<br>
                  (2) there are errors in the start up, lastly<br>
                  (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.<br>
                  <br>
                  I have petsc-3.17 built with GCC compilers and
                  --with-debugger=/usr/local/bin/gdb (using a patch
                  Barry Smith created today).<br>
                  <br>
                  [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.<br>
                  <br>
                  [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.<br>
                  <br>
                  $ mpirun -n 2 hellow -start_in_debugger gdb
                  -debugger_terminal Terminal<br>
--------------------------------------------------------------------------<br>
                  mpirun has exited due to process rank 1 with PID 0 on<br>
                  node Sanjays-MacBook-Pro2020 exiting improperly. There
                  are three reasons this could occur:<br>
                  <br>
                  1. this process did not call "init" before exiting,
                  but others in<br>
                  the job did. This can cause a job to hang indefinitely
                  while it waits<br>
                  for all processes to call "init". By rule, if one
                  process calls "init",<br>
                  then ALL processes must call "init" prior to
                  termination.<br>
                  <br>
                  2. this process called "init", but exited without
                  calling "finalize".<br>
                  By rule, all processes that call "init" MUST call
                  "finalize" prior to<br>
                  exiting or it will be considered an "abnormal
                  termination"<br>
                  <br>
                  3. this process called "MPI_Abort" or "orte_abort" and
                  the mca parameter<br>
                  orte_create_session_dirs is set to false. In this
                  case, the run-time cannot<br>
                  detect that the abort call was an abnormal
                  termination. Hence, the only<br>
                  error message you will receive is this one.<br>
                  <br>
                  This may have caused other processes in the
                  application to be<br>
                  terminated by signals sent by mpirun (as reported
                  here).<br>
                  <br>
                  You can avoid this message by specifying -quiet on the
                  mpirun command line.<br>
-------------------------------------------------------------------------<br>
                  <br>
                  [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.<br>
                  <br>
                  -sanjay<br>
                </blockquote>
              </blockquote>
              <br>
            </div>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>