启动从坞站进程与OS X上的命令行之间的区别是什么
我正在调试OS X上的一个问题，只有当应用程序从坞站启动时才会出现问题。当应用程序从命令行启动时不会发生。这两种情况有什么区别？我正在使用的代码是在第三方应用程序中加载的基于C++的捆绑插件。我在这两种情况下都使用GDB连接到了进程，唯一的区别是我可以看到，从命令行运行时，在进程中加载了几个额外的dylib，并且我的库的基址地址在两种情况。我试着将链接改为-prebind和/或-bind_at_load无济于事。启动从坞站进程与OS X上的命令行之间的区别是什么
一个重要的区别是，初始工作目录在每种情况下都会有所不同。应用程序不应该对工作目录做出任何假设，并且如果它们确实会以有趣的方式突破。
根据更多的调查，我开始认为这个问题是一个记忆腐败问题，“只从码头上”的症状是一个红鲱鱼。虽然它似乎不是我的问题，但当我试图想出可能性时，不同的工作目录绝对是我看过的。谢谢你的提示！ – 2010-04-06 15:21:57
从Dock图标启动的应用程序不会选取可能在您正在使用的shell中设置的相同环境变量。如果你依靠从环境中获取某些东西，你会想要寻找一种不同的方法。你会得到一些环境变量，比如PATH，HOME，LOGNAME等。但是如果你正在寻找HOSTTYPE，LANG，OSTYPE等等，他们不会在场。
在这种情况下，我的问题是由于加载共享库的顺序不同造成的。我们的应用程序使用加载扩展库到全局名称空间的第三方库之一。与同一个库的不同版本存在符号冲突。扩展库加载到全局池的顺序会根据应用程序是从doc启动还是从命令行进行更改。
在类似的情况下，我从应用程序包运行时发生崩溃。一种可能是我们正在使用我们已经释放的内存。例如。在free()或delete之后使用指针或类的字段。
它看起来像应用程序捆绑动态链接到一个不同的free/delete实现，它将零/修改释放的内存。
这种类型的错误可能不会使用其他平台/编译器（例如Linux/gcc，Windows/Visual Studio，命令行中的macOS/clang）出现，并且仅在从应用程序包（macOS/clang来自Finder/dock）。
如果你能告诉我们什么是A.问题是什么，B.预期的行为是什么，以及C.实际发生的事情会更有帮助。 – 2010-03-31 14:34:35
+1。这个问题本身就是有效的：“从OS X的命令行启动进程与启动进程之间有什么区别”，无论Josh遇到了什么问题。 – z5h 2010-03-31 14:38:50
不幸的是，我正在作为一个“中间人”在这里帮助我们的合作伙伴解决与他们的图书馆的问题......我没有课程的代码:)它花了一些时间来获得更好的细节。具体而言，对于unicode“RIGHT SINGLE QUOTATION MARK”字符而言，icu4c中的“unorm_normalize”函数返回错误，但仅当该应用程序从码头启动时。 – 2010-04-06 15:18:32