<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div> 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?<br class=""><div><br class=""></div><div> For example</div><div><br class=""></div><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="">$ brew install valgrind</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="">valgrind: Linux is required for this software.</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; color: #b42419" class="">Error:</span><span style="font-variant-ligatures: no-common-ligatures" class=""> valgrind: An unsatisfied requirement failed this build.</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><blockquote type="cite" class=""><div class="">On Apr 17, 2022, at 9:25 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" class="">knepley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">On Sun, Apr 17, 2022 at 2:59 PM Sanjay Govindjee <<a href="mailto:s_g@berkeley.edu" class="">s_g@berkeley.edu</a>> wrote:<br class=""></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 class="">
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" class="">http://feap.berkeley.edu/wiki/index.php?title=GDB</a>).<br class="">
<br class="">
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 class="">
<br class="">
Notwithstanding, I tried everything out a Fedora box and the
debugging worked just fine -- attached properly, symbols showing,
variables are accessible.<br class="">
<br class="">
When I get a chance, I will try a from scratch build of gdb to see
if that helps.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">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 class="">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 class="">is extendible, and Apple added its own undocumented extensions to symbols. It is some kind of data structure hanging</div><div class="">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 class="">has no problem with it here. At this point I gave up.</div><div class=""><br class=""></div><div class=""> Thanks,</div><div class=""><br class=""></div><div class=""> Matt</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
Thanks again for the help.<br class="">
-sanjay<br class="">
<pre cols="72" class=""></pre>
<div class="">On 4/17/22 8:12 AM, Barry Smith wrote:<br class="">
</div>
<blockquote type="cite" class="">
<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 color="#b51a00" class="">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 color="#b51a00" class=""> (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" target="_blank" class="">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 class=""><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" target="_blank" class="">s_g@berkeley.edu</a>>
wrote:</div>
<br class="">
<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" target="_blank" class="">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 class="">
</div>
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br class="">-- Norbert Wiener</div><div class=""><br class=""></div><div class=""><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank" class="">https://www.cse.buffalo.edu/~knepley/</a><br class=""></div></div></div></div></div></div></div></div>
</div></blockquote></div><br class=""></body></html>