What's the difference between starting a process from the dock vs. the command line on OS X

Question

I'm debugging an issue on OS X that only occurs when the application is started from the dock. It does not happen when the app is started from the command line. What is the difference between the two scenarios? The code I'm working with is a c++ based bundled plug-in being loaded in a third party app. I've attached to the process with GDB in both scenarios and the only difference I can see is that a couple of extra dylibs are loaded in the process when running from the command line and that the base address of my library is slightly different in the two scenarios. I've tried changing my linkage to -prebind and/or -bind_at_load to no avail.

Answer 1

One important difference is that the initial working directory will be different in each case. Applications should never make any assumptions about the working directory and will break in interesting ways if they do.

Answer 2

An application launched from the Dock icon won't pick up the same environment variables that may be set in the shell you're using. If you're relying on picking up something from the environment, you'll want to look for a different approach. You'll get some of the env vars, like PATH, HOME, LOGNAME, etc. But if you're looking for HOSTTYPE, LANG, OSTYPE, et al, they're not going to be present.

Answer 3

In this case, my problem was caused by a difference in the order that shared libraries are loaded. One of the third party libraries that our application uses loads extension libraries into a global namespace. There were symbol conflicts with a different version of that same library. The order that the extension libraries are loaded into the global pool changes based on whether the app is started from the doc or from the command line.

Answer 4

In a similar situation, I have a crash when running from the app bundle. One possibility is that we are using memory that we have already deallocated. E.g. using a pointer or a field of a class after free() or delete.

It looks like app bundles are dynamically linked with a different free/delete implementation which zeroes/modify the deallocated memory.

This kind of bug might not appear using other platforms/compilers (e.g. Linux/gcc, Windows/Visual Studio, macOS/clang from command line) and only appear when the program is executed from an app bundle (macOS/clang from Finder/dock).