gdb kończy się niepowodzeniem z błędem „Nie można znaleźć portu zadania Mach dla identyfikatora procesu”


138

Moja aplikacja działa poprawnie, ale gdb nie może jej debugować z następującym błędem

(gdb) run
Starting program: /path/to/app 
Unable to find Mach task port for process-id 83767: (os/kern) failure (0x5).

Jestem na OS X Lion. Wersja GDB to

$ gdb --version
GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".

Myślę, że ten post może pomóc: stackoverflow.com/questions/10221448/… .
Codie CodeMonkey,

Odpowiedzi:


64

W systemie Snow Leopard i późniejszych wersjach systemu Mac OS nie wystarczy kodować gdbpliku wykonywalnego.

Aby to działało, musisz postępować zgodnie z tym przewodnikiem: http://www.opensource.apple.com/source/lldb/lldb-69/docs/code-signing.txt

Przewodnik wyjaśnia, jak to zrobić lldb, ale proces jest dokładnie taki sam dla gdb.


12
Te instrukcje nie działały dla mnie na OSX 10.9.2 z MacPorts, ale tak się stało
simpleuser

To działa! Ale czy możesz wyjaśnić, co sudo security add-trustrobi linia? Czy mogę teraz usunąć .cerplik z mojego pulpitu?
Sreejith Ramakrishnan

9
codesign -s gdb_codesign `which gdb` pomaga po tym przewodniku
synther

Lub sudo codesign -s gdb_codesign `which gdb-apple` na macOS Sierra.
nurkowanie

3
W przypadku najnowszego systemu operacyjnego łącze działało
yuxuan

144

Działa, gdy się zmieniam na sudo gdb executableFileName! :)


2
Dzięki. To podpisywanie kodu plus było wymagane, aby GDB działało. Dałem uprawnienia roota do gdb (jak opisano tutaj stackoverflow.com/questions/10476154/… ), więc nie musiałem za każdym razem wpisywać sudo. Edycja - tutaj znalazłem lepsze podejście: stackoverflow.com/a/10441587/305149
Aneil Mallavarapu

14
Uruchomić jako root? Mówisz poważnie? Najgorsze „rozwiązanie”.
Equidamoid

7
@Equidamoid Dlaczego byłoby tak źle działać gdbjako root? Byłem po prostu ciekawy, ponieważ to tylko debugger.
TEN UŻYTKOWNIK POTRZEBUJE POMOCY

Co by się stało, gdybyś uruchomił go jako root? To kod, który napisałeś i nie rozumiem konsekwencji
COLD ICE

4
@COLDICE ogólnie nie chcesz uruchamiać procesów ze zwiększonymi uprawnieniami (szczególnie eskalowanymi do góry jako root), ponieważ generalnie nie potrzebują dostępu do modyfikowania rzeczy w systemie lub otwierania portów niższych niż 1024 (wyższe porty mogą być używany przez użytkowników innych niż system / root). Nawet jeśli „ufasz” swojemu własnemu kodowi, nie oznacza to, że nie popełniłeś błędu, który spowodowałby jego powstanie rm -rf /lub coś podobnego destrukcyjnego, polegającego na nadpisaniu niektórych konfiguracji / plików binarnych, na których opiera się Twój komputer, aby uruchomić i działać normalnie.
shaunhusain

32

Musisz utworzyć certyfikat i podpisać gdb:

  • Otwórz aplikację „Keychain Access” (/ Applications / Utilities / Keychain Access.app)
  • Otwórz menu / Dostęp do pęku kluczy / Asystent certyfikatu / Utwórz certyfikat ...
  • Wybierz nazwę (w przykładzie gdb-cert), ustaw „Identity Type” na „Self Signed Root”, ustaw „Certificate Type” na „Code Signing” i wybierz opcję „Let me override defaults”. Kliknij „Kontynuuj”. Możesz przedłużyć wstępnie zdefiniowany okres 365 dni do 3650 dni.
  • Kliknij kilka razy „Kontynuuj”, aż dojdziesz do ekranu „Określ lokalizację certyfikatu”, a następnie ustaw „Pęk kluczy na system”.
  • Jeśli nie możesz przechowywać certyfikatu w pęku kluczy „System”, utwórz go w pęku kluczy „login”, a następnie wyeksportuj. Następnie możesz zaimportować go do pęku kluczy „System”.
  • W pękach kluczy wybierz „System” i powinieneś znaleźć nowy certyfikat. Skorzystaj z menu kontekstowego certyfikatu, wybierz „Uzyskaj informacje”, otwórz element „Zaufaj” i ustaw „Podpisywanie kodu” na „Zawsze ufaj”.
  • Aby użyć certyfikatu, należy zamknąć aplikację „Dostęp do pęku kluczy” i ponownie uruchomić usługę „Taskgated”, kończąc aktualnie działający proces „Taskgated”. Alternatywnie możesz ponownie uruchomić komputer.
  • Wreszcie możesz podpisać gdb:

    sudo codesign -s gdb-cert /usr/local/bin/ggdb

    sudo ggdb ./myprog


