从Dock开始进程与OS X上的命令行有什么区别

Question

我正在调试OS X上的问题，该问题仅在从Dock启动应用程序时发生。从命令行启动应用程序时不会发生这种情况。这两种情况有什么区别？我正在使用的代码是一个基于c ++的捆绑插件，它被加载到第三方应用程序中。我在两种情况下都使用GDB附加了进程，唯一的区别是我从命令行运行时在进程中加载​​了几个额外的dylib，并且我的库的基地址略有不同两种情况。我已经尝试将我的链接更改为-prebind和/或-bind_at_load无效。

Answer 1

一个重要的区别是初始工作目录在每种情况下都会有所不同。应用程序永远不应该对工作目录做出任何假设，并且如果有的话会以有趣的方式打破。

Answer 2

从Dock图标启动的应用程序不会获取可能在您正在使用的shell中设置的相同环境变量。如果您依赖于从环境中获取某些东西，那么您将需要寻找不同的方法。你会得到一些env变种，比如PATH，HOME，LOGNAME等等。但如果你正在寻找HOSTTYPE，LANG，OSTYPE等，它们就不会出现。

Answer 3

在这种情况下，我的问题是由加载共享库的顺序不同引起的。我们的应用程序使用的第三方库之一将扩展库加载到全局命名空间中。与同一个库的不同版本存在符号冲突。扩展库加载到全局池的顺序会根据应用程序是从文档还是从命令行启动而更改。

Answer 4

在类似情况下，从应用程序包运行时出现崩溃。一种可能性是我们正在使用已经解除分配的内存。例如。在free()或delete之后使用指针或类的字段。

看起来应用程序包动态链接到不同的free/delete实现，该实现将取消分配/修改已释放的内存。

这种错误可能不会出现使用其他平台/编译器（例如Linux / gcc，Windows / Visual Studio，命令行中的macOS / clang），只有在从应用程序包执行程序时才会出现（macOS / clang来自取景器/底座）。