<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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 class="moz-txt-link-freetext" href="http://feap.berkeley.edu/wiki/index.php?title=GDB">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>
<br>
Thanks again for the help.<br>
-sanjay<br>
<pre class="moz-signature" cols="72">
</pre>
<div class="moz-cite-prefix">On 4/17/22 8:12 AM, Barry Smith wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CC4CD2ED-1BAA-4AF3-92F5-6D47031B003F@petsc.dev">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class=""><br class="">
</div>
<div class=""> Is the error of the form? </div>
<div class=""><br class="">
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">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;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class=""><font
class="" 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;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class=""><font
class="" 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;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">/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;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class=""><br
class="">
</span></div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class=""><br
class="">
</span></div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class=""> 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;" class=""><br class="">
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class="">There are two
ways around this.</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class=""><br class="">
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class="">1) codesign
gdb. I found some instructions on how to give gdb the correct
permissions. <a
href="https://sourceware.org/gdb/wiki/PermissionsDarwin"
class="moz-txt-link-freetext" moz-do-not-send="true">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;" class=""><br class="">
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class="">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;" class=""><br class="">
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class="">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;" class=""><br class="">
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 14px;
line-height: normal; font-family: Menlo;" class="">
<div style="margin: 0px; font-stretch: normal; line-height:
normal;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">warning: unhandled dyld
version (17)</span></div>
<div style="margin: 0px; font-stretch: normal; line-height:
normal;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
<div style="margin: 0px; font-stretch: normal; line-height:
normal;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">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;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
<div style="margin: 0px; font-stretch: normal; line-height:
normal;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class="">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;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
<div style="margin: 0px; font-stretch: normal; line-height:
normal;" class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Apr 17, 2022, at 1:10 AM, Sanjay Govindjee
<<a href="mailto:s_g@berkeley.edu"
class="moz-txt-link-freetext" moz-do-not-send="true">s_g@berkeley.edu</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Thanks Barry.<br class="">
<br class="">
mpirun -n 2 myapp -start_in_debugger now starts up two
Terminal windows with gdb.<br class="">
<br class="">
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 class="">
<br class="">
-sanjay<br class="">
<br class="">
On 4/16/22 8:13 PM, Barry Smith wrote:<br class="">
<blockquote type="cite" class=""> You should be able to
use -start_in_debugger -debug_terminal xterm<br class="">
<br class="">
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 class="">
<br class="">
Barry<br class="">
<br class="">
<blockquote type="cite" class="">On Apr 16, 2022, at
8:17 PM, Sanjay Govindjee <<a
href="mailto:s_g@berkeley.edu"
class="moz-txt-link-freetext" moz-do-not-send="true">s_g@berkeley.edu</a>>
wrote:<br class="">
<br class="">
I would like to start up some runs in the debugger and
am running into two primary issues.<br class="">
<br class="">
(1) seem to not be able to control which debugger is
used and<br class="">
(2) there are errors in the start up, lastly<br
class="">
(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 class="">
<br class="">
I have petsc-3.17 built with GCC compilers and
--with-debugger=/usr/local/bin/gdb (using a patch
Barry Smith created today).<br class="">
<br class="">
[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 class="">
<br class="">
[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 class="">
<br class="">
$ mpirun -n 2 hellow -start_in_debugger gdb
-debugger_terminal Terminal<br class="">
--------------------------------------------------------------------------<br
class="">
mpirun has exited due to process rank 1 with PID 0 on<br
class="">
node Sanjays-MacBook-Pro2020 exiting improperly. There
are three reasons this could occur:<br class="">
<br class="">
1. this process did not call "init" before exiting,
but others in<br class="">
the job did. This can cause a job to hang indefinitely
while it waits<br class="">
for all processes to call "init". By rule, if one
process calls "init",<br class="">
then ALL processes must call "init" prior to
termination.<br class="">
<br class="">
2. this process called "init", but exited without
calling "finalize".<br class="">
By rule, all processes that call "init" MUST call
"finalize" prior to<br class="">
exiting or it will be considered an "abnormal
termination"<br class="">
<br class="">
3. this process called "MPI_Abort" or "orte_abort" and
the mca parameter<br class="">
orte_create_session_dirs is set to false. In this
case, the run-time cannot<br class="">
detect that the abort call was an abnormal
termination. Hence, the only<br class="">
error message you will receive is this one.<br
class="">
<br class="">
This may have caused other processes in the
application to be<br class="">
terminated by signals sent by mpirun (as reported
here).<br class="">
<br class="">
You can avoid this message by specifying -quiet on the
mpirun command line.<br class="">
-------------------------------------------------------------------------<br
class="">
<br class="">
[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 class="">
<br class="">
-sanjay<br class="">
</blockquote>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
</body>
</html>