I also am receiving this error after I installed GDB using Homebrew.  One thing important to mention is that I am running on the new M1 ARM architecture MacBook Pro using macOS BigSur. 

 I receive the error whenever I use the "run" command to start GDB debugging.  NOTE:  Homebrew explicitly states that it is not compatible with ARM architecture yet, though I found a workaround and was able to install Homebrew and then use the "brew" command to install GDB.  After installing GDB, I get the below error.


(gdb) run
Starting program: /Users/*********/Desktop/a.out 
[New Thread 0x1f03 of process 1824]
[New Thread 0x2003 of process 1824]
../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n

(In reply to ethanrob122 from comment #1)
> I also am receiving this error after I installed GDB using Homebrew.  One
> thing important to mention is that I am running on the new M1 ARM
> architecture MacBook Pro using macOS BigSur. 
> 
>  I receive the error whenever I use the "run" command after running GDB as sudo. (I use "sudo gdb" to run gdb as super-user)
> 
> (gdb) run
> Starting program: /Users/*********/Desktop/a.out 
> [New Thread 0x1f03 of process 1824]
> [New Thread 0x2003 of process 1824]
> ../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t):
> Assertion `ptid == inferior_ptid' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y
> 
> This is a bug, please report it.  For instructions, see:
> <https://www.gnu.org/software/gdb/bugs/>.
> 
> ../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t):
> Assertion `ptid == inferior_ptid' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) n

This appears to still be an issue on macOS Big Sur 11.1. I am running on an ARM architecture Mac, but GDB is run under Rosetta 2 x86 emulation.

This is the output after attempting to run a program from within GDB.

Starting program: /Users/fisherfugler/Documents/Operating Systems/s21-project-1-ffugler/tree 
[New Thread 0x2a03 of process 988]
[New Thread 0x2b03 of process 988]
target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
zsh: abort      gdb tree

It does not appear that a core file was created.

Yes, getting the same problem here on M1 MBP macOS 11.1. Is it that gdb has not been ported over for apple silicone yet?


(gdb) run
Starting program: /Users/franklinshe/Desktop/c_practice/count
[New Thread 0x2a03 of process 13787]
[New Thread 0x2b03 of process 13787]
../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n

This particular assertion failure means there's a bug in GDB. Function target_mourn_inferior expects that the ptid it is passed corresponds to the current thread.  That means the caller should call `switch_to_thread` or `switch_to_thread_no_regs` before calling target_mourn_inferior.  We would need to find out who calls target_mourn_inferior to add it.

Somebody with macOS needs to do that investigation.

And yeah, I presume that to support macOS on ARM, we will need some new code that ties the right things together.  We have i386-darwin-nat.c implementing native support for macOS on both i386 and x86_64.  Presumably, there would be aarch64-darwin-nat.c / aarch64-darwin-tdep.c files for macOS on AArch64.

I get the same error message on my 8-year old Mac (x86) running Big Sur 11.2. I use GDB 10.1 from Homebrew. 

It does not happen on every run. My MWE:
```
// test.cpp
#include<iostream>

int main()
{
    int a{ 4 };

    std::cout << "a = " << a << '\n';

    return 0;
}
```
Simply running the program under GDB yields:
```
(gdb) r
Starting program: test-gdb/a.out
[New Thread 0x1a03 of process 24826]
[New Thread 0x1b03 of process 24826]
warning: unhandled dyld version (17)
a = 4
[Inferior 1 (process 24826) exited normally]
```
However, setting breakpoints triggers it:
```
(gdb) b main
Breakpoint 1 at 0x100003e57: file test.cpp, line 5.
(gdb) r
Starting program: test-gdb/a.out
[New Thread 0x2403 of process 24836]
[New Thread 0x2203 of process 24836]
warning: unhandled dyld version (17)

Thread 2 hit Breakpoint 1, main () at test.cpp:5
5	    int a{ 4 };
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) q
A debugging session is active.

	Inferior 1 [process 24836] will be killed.

Quit anyway? (y or n) y
../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

../../gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
[1]    24834 abort      gdb a.out
```

