Run as another user with su - Here's where things get interesting.Application Support garbage - Lacking other intelligent avenues, I tried copying the entire ~/Library/Application Support folder from the "bad" to "good" account, to see if that did anything.Same result after a logout/login on the "good" account side, the app still runs. Preferences garbage - I tried copying (and chowning) the ~/Library/Application Support/Preferences folder from the "bad" account to the "good" account, thinking that perhaps there were some preferences causing the crash.Though Apple's way of loading Frameworks seems rather complex, so maybe there is something else that can be eliminated? User-specific Framework - Neither user has a ~/Library/Frameworks folder in their homedir, which would be the obvious place for a user-specific framework to be hiding.I also moved/chowned ~/bin over, so they had access to the same stuff in the path, in addition to having the same $PATH set. (Yeah, I really liked that theory, too.) N.B. So it doesn't seem to just be an environment var that's set on one side but not on the other.
Program launches fine for one user, crashes for the other. bashrc to the "good" user account, such that printenv shows the same variables set in each user's environment. Environment variables - On the theory that there's something going on with the "bad" user's $PATH, I copied/chowned.It fixed a couple of things, but didn't appear to make a difference. Repair permissions - Just for starters, I ran Disk Utility's "Repair Permissions" a few times on the boot disk.In fairness, I do have a lot of stuff installed (XCode and CLI tools, MacPorts, Homebrew, LaTeX, various releases of Python, etc.) but they are all installed for all users, not to the affected user's homedir. When run from a Guest account or a different user's account, it launches just fine with no suggestion as to what might be going wrong. But I'm open to other thoughts on what it might mean. My interpretation of this is that it's trying to load something from a NIB, possibly from a shared framework, and it's choking.
The error that's causing the crash is setObjectForKey: object cannot be nil (key: LibraryPath)' When launched by the "bad" user, the application immediately quits with this crashlog output. So, obviously, the problem is related to that user's account/environment. The problem is that it crashes immediately after launch, with absolute consistency, but only when run from a particular user's account, but not when run from a Guest account or from another user.
#Macbook pro 2009 appdelete does not work mac os x#
I have a Mac OS X application (Garmin's "VIRB Edit", which lets you download videos from the VIRB series of GoPro-ish cameras) that has turned into a slightly obsessive technical challenge.
0 kommentar(er)
