I've got a user reporting crashes in my Mac OS X application, and their console logs report the following:
Symbolication warning: error parsing FDE at 0x100052649 in:\n
Does anyone have any insight into what this might be? I assume that somehow the symbols have been stripped from my app in a way that gets in the way of Mac OS X's crash reporter, but I've not seen it before.
I can honestly say that I have never seen this one before. I have seen a number of other dynamic linking problems just not this one. If the user is amenable to helping you with this defect, you might want to write a shell script to enable some dynamic linking environment variables and then launch your application.
#! /bin/bash
export DYLD_PRINT_LIBRARIES=1
export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
export DYLD_PRINT_APIS=1
export DYLD_PRINT_BINDINGS=1
export DYLD_PRINT_DOFS=1
open -a Console.app > /tmp/link-log 2>&1
The output log might provide some hint as to what is going on. You could also capture the output of otool and other command line utilities to check for unexpected libraries and what not.
You might want to google Symbolication to get a better handle of what is going on here. I came across an interesting chunk of code from Darwin that points this to a dynamic symbol lookup warning. There is also a utility called Shark that may be of interest as well.
Good luck...
I just found this topic via Google because I'm having the same problem. The StarCraft installer crashes immediately. It points to /usr/libexec/oah/translate, which seems to work perfectly well. My guess is this has something to do with the fact the computer it doesn't work on runs iDeneb 1.3 (aka Mac OS X 86 for use on non-Apple hardware), whereas the computer that can run the application just fine has a genuine version of Leopard.
Related
I'm perplexed by this one and not sure what's relevant so will include all context:
MacBook Pro with an M1 Pro running macOS 12.6.
Apple clang version 14.0.0, freshly installed by deleting DeveloperTools folder and running xcode-select --install.
Using zsh in Terminal.
Network share mounted using no-configuration Finder method (seems to use standard SMB, but authenticates with my Apple ID)
Network share is my home directory on a iMac with a Core i5 running macOS 11.6.8.
Update: also tried root directory and using the tmp directory, to eliminate one category of doubt. Same result.
The minimum repeatable example of the issue I've managed to find is:
Use gcc from Apple's Developer Tools to compile a “Hello World” C application (originally discovered using ghc to compile Haskell - effect is the same).
Run the compiled executable. No surprises.
cd to the mounted network drive.
Do the same thing there - compiled executable hangs! First surprise, but relatively minor.
Return to the local machine. Original compiled executable still runs fine.
Use the DeveloperTools to compile anything, including the original source - compiled executable on local machine now hangs!
I've created an asciinema recording of the MRE. You can see the key part of the transcript in this still:
I’ve tried killing processes, checking lsof, unmounting the drive, logging in and out, checking the PATH, etc. Nothing gets me back to a working state short of a reboot.
Some more troubleshooting data:
gcc -v is identical for both executables, except for -fdebug-compilation-dir (set to cwd) and the name of the object file (randomly generated).
Just performing the compilation doesn't trigger the issue - running the networked executable does.
Trawling through the voluminous Console log reveals nothing relevant.
system.log shows no entries around the time of the issue.
lsof and ps -axww show reams and reams of output that is hard to spot patterns in, but I'm pretty sure there is no significant before/after differences.
I left the hung process running on the local machine overnight, and there's no change the next day.
Have I triggered some sandboxing or security fault and am being protected from disastrous consequences? Or this some clang/llvm related quirk I'm not familiar with? Or, given that ghc using its native code generator seems to have the same result, is this a bug in the way stdout is provided to executables? I'm at a loss!
Oh boy, avoiding Apple ID authentication of the network share fixed this for me.
I forced Finder to not use it’s magic no-configuration Apple ID login method, by opening the Location in Finder, clicking the "Disconnect" button and then clicking the "Connect As..." button that appears in its place. If I choose "Registered User" and use my username and password, I can then execute exactly the same commands (since the mount name ends up being the same) and execution works without an issue. I can continue to compile and execute to my heart's content.
That the Apple ID method is being used in the first place is not obvious (in true minimal design fashion), but subtly indicated at the top of the Finder window as "Connected as ". The only obvious difference this makes, is the username shown in mount:
Apple ID:
//com.apple.idms.appleid.prd.<UUID>#<HOSTNAME>._smb._tcp.local/<SHARE> on /Volumes/<SHARE> (smbfs, nodev, nosuid, mounted by <USERNAME>)
"Registered User":
//<USERNAME>#<HOSTNAME>._smb._tcp.local/<SHARE> on /Volumes/<SHARE> (smbfs, nodev, nosuid, mounted by <USERNAME>)
Obviously something far more significant is different, given the fundamental impact, but it's not at all clear to me what that is. So at this stage, this answer is just a workaround to a nasty bug.
I've hooked the system call to typedef int (*orig_open_f_type)(const char *__file, int __oflag, ...); and thus, whenever a file gets opened, my code gets the event before it is passed on to the system. I created a dynamic library that overrides the open call and inject this library using DYLD_INSERT_LIBRARIES - working on a Mac machine and using XCode. It is a standard step that enables me to hook calls.
Now, I have bash script in which I have some files that I want to open. I have tried xdg-open , cat, exec - but they are not triggering the system call to open the file.
How should I invoke this open call in my bash script?
Please note that I have tested my open call hook, by opening files in C code.
I believe you're running foul of Apple's SIP (System Integrity Protection) which is designed to stop people doing things like that with system-provided executables. SIP was added to Mac OS X El Capitan (10.11) and continues in macOS Sierra (10.12).
To demonstrate whether this is the problem, consider copying /bin/cat to /usr/local/bin/cat and then try hooking (running) the local copy. You might get away with it there. This 'workaround' is purely for demonstration purposes. Basically, if I'm right, SIP is Apple's way of saying "don't go messing with our software".
You can follow links from Can Mac OS X El Capitan run software compiled for Yosemite that expects libraries in /usr/gnu/lib? to find out more about SIP. Following links via What is the "rootless" feature in El Capitan, really? on Ask Different to a blog article on System Integrity Protection, it says explicitly:
Runtime protection
SIP’s protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.
task_for_pid() / processor_set_tasks() fail with EPERM
Mach special ports are reset on exec(2)
dyld environment variables are ignored
DTrace probes unavailable
However, SIP does not block inspection by the developer of their own applications while they’re being developed. Xcode’s tools will continue to allow apps to be inspected and debugged during the development process.
For more details on this, I recommend taking a look at Apple’s developer documentation for SIP.
Emphasis added
Basically, this means that you won't be able to hook calls to the open() system call for Apple-supplied software installed in the system directories. You will need to rethink what you are trying to do.
Running any normal command -- like cat -- that processes a file will cause the file to be opened. You can also open a file (and immediately close it) using the shell syntax:
: < /path/to/file
If your system call hook isn't getting called, something must be wrong with your hook -- there's no way these commands are working without opening the file. Alas, you haven't explained how you implemented your hook, so we have no way of debugging that.
The file command opens the file to look at its contents.
$ file /path/to/file
I have suggested this because it eventually leads to having the system call open which can be confirmed using strace.
$ strace file /path/to/file 2>&1 | grep open
I thought one of the good things about using file is that it opens the file in read only mode. In comparison to other ideas, unlike cat, it will not have to run through the entire file, just part of it, so the time complexity using file may be constant. Unlike vim, which someone has suggested, file will return when finished and not block like a text editor would.
I am on Mac OSX 10.7 however I believe this would also appear in 10.8+
Try running (within erlang)
wx:demo().
Which will produce the following output:
beam.smp[2733:f0b] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.
Now the demo runs just fine but why output this line then?
It speaks nothing of erlang and after some browsing around it seems as if this is a wxWidgets bug as people have the same issue in python and that it is Mac OSX centric due to the CommonCocoaPanels.bundle in the output.
Its really just an annoyance for now as everything runs just fine. But it is more than likely a bug, no?
How can it be fixed?
As far as I know wxErlang is currently broken on MacOS and maintainers promise to fix it after wxWidgets 3.0 release.
Which version of wxWidgets are you using? I used wxWidgets 2.8.12 under Mac OS 10.6.8, custom build for Carbon with -arch i386.
In wxWidgets 2.8.x, Carbon is the recommended library because it is the
more stable. Cocoa is incomplete in wxWidgets 2.8.x. If you are interested
in using Cocoa, you should start with wxWidgets 2.9.x where Cocoa is
much more complete.
The framework itself looked somehow alien to Max OS (maybe because of Carbon), a small part of API was broken (this does not prevent programs to actually run - just small annoyances).
For my future reference, and that of others..
The following will work without displaying the above error message.
P = wx:new(),
F = wxFrame:new(P, 1, "main", [{size, {600,600}]),
WindowOpts = [{size, {600,600}}, {style, ?wxSUNKEN_BORDER}],
W = wxWindow:new(F, ?wxID_ANY, WindowOpts),
wxFrame:connect(F, close_window, [{skip,true}]),
wxWindow:connect(W, paint, [{skip, true}]),
wxFrame:show(F),
wxFrame:centre(F).
Strangely enough even with all my trial and error debugging, line by line, there is really no easy way to get to the bottom of it. It turns out to be the inclusion of a:
process_flag(trap_errors, true)
Will generate that error. I am positive there is nothing crashing that would invoke the actions of the flag.
Deep error. Little consequence.
Lets hope they get it fixed along with the 3.0 upgrade.
Here is what I want to do:
I want to run Mathematica on another Mac from my Mac (both Snow Leopards). I want to do this because the remote Mac has multiple cores/processors while my local Mac is rather shabby. I would like to have the front end still locally (i.e. the graphical interface).
What I've learned:
I used to do this type of thing from multiple Linux machines and was expecting to have similar success for Mac-to-Mac operation. However no such luck.
The problem seems to be a display issue (front end).
Mac front end runs in Aqua while X11 is what is really needed (this is why there is no problem on Unix). While Macs have X11, for some reason Mathematica can't use it.
So how do I get around this issue?
Possible solutions that I have had to rule out are: 1. screen sharing. Not practical since someone else will be using the remote Mac on another account. Screen sharing only uses the active screen. 2. Installing Unix on the remote computer. Not possible in my situation.
Thanks.
You should be able to set up a remote kernel on the other Mac. This is done through the Evaluation > Kernel Configurations menu item. The you can set the remote kernel for a given notebook using Evaluation > Notebook's Kernel or globally via Evaluation > Default Kernel.
I haven't done this in a while, and it's sometimes useful to test things from a terminal with something like
ssh <user>#<remote.machine.com> </path/to/remote/Mathematica.app/Contents/MacOS/MathKernel>
Why not use the command line kernel? I have a script math which does:
#!/bin/bash
rlwrap /Applications/Mathematica.app/Contents/MacOS/MathKernel
I built rlwrap from source, but basically that tool gives you readline behaviors. You can just do
ssh remote-machine /Applications/Mathematica.app/Contents/MacOS/MathKernel
The only solution, I believe, is for you to upgrade to OS X Lion. It allows simultaneous screen sharing sessions where each user can control the screen for their own account:
http://www.apple.com/macosx/whats-new/features.html#screensharing
I have a testing setup which runs an Application on OS X with a varying set of parameters, if/when the program crashes it's relaunched and continues from where it left off. However when the Application crashes OS X raises the “Application quit unexpectedly” dialog, I'd rather avoid this as it clutters the machine. Is there a way to inhibit this dialog from opening without modifying the source of the Application? If it's of any help in honing solutions the scripting setup is written in Python.
As an example, on Windows I handle the GPF dialog like this:
SEM_NOGPFAULTERRORBOX = 0x0002
ctypes.windll.kernel32.SetErrorMode(SEM_NOGPFAULTERRORBOX);
Ideally there'd be something similar I could use on OS X.
Thanks.
With the developer tools (Xcode, etc.) installed, you get a tool called CrashReporterPrefs. This is basically an interface to some plist file that sets globally how you want crashes handled. Probably not exactly what you're looking for, but if you control the deployment environment it might help.
There must be other options because Google products, like Sketchup, override the default handler and install their own crash reporter. My guess is that they register signal handlers for SIGBUS, SIGSEGV, etc. (see man 2 sigaction) and somehow mask the crash from MacOSX... but I'm speculating here.
I'll let others ask the question on why you can't fix the crash instead. :-)