I also get this error on my old macOS 10.11.6 system with a self-compiled GDB 10.1. This did not happen with GDB 8.3.1 which I was using previously.

So it is definitely not specific to ARM or even Big Sur...

My reproducer program:

~~~cpp
# test.cpp
void here() {};

int main() {
    const int size = 5;
    double array[size] = {1.0, 2.0, 3.0, 4.0, 5.0};
    here();
    return 0;
}
~~~

I build that example and invoke GDB like so:

~~~shell
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ g++ -O0 -g test.cpp -o test
$ gdb --configuration
This GDB was configured as follows:
   configure --host=x86_64-apple-darwin15.6.0 --target=x86_64-apple-darwin15.6.0
             --with-auto-load-dir=:${prefix}/share/auto-load
             --with-auto-load-safe-path=:${prefix}/share/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/Cellar/gdb/10.1/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/Cellar/gdb/10.1/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
             --without-intel-pt
             --with-mpfr
             --without-xxhash
             --with-python=/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7
             --with-python-libdir=/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib
             --without-debuginfod
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/local/Cellar/gdb/10.1/lib/debug (relocatable)

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)
$ gdb --batch ./test -ex 'b here' -ex run
Breakpoint 1 at 0x100000e74: file test.cpp, line 1.
[New Thread 0x1403 of process 30980]

Breakpoint 1, here () at test.cpp:1
1       void here() {};
warning: Mach error at "../../gdb-10.1/gdb/darwin-nat.c:453" in function "void darwin_resume_inferior(struct inferior *)": (ipc/send) invalid destination port (0x10000003)
../../gdb-10.1/gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

../../gdb-10.1/gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
Abort trap: 6
~~~

Note that no core file is generated despite the last message...

Ok so it appears core dumps are not written to the current working directory on macOS, you learn something new everyday...

So you need to do the following ([1], [2]):

~~~shell
$ ulimit -c unlimited
$ chmod o+w /cores
$ gdb --batch ./test -ex 'b here' -ex run 
# GDB fails as above
$ ls /cores
core.32580
$ lldb -c /cores/core.32580
(lldb) target create --core "/cores/core.32580"
Core file '/cores/core.32580' (x86_64) was loaded.
(lldb) bt
* thread #1: tid = 0x0000, 0x00007fff98713f06 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff98713f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff94c264ec libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff8a4e36df libsystem_c.dylib`abort + 129
    frame #3: 0x00000001003547cd gdb`internal_vproblem(internal_problem*, char const*, int, char const*, __va_list_tag*) [inlined] dump_core() + 1325 at utils.c:204 [opt]
    frame #4: 0x00000001003547a4 gdb`internal_vproblem(problem=<unavailable>, file=<unavailable>, line=<unavailable>, fmt=<unavailable>, ap=<unavailable>) + 1284 at utils.c:414 [opt]
    frame #5: 0x000000010035427e gdb`internal_verror(file=<unavailable>, line=<unavailable>, fmt=<unavailable>, ap=<unavailable>) + 30 at utils.c:439 [opt]
    frame #6: 0x0000000100414ad4 gdb`internal_error(file=<unavailable>, line=<unavailable>, fmt=<unavailable>) + 116 at errors.cc:55 [opt]
    frame #7: 0x00000001003035ac gdb`target_mourn_inferior(ptid=<unavailable>) + 124 at target.c:2149 [opt]
    frame #8: 0x00000001000df487 gdb`darwin_nat_target::kill(this=<unavailable>) + 791 at darwin-nat.c:1535 [opt]
    frame #9: 0x000000010032796f gdb`quit_force(int*, int) [inlined] kill_or_detach(inf=<unavailable>, from_tty=<unavailable>) + 207 at top.c:1689 [opt]
    frame #10: 0x0000000100327921 gdb`quit_force(exit_arg=<unavailable>, from_tty=<unavailable>) + 129 at top.c:1780 [opt]
    frame #11: 0x00000001001f06a8 gdb`captured_main_1(context=<unavailable>) + 9592 at main.c:1234 [opt]
    frame #12: 0x00000001001ee06f gdb`gdb_main(captured_main_args*) [inlined] captured_main(void*) + 11 at main.c:1243 [opt]
    frame #13: 0x00000001001ee064 gdb`gdb_main(args=<unavailable>) + 4 at main.c:1268 [opt]
    frame #14: 0x0000000100000bea gdb`main(argc=<unavailable>, argv=<unavailable>) + 42 at gdb.c:32 [opt]
    frame #15: 0x00007fff8b1495ad libdyld.dylib`start + 1