4
zabijanie notatek z bramkowanymi zadaniami nie restartuje procesu. potrzebne do: sudo launchctl load /System/Library/LaunchDaemons/com.apple.taskgated.plist
Ben

Powyższe zrestartowano Taskgated - ale niestety nadal nie działało bez ponownego uruchomienia na Sierra.
Neil McGill

16

Problem polega na tym, że nie jesteś zalogowany jako użytkownik root (czego nie chcesz). Aby uzyskać dostęp do gdb, musisz utworzyć certyfikat. Postępuj zgodnie z tym samouczkiem i powinieneś być gotowy ...

http://sourceware.org/gdb/wiki/BuildingOnDarwin

Jeśli wszystko inne zawiedzie, po prostu użyj: sudo gdb executableFileName


4
Samouczek podany tutaj działał najlepiej. Wystarczyło uruchomić, codesign -s gdb-cert $(which gdb)aby podpisać gdbaplikację.
cevaris

Potwierdzam tylko, że każdy, kto próbuje tego na OSX 10.12.5, musi wykonać oba kroki opisane w linku BuildingOnDarwin ORAZ uruchomić gdb po przełączeniu się na użytkownika root.
AdjunctProfessorFalcon

7

Ten link miał najbardziej przejrzysty i najbardziej szczegółowy krok po kroku, aby ten błąd zniknął dla mnie.

W moim przypadku musiałem mieć klucz jako klucz „systemowy”, w przeciwnym razie nie zadziałał (o czym nie każdy adres URL wspomina).

Zabijanie taskgatedjest również realną (i szybszą) alternatywą dla konieczności ponownego uruchamiania.

Odinstalowałem również MacPorts, zanim zacząłem ten proces, i odinstalowałem obecny GDB przy użyciu brew uninstall gdb.


To zadziałało dla mnie. +1 dla odniesienia, który używa brew.
trigoman

3

Potrzebowałem tego polecenia, aby działało na El Capitan:

sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/gdb-cert.cer


2

W systemie MacOSX lldb musi być podpisany kodem. Kompilacje debugowania i wydania są ustawione na podpisywanie kodu przy użyciu certyfikatu podpisującego kod o nazwie lldb_codesign.

If you don't have one yet you will need to:
- Launch /Applications/Utilities/Keychain Access.app

- In Keychain Access select the "login" keychain in the "Keychains"
  list in the upper left hand corner of the window.

- Select the following menu item:

    Keychain Access->Certificate Assistant->Create a Certificate...

- Set the following settings

    Name = lldb_codesign
    Identity Type = Self Signed Root
    Certificate Type = Code Signing

- Click Continue
- Click Continue
- Click Done
- Click on the "My Certificates"
- Double click on your new lldb_codesign certificate
- Turn down the "Trust" disclosure triangle

    Change:
        When using this certificate: Always Trust

- Enter your login password to confirm and make it trusted

The next steps are necessary on SnowLeopard, but are probably because of a bug
how Keychain Access makes certificates.

- Option-drag the new lldb_codesign certificate from the login keychain to
  the System keychain in the Keychains pane of the main Keychain Access window
  to make a copy of this certificate in the System keychain.  You'll have to
  authorize a few more times, set it to be "Always trusted" when asked.
- Switch to the System keychain, and drag the copy of lldb_codesign you just
  made there onto the desktop.
- Switch to Terminal, and run the following:

sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/lldb_codesign.cer

- Right click on the "lldb_codesign" certificate in the "System" keychain (NOT
  "login", but the one in "System"), and select "Delete" to delete it from
  the "System" keychain.
- Reboot
- Clean and rebuild lldb and you should be able to debug.

That should do it.

[Uwaga: - lldb jest używany w mac jako gdb.]


2

Oto naprawdę przydatny przewodnik, który rozwiązał mój problem (OSX 10.13.6).

  1. Otwórz dostęp do pęku kluczy
  2. W menu otwórz Dostęp do pęku kluczy> Asystent certyfikatu> Utwórz certyfikat
  3. Nadaj mu nazwę (np. Gdbc)
    • Typ tożsamości: katalog główny z podpisem własnym
    • Typ certyfikatu: podpisywanie kodu
    • Sprawdź: pozwól mi zastąpić ustawienia domyślne
  4. Kontynuuj, aż pojawi się monit o: „określ lokalizację ...”
  5. Ustaw lokalizację pęku kluczy na System
  6. Utwórz certyfikat i zamknij asystenta.
  7. Znajdź certyfikat w Systemowych pękach kluczy, kliknij go prawym przyciskiem myszy> uzyskaj informacje (lub po prostu kliknij dwukrotnie)
  8. Rozwiń Zaufanie, ustaw podpisywanie kodu na zawsze zaufane
  9. Zrestartuj taskgated w terminalu: killall taskgated
  10. Uruchom codesign -fs gdbc /usr/local/bin/gdbw terminalu: prosi o hasło roota

