<div dir="ltr"><div dir="ltr">On Sun, Apr 17, 2022 at 9:48 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</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 style="overflow-wrap: break-word;"><div><br></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?</div></blockquote><div><br></div><div>It will build and look somewhat like it is functioning. I think no one bothered to really check it out.</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 style="overflow-wrap: break-word;"><div> For example</div><div><br></div><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">$ brew install valgrind</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">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"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">Error:</span><span style="font-variant-ligatures:no-common-ligatures"> 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"><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><blockquote type="cite"><div>On Apr 17, 2022, at 9:25 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">On Sun, Apr 17, 2022 at 2:59 PM Sanjay Govindjee <<a href="mailto:s_g@berkeley.edu" target="_blank">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"><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>
</div></blockquote></div><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>