(lldb) 
~~~

I've never debugged a debugger before, nor done system-level programming so I'm really at the limit of my knowledge here... I'm willing to help further though. I'll start by recompiling GDB without optimization.

[1] https://stackoverflow.com/questions/9412156/how-to-generate-core-dumps-in-mac-os-x
[2] https://developer.apple.com/library/archive/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCOREDUMPS

I recompiled 10.1 with both CFLAGS and CXXFLAGS set to '-O0 -g' and re-ran my test. I zippped the core dumped and uploaded it to my dropbox since it's too big to attach https://www.dropbox.com/s/3jo9fogiuas9cyp/core.52896.zip?dl=1

Here is the backtrace:
~~~
$ lldb -c /cores/core.52896 
(lldb) target create --core "/cores/core.52896"
warning: (x86_64) /cores/core.52896 load command 112 LC_SEGMENT_64 has a fileoff + filesize (0x257fe000) that extends beyond the end of the file (0x257fd000), the segment will be truncated to match
Core file '/cores/core.52896' (x86_64) was loaded.
(lldb) bt
* thread #1: tid = 0x0000, 0x00007fffa002bf06 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
  * frame #0: 0x00007fffa002bf06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff9c53e4ec libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff91dfb6df libsystem_c.dylib`abort + 129
    frame #3: 0x00000001007806d4 gdb`dump_core() + 52 at utils.c:204
    frame #4: 0x0000000100781aba gdb`internal_vproblem(problem=0x0000000100b8c850, file="../../gdb-10.1/gdb/target.c", line=2149, fmt="%s: Assertion `%s' failed.", ap=0x00007fff5fbfd850) + 4746 at utils.c:414
    frame #5: 0x0000000100780815 gdb`internal_verror(file="../../gdb-10.1/gdb/target.c", line=2149, fmt="%s: Assertion `%s' failed.", ap=0x00007fff5fbfd850) + 53 at utils.c:439
    frame #6: 0x00000001008c5068 gdb`internal_error(file="../../gdb-10.1/gdb/target.c", line=2149, fmt="%s: Assertion `%s' failed.") + 344 at errors.cc:55
    frame #7: 0x00000001006d216a gdb`target_mourn_inferior(ptid=(m_pid = 52898, m_lwp = 0, m_tid = 0)) + 90 at target.c:2149
    frame #8: 0x00000001002134d3 gdb`darwin_nat_target::kill(this=0x0000000100ba6260) + 979 at darwin-nat.c:1535
    frame #9: 0x00000001006cb435 gdb`target_kill() + 21 at target.c:300
    frame #10: 0x0000000100701248 gdb`kill_or_detach(inf=0x000000010159c130, from_tty=0) + 120 at top.c:1689
    frame #11: 0x0000000100700d53 gdb`quit_force(exit_arg=0x0000000000000000, from_tty=0) + 323 at top.c:1780
    frame #12: 0x000000010046052a gdb`captured_main_1(context=0x00007fff5fbff6a8) + 19754 at main.c:1234
    frame #13: 0x000000010045b76d gdb`captured_main(data=0x00007fff5fbff6a8) + 29 at main.c:1243
    frame #14: 0x000000010045b6b1 gdb`gdb_main(args=0x00007fff5fbff6a8) + 17 at main.c:1268
    frame #15: 0x0000000100001083 gdb`main(argc=7, argv=0x00007fff5fbff6f0) + 99 at gdb.c:32
    frame #16: 0x00007fff92a615ad libdyld.dylib`start + 1
