Unable to find Mach task port for process-id 2546: (os/kern) failure
(0x5).\n (please check gdb is codesigned - see taskgated(8))
What's wrong with my ggdb debugger tool (gdb installed by MacPorts), It was working perfectly for months till now!
The whole problem starts just after running the following command to install some avr tools and libraries:
port install avrdude avarice avr-binutils avr-gcc avr-libc avr-gdb simulavr uisp git gcc5 gcc6
It's not a How-to-sign question, it's already signed months ago, however I'll really appreciate any help suggestions.
You may need to have a look at those:
which ggdb
/opt/local/bin/ggdb
security find-identity -p codesigning
Policy: Code Signing
Matching identities
1) 4627C4FCFACC41114B956E7DAB83E83C014641BC "gdb-cert"
1 identities found
Valid identities only
1) 4627C4FCFACC41114B956E7DAB83E83C014641BC "gdb-cert"
1 valid identities found
find / -name gdb
I'm not using this.
/Applications/Android Studio.app/Contents/bin/lldb/shared/stl_printers/gdb
/Applications/Arduino.app/Contents/Java/hardware/tools/avr/include/gdb
/Applications/CLion.app/Contents/bin/gdb
/Applications/CLion.app/Contents/bin/gdb/bin/gdb
/Applications/CLion.app/Contents/bin/gdb/share/gdb
/Applications/CLion.app/Contents/bin/gdb/share/gdb/python/gdb
/opt/local/include/gdb
/opt/local/libexec/gnubin/gdb
/opt/local/share/gdb
/opt/local/share/gdb/python/gdb
/opt/local/share/glib-2.0/gdb
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_cross_i386-mingw32-binutils/i386-mingw32-binutils/work/binutils-2.21/include/gdb
/opt/local/var/macports/software/gdb
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/gdb
find / -name ggdb
I'm using this.
/opt/local/bin/ggdb
uname -a
Darwin Ghoneim.local 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
Thanks for advance for helping me figuring it out..
Related
Suddenly on the afternoon of January 6, 2021, my Selenium Protractor tests under OSX stopped working with the mysterious error
spawn Unknown system error -86
I did some research and discovered that error number 86 is the same as
Bad CPU type in executable
and ran the following to compare the cpu architecture of my chromedriver binary to my system:
% file chromedriver_87.0.4280.88
chromedriver_87.0.4280.88: Mach-O 64-bit executable arm64
% uname -a
Darwin kobl179273m 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64
% uname -p
i386
How can I fix the chromedriver binary used by my Selenium so that it will run on my Intel x64 mac and clear the "system error -86" or "Bad CPU type" message?
The issue is described in https://github.com/angular/webdriver-manager/issues/476.
This has been now fixed in 12.1.8 so just update to that webdriver manager.
For most users this can be accomplished with
npm uninstall protractor && npm install protractor
Edit: this answer should be considered deprecated now that the underlying bug in webdriver-manager has been fixed. A better solution would be to upgrade to the newest version of webdriver-manager. The answer below may be useful if people need to use an older version of webdriver-manager which still has the bug.
As per Deepak Srinivasan's comment above, this error is caused by https://github.com/angular/webdriver-manager/issues/476
Root Cause:
The ChromeDriver team added "_m1" to the end of the filename for their Apple Silicon ARM builds of Chromedriver -- but both the Silicon and Intel versions of chromedriver have "mac64" in the filename, and the version number is exactly the same. This causes webdriver-manager to always download the Silicon build of Chromedriver, even on Intel macs. As a general solution, simply avoid using the chromedriver that has _m1 in its filename if you are on an Intel mac.
Solution 1: Downgrade to Chrome 86.0.4240.198 and Chromedriver 86.0.4240.22. These versions work together and are the most recent versions prior to the new and problematic support for Silicon ARM
Chrome 86 download page:
https://google-chrome.en.uptodown.com/mac/download/2920124
Disable auto-updates in Chrome: https://superuser.com/questions/1359017/how-do-i-disable-automatic-updates-of-google-chrome-on-mac-os-x
Chromedriver 86: https://chromedriver.storage.googleapis.com/index.html?path=86.0.4240.22/
% webdriver-manager update --versions.chrome=86.0.4240.22
Solution 2: Modify the webdriver-manager npm package to point to the correct chromedriver (thanks to ciekaway from the angular github issue page for this fix)
Modify the following file
node_modules/webdriver-manager/built/lib/files/file_manager.js
or, if using protractor
node_modules/protractor/node_modules/webdriver-manager/built/lib/files/file_manager.js
Near the top of the downloadFile method around line 166, add the following line to remove "_m1" from the name of the file:
fileUrl.url = fileUrl.url.replace(/_m1/, '');
It needs to be after the beginning of the .then block that starts with
binary.getUrl(binary.version()).then(fileUrl => {
it also needs to be before the next reference to fileUrl.
For example:
binary.getUrl(binary.version()).then(fileUrl => {
binary.versionCustom = fileUrl.version;
fileUrl.url = fileUrl.url.replace(/_m1/, '');
let filePath = path.resolve(outputDir, binary.filename());
Note that this solution is temporary. It will be overwritten by an npm install. The Chromedriver and/or the webdriver-manager team will probably fix this issue, at which point you should clear the modified version of your webdriver-manager and download the fix from npm.
For macOS Catalina Version 10.15.6 (19G73)
In my case I was working with Rails and Capybara for feature tests. What worked for me was
First, find the actual chromedriver location running:
which chromedriver
# Which returned:
/Users/alex/.webdrivers/chromedriver
Then, install chromedriver via Homebrew:
brew install chromedriver
Then, remove old chromedriver reference found at previous location with:
rm /Users/alex/.webdrivers/chromedriver
Now, link the old chromedriver reference to the one installed with brew:
ln -s /usr/local/bin/chromedriver /Users/alex/.webdrivers/chromedriver
Then, open Finder app, then click on Go menu and then click Go to folder ... option, and enter this route:
/usr/local/Caskroom/chromedriver/
There you should see a folder with the chromedriver version you have installed, something like this:
88.0.4324.96
Enter that folder and you should see the chromedriver binary file.
Right click on it, and click on Open
Now, you should get a terminal window popping up with the output:
Last login: Sun Jan 31 12:29:15 on ttys001
/usr/local/Caskroom/chromedriver/88.0.4324.96/chromedriver ; exit;
~ /usr/local/Caskroom/chromedriver/88.0.4324.96/chromedriver ; exit;
Starting ChromeDriver 88.0.4324.96 (68dba2d8a0b149a1d3afac56fa74648032bcf46b- refs/branch-heads/4324#{#1784}) on port 9515
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
Finally, press Ctrl+C to stop the execution and quit the terminal window.
Now, you should be able to run capybara tests.
npm uninstall protractor && npm install protractor
If you use webdrivers gem, upgrade it:
bundle update webdrivers
I have an app bundle containing a cli tool and a dylib. For testing I am calling the cli tool in Terminal (iTerm2):
DYLD_INSERT_LIBRARIES=./libwebsockets.14.dylib THNUCLNT_SVC="private" ./thnuclnt -v
dyld: Library not loaded: #rpath/libwebsockets.14.dylib
Referenced from: /Users/rwelz/Downloads/ezeep Connector.app/Contents/Resources/thnuclnt/thnuclnt/x86_64-darwin/./thnuclnt
Reason: image not found
Abort trap: 6
When I remove the signature from cli tool, everything works fine:
codesign --remove-signature thnuclnt
DYLD_INSERT_LIBRARIES=./libwebsockets.14.dylib THNUCLNT_SVC="private" ./thnuclnt -v
ThinPrint Client Mac Version 7.6.10.1, (c) 2007-2019 ThinPrint GmbH
removing signature from libwebsockets.14.dylib has no effect at all.
I know that the cli tool is using dlopen to load the dylib. But I have no code for the cli tool nor for the libwebsockets.dylib since these are programmed by a colleague of mine. I am only responsible for putting everything together in the app bundle. But everything is build on our build server - so everything uses the same certificate for code signing.
I expect my cli tool to load libwebsockets.dylib and execute and output the same as if it had no signature.
What is changing on the cli tool when codesign is applied? What is going on here?
Many thanks for your valuable help
regards,
Robert
PS.:
libwebsockets.14.dylib and tnuclnt reside in the same directory inside the resource folder of the app:
~/Downloads/my_supersecret.app/Contents/Resources/thnuclnt/thnuclnt/x86_64-darwin/] $ ls -l
total 3368
-rwxr-xr-x 1 rwelz staff 268K Sep 25 11:35 libwebsockets.14.dylib
-rwxr-xr-x 1 rwelz staff 321K Sep 25 11:35 thnuclnt
I'm trying to install the Awesome VM in Alpine Linux following this tutorial.
I have passed the following commands:
$ sudo apk add awesome feh lxterminal
$ sudo apk add lua
$ setup-xorg-base
Then and all the commands in the "Start Your Desktop" section ...
... but when I pass this command :
$ startx
I got the following errors:
hostname: dev-box: Host not found
xauth: unable to link authority file /home/babonet13/.Xauthority, use /home/babonet13/.Xauthority-n
xauth: unable to link authority file /home/babonet13/.Xauthority, use /home/babonet13/.Xauthority-n
X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.39-0-vanilla x86_64 Alpine Linux
Current Operating System: Linux dev-box 4.14.69-0-vanilla #1-Alpine SMP Mon Sep 10 19:33:23 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=vmlinuz-vanilla root=UUID=26f38daa-766f-49f1-abb3-a0f7e8fc9d15 modules=sd-mod,usb-storage,ext4 nomodeset quiet rootfstype=ext4 initrd=initramfs-vanilla
Build Date: 30 August 2018 02:57:08PM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Oct 5 13:33:54 2018
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
deallocvt: can't open console
Can could help me to start debugging it in the right way?
This is a problem installing X.org on Alpine Linux, you have not yet reached the point where Awesome is involved. I suggest you edit your post title and tags to reflect this. Also, stackoverflow is for programming question. If you have further installation issues, it is preferred to use SuperUser
Nevertheless:
(EE) no screens found(EE)
This is the error. It usually means you didn't install the video drivers or your kernel doesn't have the right modules or you use a static X.org build and it doesn't have the right compile options or you have a custum xorg.conf[.in] file that isn't representative of your setup.
/var/log/Xorg.0.log may have more information, but from my past experience with this kind of issue, wont provide more relevant details.
Also, it is AwesomeWM, not Awesome-VM.
I need help compiling nginx with the perl_module on my Mac:
System Software Overview:
System Version: OS X 10.11.1 (15B42)
Kernel Version: Darwin 15.0.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Computer Name: Philipp
User Name: XXXXXXX XXXXXXXX (philipp)
Secure Virtual Memory: Enabled
Time since boot: 4 days 22:46
I configure nginx to be compiled with PCRE and PERL, i.e.,:
./configure --with-pcre=/Users/philipp/downloads/pcre-8.38 --with-http_perl_module --prefix=/servers/nginx
The output of the configure states:
checking for perl
+ perl version: This is perl 5, version 18, subversion 2 (v5.18.2)
built for darwin-thread-multi-2level
+ perl interpreter multiplicity found
If I execute make I run into the following error:
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I googled and found a hint to export KERNEL_BITS=64, which did not solve the problem. Any suggestions on how to compile nginx with perl. The compilation succeeds without the --with-http_perl_module option, but in that case I cannot use perl in the nginx.conf (of course :)).
UPDATE:
I was not able to compile nginx with perl. I ended up using a pre-compiled package, which is kind of unsatisfying, because now I have to deal with a lot of packages I don't like. Anyways, if someone has a solution I'd be more than happy to know.
I'm not sure if this is offtopic or not, but as it's about using perl within nginx (which I do, and is awesome).
I had a similar problem when trying to build this module. The root of it was that I hadn't got the right LD flags.
The easiest way of doing this - IMO - is install nginx from a package, run nginx -V and see what flags were used - copy them all, and include the extras. (And check it wasn't already build in your distribution - it was in mine, which I think was a Centos 7.2 package - I don't have it to hand, but I'm not sure it would necessarily help)
You may also need to install a new perl version, to go with it though.
--with-pcre=../modules/pcre-8.38
--with-openssl=../modules/openssl-1.0.2g
--prefix=/usr/local/nginx
--with-http_perl_module
--with-http_ssl_module
--with-http_addition_module
--with-http_sub_module
--with-http_realip_module
--with-http_stub_status_module
--with-cc-opt='-I /usr/local/include'
--with-ld-opt='-L /usr/local/lib -L/usr/local/opt/perl518/lib'
I got the same problem. after about 3 hours digging with this, finally solved. This is my configure file, i installed perl518 with brew located in /usr/local/opt/perl518/lib, and use the newest nginx source code of version nginx version: nginx/1.10.0.
Things seems happend as #Sobrique said, you need to give the right --with-ld-opt & --with-cc-opt.
important, after ./configure, DO NOT doing make immediately, vi ./objs/Makefile and modify openssl config from './config' to './Configure darwin-x86_64-cc' so that it can build openssl in x86_64 mod.
Hope it can help you!
I'm trying to give HsOpenSSL a whirl on Mac OS X, and it's blowing up in my face.
The latest Hackage version (HsOpenSSL-0.10.3.3) builds and imports, but doing anything with it kills my GHCi (both 7.6.3 and 7.4.2):
ghci> import OpenSSL
ghci> withOpenSSL $ do undefined
$ # Now I'm looking at a shell prompt
I put together an executable and built it with GHC, and voilà, a segfault:
$ ./test
Segmentation fault: 11
I'm using the version of OpenSSL that comes with OS X 10.8:
$ openssl version
OpenSSL 0.9.8r 8 Feb 2011
(I've also now installed the latest version of OpenSSL, v1.0.1e, and built HsOpenSSL against it. Again it builds and imports fine, but segfaults on any call out to OpenSSL.)
This is likely a problem with OpenSSL, or with some idiosyncrasy of using OS X rather than Linux, but my installation does work fine with Python's OpenSSL library. ...
Can anyone replicate this, or give me any debugging tips?
I'm afraid I have another negative report - it works here for me, on OS X. Hypothetically, I might be using a version that I might not be allowed to mention, though, so that could be the difference...
module Main (main) where
import OpenSSL
main :: IO ()
main = withOpenSSL $ do
putStrLn "Hm."
Then I can run it with:
$ ghc Crash.hs
... [it compiles] ...
$ ./Crash
Hm.
And it succeeds. I'm using GHC 7.6.3, HsOpenSSL 0.10.3.3, and OpenSSL 0.9.8y, this last dated 5 Feb 2013.