1

Te instrukcje działają na OSX High Sierra i unikają uruchamiania gdb jako root (fuj!). Niedawno zaktualizowałem z OSX 10.13.2 do 10.3.3. Myślę, że to wtedy, gdy gdb 8.0.1 (zainstalowany w / homebrew) zaczął mi zawodzić.

Miałem trudności z poleceniami innych osób. Po różnych instrukcjach wszystko się pogmatwało. Więc zacząłem od nowa. Mniej więcej postępowałem zgodnie z tymi instrukcjami .

Oczyść bałagan:

  1. brew uninstall --force gdb # This deletes _all_ versions of gdb on the machine
  2. W Applications-> Utilities-> Keychain Accessusunąłem wszystkie poprzednie certyfikaty i klucze gdb (upewnij się, że wiesz, co tu robisz!). Nie jest jasne, czy jest to konieczne, ale ponieważ popełniłem błąd, próbując utworzyć te certyfikaty i klucze przy użyciu innych instrukcji, i tak je wyeliminowałem. Miałem klucze i certyfikaty zarówno w logowaniu, jak iw systemie.

Teraz ponownie zainstaluj gdb.

  1. brew install gdb
  2. Wewnątrz Keychain Accessprzejdź do menu Keychain Access-> Certificate Assistant->Create a Certificate
  3. Zaznacz „Pozwól mi zastąpić ustawienia domyślne” i ustaw
Name : gdb-cert
Identity Type: Self Signed Root
Certificate Type : Code Signing

[X] Let me override defaults
  1. Na pierwszej stronie informacji o certyfikacie:
Serial Number : 1
Validity Period (days): 3650
  1. Na drugiej stronie Informacje o certyfikacie wszystkie pola z wyjątkiem tych już wypełnionych pozostawiłem puste.

  2. Na stronie Informacje o parach kluczy zostawiłem wartości domyślne

Key Size : 2048
Algorithm : RSA
  1. Na stronie rozszerzenia użycia klucza pozostawiłem zaznaczone wartości domyślne.
[X] Include Key Usage Extension
[X] This extension is critical
Capabilities:
[X] Signature
  1. Na stronie Rozszerzone rozszerzenie użycia klucza pozostawiłem zaznaczone wartości domyślne.
[X] Include Extended Key Usage Extension
[X] This extension is critical
Capabilities:
[X] Code Signing
  1. Na stronie rozszerzenia podstawowych ograniczeń nic nie zostało zaznaczone (domyślnie).

  2. Na stronie Subject Alternate Name Extension zostawiłem domyślne zaznaczone i nie dodałem nic więcej.

[X] Include Subject Alternate Name Extension
  1. Na Specify a Location dla strony certyfikatu ustawiłem
Keychain: System
  1. Kliknąłem Utwórz i zostałem poproszony o podanie hasła.

  2. Po powrocie do Keychain Accessaplikacji przeszedłem do Systemi kliknąłem prawym przyciskiem myszy gdb-certiw menu rozwijanym Trustzmieniłem wszystkie pola na Always Trust.

  3. Zrestartowany komputer.

  4. Na terminalu pobiegłem codesign -s gdb-cert /usr/local/bin/gdb. Po wyświetleniu monitu wprowadziłem hasło.

  5. Na terminalu pobiegłem echo "set startup-with-shell off" >> ~/.gdbinit

  6. Uruchomiłem, gdb myprograma następnie startw konsoli gdb. Tutaj, jak sądzę, poprosił mnie o podanie hasła. Po tym, przy wszystkich kolejnych uruchomieniach, nie pytał o moje hasło.


Niestety, uzyskałem zarówno odpowiedź z największą liczbą głosów, jak i Twoją odpowiedź, i nadal widzę ten sam komunikat o błędzie. Mam macOS Catalina w wersji 10.15.4 i GDB 9.1.
Jay Sullivan

@JaySullivan +1. Ja też mam ten sam problem.
irsis

1

To dziwne podejście, ale zadziałało dla mnie (MacOs HighSierra 10.13.3). Zainstaluj CLion. Pochodzi z gdb. Po uruchomieniu gdb za pomocą terminala. Skopiuj program gdb do swojego usr / local / bin /. Nie ma problemu z logowaniem, sudo itp.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.