I wanted to do again to develop in haxe on my MacBook after quite a long time. So I go on haxe.org, download the mac installer and install the latest version of haxe with it.
Then I open the terminal and type haxe, just to encounter this short error message:
Bus Error
Well, did I do something wrong? I'm using OSX 10.4, can it be that the latest version of haxe is not supported on this operating system?
UPDATE:
Looking into the system log, I found out that after the installer was called, the following messages:
Nov 12 18:12:16 my-computer authexec: executing /Volumes/haXe Installer/haXe Installer.app/Contents/MacOS/hxinst-osx
Setting FD_CLOEXEC on all file descriptors
Initializing child but not closing any file descriptors...
Initializing child but not closing any file descriptors...
Nov 12 18:13:25 my-computer crashdump[1655]: haxe crashed
Nov 12 18:13:25 my-computer crashdump[1655]: crash report written to: /Users/myuser/Library/Logs/CrashReporter/haxe.crash.log
Also, investigating the crash log, I got a name for the exception which resulted from the crash:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Any idea? I'm investigating the problem further.
Bus error means that the program itself is broken (specifically, it means that the program used an unaligned or completely garbage pointer). To find out why, you could try attaching gdb (gdb haxe) and poking around
It is very likely that the installer was built on and targeted for a later version of OS X (either 10.5 or 10.6). You may find more information in your system log (/Applications/Utilities/Console.app). You could ask in the Haxe community or, if you're feeling brave, you could try building your own version from source.
Related
I'm experimenting with building a Windows and Mac OS app using Electron and have hit a snag.
In short, if I try to run the application directly with Electron on Mac OS Big Sur (as opposed to building a Mac app and then running that) I get the following error returned:
[35941:0821/171720.038162:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
I am running directly with Electron using the following in my package.json:
"scripts": {
...
"test": "electron main.js",
...
}
So far the only Mac OS environment I have access to is Big Sur so haven't tried this on earlier versions of Mac OS but from Googling it seems this error may be related to Big Sur's tightened security/sandbox constraints -- but I am guessing about that.
In any case, after some Googling several suggestions indicated trying to run without the app sandbox, i.e. adding this to main.js:
app.commandLine.appendSwitch('no-sandbox');
That's all well and good and works.
However, if I ever want to build and distribute a signed Mac app targeting the Mac App store or a just a signed, sandboxed DMG or PKG installer, then this won't be suitable.
If I remove the above no-sandbox command from main.js and specify the app sandbox in my entitlements plist as shown below the resulting signed app will not run:
<key>com.apple.security.app-sandbox</key>
<true/>
The app tries to open and just closes. I can try running at the command line with open <appname>.app but this throws the following error in the console:
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2561, NSUnderlyingError=0x7fd3c9c13db0 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x7fd3c9c158e0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 153}}}}}
If I build a signed app with no-sandbox enabled, the app will run just fine on Big Sur using open <appname>.app.
I have tried my best through Google, Stack Overflow, etc to diagnose this but am not getting anywhere. Here's to hoping the Stack Overflow community can provide me the critical clue to solving this.
For further context, I created a new, empty Electron application and followed the Electron Quick Start Guide to the section where it describes creating an empty main.js which technically should allow the Electron app to start -- but it won't. The same error describe above re the GPU gets thrown even without instantiating a BrowserWindow or writing any custom code of my own.
NEW UPDATE: I set these environment variables to true and then tried running the app with npm start:
ELECTRON_ENABLE_LOGGING
ELECTRON_DEBUG_NOTIFICATIONS
ELECTRON_ENABLE_STACK_DUMPING
The result is more detailed error output:
[48836:0823/165857.676747:ERROR:icu_util.cc(179)] icudtl.dat not found in bundle
[48836:0823/165857.676838:ERROR:icu_util.cc(243)] Invalid file descriptor to ICU data received.
[48778:0823/165857.677376:ERROR:gpu_process_host.cc(1003)] GPU process exited unexpectedly: exit_code=5
[48778:0823/165857.677430:WARNING:gpu_process_host.cc(1317)] The GPU process has crashed 1 time(s)
[48850:0823/165857.827224:ERROR:icu_util.cc(179)] icudtl.dat not found in bundle
[48848:0823/165857.827255:ERROR:icu_util.cc(179)] icudtl.dat not found in bundle
[48850:0823/165857.827341:ERROR:icu_util.cc(243)] Invalid file descriptor to ICU data received.
[48848:0823/165857.827358:ERROR:icu_util.cc(243)] Invalid file descriptor to ICU data received.
[48778:0823/165857.827836:ERROR:gpu_process_host.cc(1003)] GPU process exited unexpectedly: exit_code=5
[48778:0823/165857.827875:WARNING:gpu_process_host.cc(1317)] The GPU process has crashed 2 time(s)
... repeats until the GPU processes crashes 9 times ...
[48778:0823/165903.080134:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
Haven't had time to do the research as to what ICU refers to but thought I would update with this info.
ANOTHER UPDATE: all this has been done on Mac OS Big Sur which is my main development machine. Trying this on a Windows 10 machine, using the same Electron code, dependencies, etc and things work fine. So the problem is either related to Mac OS Big Sur or a specific local issue on my development machine which I cannot identify. Any suggestions on how to diagnose this will be much appreciated.
ONE MORE UPDATE: Based on a guess, I created a new user on my mac, took the code in there and it ran perfectly. So -- this probably means that I need to find something installed in my profile or some corruption in my own profile/settings that is breaking things. As always, any suggestions appreciated it.
In my case, I got this to work using command line switch, --in-process-gpu, or:
app.commandLine.appendSwitch('in-process-gpu');
There's also an extensive list of Chromium switches here that you can try at:
https://peter.sh/experiments/chromium-command-line-switches/
Yeah, the whole hardened runtime thing is just such an awful, awful mess! Now to figure out the next crash!
So -- partial answer. I think I've found the solution to this error:
GPU process isn't usable. Goodbye.
My development directories are all on a file system accessed via a symbolic link. As soon as I moved the folder for this app to my my home directory (no symlinks involved) I could launch with npm start without needing to enable no-sandbox and without seeing this error or the errors related to icudtl.dat.
I haven't yet determined if the problem described with the error below when launching the packaged app is related/solved:
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2561, NSUnderlyingError=0x7fd3c9c13db0 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x7fd3c9c158e0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 153}}}}}
That said, it is a big step forward.
I have a similar issue on a linux machine with an electron app. The answer in this github issue helped me.
Using --disable-gpu-sandbox flag with electron apps solved it for me.
The underlying problem seems to be that the Mac OS sandbox is preventing the GPU process to spawn properly.
You can specify a variety of entitlements when packaging your application, but not all entitlements are created equally, especially entitlements that want access to the keychain, secure enclave and TouchID.
If you're specifying a provisioning profile - make sure that all those entitlements are only in the original file, keep your inherited entitlements empty or to the bare minimum. In my case, I had the keychain-access-groups specified in my inherited entitlements which was a painful lesson to learn. Removing it made the builds not crash!
I believe in your case it's likely that you tried to access files outside of the application itself which might have caused the sandbox to prevent opening the GPU processes.
I know the OP reported this against MacOS, but on my Windows 10 VM I used the following instructions to create the electron-quick-start app…
net use T: \\busdata\company\BrianT
T:
cd \Development\Sandbox\electron
"C:\Users\thomasb\AppData\Local\GitHubDesktop\app-2.9.15\resources\app\git\cmd\git.exe" clone https://github.com/electron/electron-quick-start
cd electron-quick-start
npm install && npm start
…and then electron wrote error messages to the console, the same errors as those reported by the OP:
[5796:1025/121431.238:ERROR:gpu_process_host.cc(969)] GPU process launch failed: error_code=18
[5796:1025/121431.328:FATAL:gpu_data_manager_impl_private.cc(441)] GPU process isn't usable. Goodbye.
An earlier answer mentioned symbolic links, and to investigate that further I xcopied the entire electron-quick-start folder down from T: (a remapped network folder) to C: (my local disk).
When I then ran npm start in the folder that I'd copied down to C: there was no error.
Looks like electron is being fussy about where the source files live.
I had the same Issue when running the files off of a server such as a nas, but moving files to local storage solved the issue.
I'm trying to develop code under 64-bit Cygwin, and I'm having trouble getting a core dump file that I can use under GDB. The code is compiled using GCC 7.3.0, and I've just updated my Cygwin bits. ulimit -c is unlimited.
I've got my $CYGWIN variable set to point to dumper, and that appears to be being launched on crashes. I get a pop-up, and the message
*** starting debugger for pid 5288, tid 9464
*** continuing pid 5288 from debugger call (1)
Aborted (core dumped)
and a core file (basic.exe.core) is created in the current dir.
When I try to run (the stock Cygwin) GDB on this
gdb tests/basic.exe --core=basic.exe.core
I get the normal version intro, Reading symbols..., and then a warning
warning: core file may not match specified executable file.
and GDB crashes (and dumps its own core file). The crashing program was launched from the Cygwin bash command line (as ./tests/basic.exe).
It's been a long time since I've tried to develop under Windows or Cygwin, so it's quite possible that I'm doing something stupid. Or, alternatively, it may be that GCC 7.3.0 is doing something wrong or that I configured it poorly when I built it.
Any help will be appreciated.
here is a link to a C++ (CLion) project. I've distilled/simplified the issue down as much as I could.
The problem is that when debugging, LLDB (version 3.9.0) crashes.
Steps to reproduce crash:
Open project with CLion 2017.1 (use built in LLDB for debug)
Compile the Project
Place breakpoint in main.cpp line 14
Run in debug mode.
Once you're at line 14 breakpoint, then output the variable "an_integer" via the "print an_integer" command.
Crash
The Error/Crash Report:
Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file
/Applications/buildAgent/work/92515a49514b3993/lldb/llvm/tools/clang/lib/AST/Decl.cpp,
line 1360.
Note that this crash occurs with LLDB v3.9.0 on Mac v10.12.4. But it does not occur with LLDB 3.7.0 on Mac 10.12.4.
Ultimately, I'm wanting to know if I'm doing something dumb in my project code? If not, is this a bug with CLion or LLDB? Is there somewhere that I should post this to help get the bug (if it is that) resolved?
That doesn't look like your bug. For some reason lldb is having trouble ingesting the type information produced by the compiler.
I don't have clion so I can't try that, but if I just build your test project, either with a PCH or without, using clang from Xcode 8.3 I don't see this crash. Best thing to do is to build this project with CLion, then make a dSYM (if CLion doesn't do this for you.) You do that by running:
> dsymutil TestingLLDBBreaking
Check that you can reproduce the crash with the dSYM, and if so then file a bug with http://bugreporter.apple.com with the executable and the .dSYM.
So I had the same problem for a while.
just before almost formatting my mac I've re-cloned the project to a different directory and ran it from there. No issues. (i'm sure its a mac-os thing).
Good luck :)
I just have installed Lazarus on my MacBook Air with OS X 10. And when I want to run a code, it says
Exit code 256
Does anyone know, what should I do?
Explanation
I had the same problem. I tried to compile this extremely basic program:
program HelloWorld;
begin
Writeln('Hello, world');
end.
And I got the error message:
Compile Project, Target: HelloWorld: Exit code 256, Errors: 1
Fatal: Compilation aborted
I think this was due to the fact that I had installed macOS Sierra last weekend. So I re-installed (with some difficulties, see below) the fcp, fpcsrc and lazarus packages and recompiled the source. Now I got a success message.
Answer
So re-download the packages above (they may have longer names, but these are the base names). Then first install fpc, then fpcsrc and then lazarus. Note that if you simply double-click the .pkg files in the .dmg files, macOS Sierra will complain:
“lazarus.pkg” can’t be opened because it is from an unidentified developer.
So open the context menu (right click) and select Open. Then you will get:
“lazarus.pkg” is from an unidentified developer. Are you sure you want to open it?
Then you can click the Open button and it will start the installer anyway. Follow the instructions and all should install well.
After that, you should be able to compile your code without that ugly error message. Note that under OS X (or, as they call it now, macOS) you won't be able to debug console mode programs from the Lazarus IDE. You'll have to start it from the console.
I've recently updated my system to Ubuntu 14.04 LTE. I've also updated the version of my QtCreator to 3.3.
When I run in Release mode, no problem. However, when I tried to debug, something strange happens: The system throws a Segmentation Fault, and the application give me this message:
&"warning: GDB: Failed to set controlling terminal: Inappropriate ioctl for device\n"
I saw other comments that propose to downgrade the GDB version from 7.8 to 7.7 and other saying the opposite thing. I tried both but nothing works.
I saw some posts saying that it's a bug, but I'm not being able to find any solution in these messages.
Have anyone some suggestions?
Thank you very much!
EDIT:
I tried to use gdb via command line, and it works a little bit different: The segmentation fault remains, but the error is different:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1da2a70 in boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64, long double>::init::init() ()
from /usr/lib/libpcl_sample_consensus.so.1.7
I removed the flag -std=c++0x from my makefile in order to not use c++11. Then, using command line gdb, the debugging works. However, using QtCreator it still not working.
Any idea? Thaaanks!
I get this message every time I debug, but the debugging works fine. I'm sure I found a comment on the QT forums that says just ignore it.
Have you tried debugging a trivial "hello world" program?