[SOLVED] error message Ooops...Unable to find Mach task port for process-id

[Ziska]

Hi!
After not working with pascal and lazarus for a few years, I tried installing it on my laptop today. I have XCode 7.1.1 installed and downloaded and installed fpc, fpcsrc and lazarus itself. After getting a debugger file not found error, I installed gdb (version 7.10) using brew, made a certificate and signed gdb with it. The debugger file not found message is now gone. However, when I try running a project (even an empty one) I get following error message after successfully compiling the project:
Debugger error
Ooops, the debugger entered the error state Save your work now!
[...]
The GDB command:
"-exec-run"
returned the error:
",msg="Unable to find Mach task port for process-id 4275: (os/kern) failure (0x5).\n

So far I have tried deinstalling and reinstalling and signing gdb and changing the gdb path from usr/local/bin/gdb (only contains link to gdb file) to the path of the original gdb file.

I'm guessing the problem has something to do with the gdb version I'm using, but I am not sure.

Another question: Is it any easier to install lazarus on El Capitan? I was thinking of upgrading anyways...

Thanks in advance!
Ziska

[Jonas Maebe]

The error you get  does mean that the gdb binary is either not codesigned, or that there is a problem with the certificate. Some things to keep in mind:
* make sure you edit the certificate in the keychain after adding it and to set all "trust" settings to "trust always"
* ensure the certificate is in the keychain called "Login"
* you have to quit the Keychain Access utility after adding the certificate and kill the "taskgated" process before you can use the certificate (or restart the system).

It's not easier nor more difficult to install lazarus on El Capitan, because the gdb issue is exactly the same there.

[robsoft]

One thing to notice if you do go through the process again, for El Capitan - the Homebrew location of gdb.rb has changed in the last few days, and most of the current online instructions won't work when you try to get the gdb ruby package.

I ended up finding it in the github repository (it's moved from homebred-dupes to something like homebrew/Library/Formula), downloading the gdb.rb file to my mac and altering the install command e.g.

brew install ~/Downloads/gdb.rb

I got this working fine, and the debugger does kick in ok etc with a simple form/button/showmessage type app. I changed one of the debugger options over to 'dwarf' or similar - it does get mentioned in a lot of the online gdb guides.

edit:
https://github.com/Homebrew/homebrew/tree/master/Library/Formula for the new github page, and
https://github.com/Homebrew/homebrew/raw/master/Library/Formula/gdb.rb for the gdb.rb file itself

[Ziska]

Thank you so much, it works now! I changed the certificates settings and restarted my laptop and everything works perfectly =)
Als, thank you for the hints regarding El Capitan, I'll probably upgrade soon

[markusd112]

I don't get it running under OS X 10.11.2

I have created the "gdb-cert" certificate, put it in the system key chain and changed the trust settings to "always".

I have installed "gdb" and "gdb-apple" package via macports (that's the only difference) and have signed both (/opt/local/bin/ggdb and /opt/local/bin/gdb-apple) via codesign shell command.

But it doesn't work: lazarus always gives the error message "The debugger could not run the application. This may be caused by mussing debug info. The GDB command: '-exec-run' returned the error: ',msg='Unable to find Mach task port for process-id 818:(os/kern) failure (0x5).'"

Any idea what's going wrong here or where? Is it possible to test it via shell command (not via lazarus run)?

Thanks,

Markus

[Jonas Maebe]

Have you also done this part:

* you have to quit the Keychain Access utility after adding the certificate and kill the "taskgated" process before you can use the certificate (or restart the system)."

?

[markusd112]

Yes, I have done all, but without success...

I think I have found the solution: it seems there has been a rights problem on file system level:

the group for ggdb and gdb-apple executable in /opt/local/bin/ was set to "procmod" group. I have changed to to "admin" and then the ggdb debugger seems to work...

So I think it's a macports issue?!

Best regards,

Markus

[Jonas Maebe]

Yes, I have done all, but without success...

I think I have found the solution: it seems there has been a rights problem on file system level:

the group for ggdb and gdb-apple executable in /opt/local/bin/ was set to "procmod" group. I have changed to to "admin" and then the ggdb debugger seems to work...

That suggests you (or macports) are mixing two different ways of getting gdb to run:

• The old way (OS X 10.6 and earler) was to ensure that gdb was executed using the procmod group (set its group to procmod, set its setgid bit, and make sure the user trying to execute it is also a member of the procmod group
• The new way (OS X 10.7 and later) is using the code signing certificates

The old way still works on current systems if you modify how taskgated is started (by editing its launchd plist). You cannot do that easily on OS X 10.11 though, because it requires disabling system integrity protection. I'm not sure what happens if gdb is setgid procmod, but you are using the codesigning method. According to your experiences, it doesn't seem to work (although I'm not sure why). It's probably better to remove the setgid bit of the gdb executable altogether via "sudo chmod g-s /path/to/gdb" (see https://en.wikipedia.org/wiki/Setuid if you don't know what "setgid" means).

[markusd112]

Aahhh, that explains all that!

Thanks for the background informations. It now works fine.

Thanks a lot!!!

Greetings

Markus

[markusd112]

One little thing remains: after exiting my Lazarus application the gnu debugger seems to crash. Each time an error message pops up that says: "While executing the command:
"TGDBMIDebuggerInstruction: "-file-exec-and-symbols ", "
gdb reported:
"&"solib-target.c:324: internal-error: void solib_target_free_so(struct so_list *): Assertion `so-

Any idea, what's going wrong here?

Thanks,

Markus