从OS X的Dock和命令行启动进程有什么区别?

4
我正在调试一个仅在从 Dock 启动应用程序时出现的 OS X 问题。当应用程序从命令行启动时,这种情况不会发生。这两种情况之间有什么区别?我正在使用的代码是基于 C++ 的捆绑插件,正在第三方应用程序中加载。我已经在两种情况下使用 GDB 进行了连接,我能看到的唯一区别是在从命令行运行时加载了一些额外的 dylibs,并且我的库的基址在这两种情况下略有不同。我已尝试将链接方式更改为-prebind和/或-bind_at_load,但没有效果。

如果您能告诉我们A.问题所在,B.期望的行为是什么以及C.实际发生了什么,那会更有帮助。 - Billy ONeal
这个问题本身是有效的:“在OS X上从dock和命令行启动进程有什么区别”,与Josh正在经历什么无关。 - Mark Bolusmjak
不幸的是,我在这里充当“中间人”,帮助我们的一个合作伙伴解决他们的库问题...当然我没有代码 :) 获取更好的细节花费了一些时间。具体而言,对于Unicode“RIGHT SINGLE QUOTATION MARK”字符,“icu4c”的“unorm_normalize”函数返回错误,但仅当应用程序从dock启动时才会出现此问题。 - Josh Knauer
4个回答

1
一个重要的区别是每种情况下的初始工作目录都不同。应用程序不应该对工作目录做任何假设,如果这样做,它们将以有趣的方式中断。

根据更多的调查,我开始认为问题是内存损坏问题,而“仅从码头”症状只是一个误导。虽然在我的情况下它似乎不是问题,但当我试图想出可能性时,不同的工作目录肯定是我忽略的东西。感谢您的提示! - Josh Knauer

1
从 Dock 图标启动的应用程序不会获取与您正在使用的 shell 中可能设置的相同环境变量。如果您依赖于从环境中获取某些内容,则需要寻找其他方法。您将获得一些 env 变量,例如 PATH、HOME、LOGNAME 等等。但是,如果您正在寻找 HOSTTYPE、LANG、OSTYPE 等等,它们将不存在。

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

0
在类似的情况下,当从应用程序包中运行时,我遇到了崩溃。一个可能性是我们正在使用已经释放的内存。例如,在free()delete之后使用指针或类的字段。

看起来应用程序包与不同的free/delete实现动态链接,这些实现会将已释放的内存清零/修改。

这种错误可能不会在其他平台/编译器(例如Linux/gcc、Windows/Visual Studio、macOS/clang命令行)上出现,并且只有在从应用程序包(macOS/clang从Finder/dock)执行程序时才会出现。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接