~~~

note the "warning" that I was not getting yesterday...

Created attachment 13260 [details]
Proposed patch

Can you please try the attached patch?  The explanation of the problem and of the fix is in the patch's message.  If that works for you I'll submit it for merging.

(In reply to Philippe Blain from comment #10)
> warning: (x86_64) /cores/core.52896 load command 112 LC_SEGMENT_64 has a
> fileoff + filesize (0x257fe000) that extends beyond the end of the file
> (0x257fd000), the segment will be truncated to match

Regarding this warning, I don't think GDB has anything to do with this.  AFAIK the core isn't produced by GDB (is it produced by the kernel?) and it is read by lldb.

Hi Simon, 

I recompiled with your patch on top of the latest master f16ccf47d87 (Automatic date update in version.in, 2021-02-23) and re-ran my test and it works correctly.

The patch did not apply directly on top of the 10.1 tarball or the gdb-10-branch branch though. I don't know how release management is done for this project so  I don't know if it matters, i.e. would the patch be backported for a 10.2 release or something like this.

Thanks for the patch.

Signé: un confrère de Poly!

Forget my comment about the patch not applying to the 10.1 branch, it does.

(In reply to Philippe Blain from comment #13)
> Hi Simon, 
> 
> I recompiled with your patch on top of the latest master f16ccf47d87
> (Automatic date update in version.in, 2021-02-23) and re-ran my test and it
> works correctly.

Great, thanks.

> 
> The patch did not apply directly on top of the 10.1 tarball or the
> gdb-10-branch branch though. I don't know how release management is done for
> this project so  I don't know if it matters, i.e. would the patch be
> backported for a 10.2 release or something like this.

Development happens on master, but if this is a regression we can backport it to the gdb-10-branch, so it is included in the upcoming GDB 10.2 release.  I think it wouldn't hurt in this case.

> 
> Thanks for the patch.
> 
> Signé: un confrère de Poly!

Yay!

(In reply to Philippe Blain from comment #14)
> Forget my comment about the patch not applying to the 10.1 branch, it does.

Ok, thanks.

The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dffdd8b51f3fb086faf750592709baa8faa66fd1

commit dffdd8b51f3fb086faf750592709baa8faa66fd1
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Thu Feb 25 15:52:29 2021 -0500

    gdb: relax assertion in target_mourn_inferior
    
    As reported in PR 26861, when killing an inferior on macOS, we hit the
    assert:
    
        ../../gdb-10.1/gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
    
    This is because darwin_nat_target::kill passes a pid-only ptid to
    target_mourn_inferior, with the pid of the current inferior:
    
        target_mourn_inferior (ptid_t (inf->pid));
    
    ... which doesn't satisfy the assert in target_mourn_inferior:
    
        gdb_assert (ptid == inferior_ptid);
    
    The reason for this assertion is that target_mourn_inferior is a
    prototype shared between GDB and GDBserver, so that shared code in
    gdb/nat (used in both GDB and GDBserver) can call target_mourn_inferior.
    In GDB's implementation, it is likely that some targets still rely on
    inferior_ptid being set to "the current thread we are working on".  So
    until targets are completely decoupled from inferior_ptid (at least
    their mourn_inferior implementations), we need to ensure the passed in
    ptid matches inferior_ptid, to ensure the calling code called
    target_mourn_inferior with the right global context.
    
    However, I think the assert is a bit too restrictive.  The
    mourn_inferior operation works on an inferior, not a specific thread.
    And by the time we call mourn_inferior, the threads of the inferior
    don't exist anymore, the process is gone, so it doesn't really make
    sense to require inferior_ptid to point a specific thread.
    
    I looked at all the target_ops::mourn_inferior implementations, those
    that read inferior_ptid only care about the pid field, which supports
    the idea that only the inferior matters.  Other implementations look at
    the current inferior (call `current_inferior ()`).
    
    I think it would make sense to change target_mourn_inferior to accept
    only a pid rather than a ptid.  It would then assert that the pid is the
    same as the current inferior's pid.  However, this would be a quite
    involved change, so I'll keep it for later.
    
    To fix the macOS issue immediately, I propose to relax the assert to
    only compare the pids, as is done in this patch.
    
    Another solution would obviously be to make darwin_nat_target::kill pass
    inferior_ptid to target_mourn_inferior.  However, the solution I propose
    is more in line with where I think we want to go (passing a pid to
    target_mourn_inferior).
    
    gdb/ChangeLog:
    
            PR gdb/26861
            * target.c (target_mourn_inferior): Only compare pids in
            target_mourn_inferior.
    
    Change-Id: If2439ccc5aa67272ea16148a43c5362ef23fb2b8

The gdb-10-branch branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=962ba37a9229979d0baf68e2d5de05962466dc94

commit 962ba37a9229979d0baf68e2d5de05962466dc94
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Thu Feb 25 15:52:29 2021 -0500

    gdb: relax assertion in target_mourn_inferior
    
    As reported in PR 26861, when killing an inferior on macOS, we hit the
    assert:
    
        ../../gdb-10.1/gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
    
    This is because darwin_nat_target::kill passes a pid-only ptid to
    target_mourn_inferior, with the pid of the current inferior:
    
        target_mourn_inferior (ptid_t (inf->pid));
    
    ... which doesn't satisfy the assert in target_mourn_inferior:
    
        gdb_assert (ptid == inferior_ptid);
    
    The reason for this assertion is that target_mourn_inferior is a
    prototype shared between GDB and GDBserver, so that shared code in
    gdb/nat (used in both GDB and GDBserver) can call target_mourn_inferior.
    In GDB's implementation, it is likely that some targets still rely on
    inferior_ptid being set to "the current thread we are working on".  So
    until targets are completely decoupled from inferior_ptid (at least
    their mourn_inferior implementations), we need to ensure the passed in
    ptid matches inferior_ptid, to ensure the calling code called
    target_mourn_inferior with the right global context.
    
    However, I think the assert is a bit too restrictive.  The
    mourn_inferior operation works on an inferior, not a specific thread.
    And by the time we call mourn_inferior, the threads of the inferior
    don't exist anymore, the process is gone, so it doesn't really make
    sense to require inferior_ptid to point a specific thread.
    
    I looked at all the target_ops::mourn_inferior implementations, those
    that read inferior_ptid only care about the pid field, which supports
    the idea that only the inferior matters.  Other implementations look at
    the current inferior (call `current_inferior ()`).
    
    I think it would make sense to change target_mourn_inferior to accept
    only a pid rather than a ptid.  It would then assert that the pid is the
    same as the current inferior's pid.  However, this would be a quite
    involved change, so I'll keep it for later.
    
    To fix the macOS issue immediately, I propose to relax the assert to
    only compare the pids, as is done in this patch.
    
    Another solution would obviously be to make darwin_nat_target::kill pass
    inferior_ptid to target_mourn_inferior.  However, the solution I propose
    is more in line with where I think we want to go (passing a pid to
    target_mourn_inferior).
    
    gdb/ChangeLog:
    
            PR gdb/26861
            * target.c (target_mourn_inferior): Only compare pids in
            target_mourn_inferior.
    
    Change-Id: If2439ccc5aa67272ea16148a43c5362ef23fb2b8

This is hopefully fixed now, please re-open if it isn't.

Set the target-milestone to 10.2 as Simon backported it to the gdb-10-branch as well.

Thanks for the fix, Simon!

*** Bug 27342 has been marked as a duplicate of this bug. ***