¿Cuál es la diferencia entre el comienzo de un proceso desde el muelle frente a la línea de comandos en OS X

Question

Estoy depurar un problema en OS X que sólo se produce cuando la aplicación se inicia desde el muelle. Esto no sucede cuando la aplicación se inicia desde la línea de comandos. ¿Cuál es la diferencia entre los dos escenarios? El código que estoy trabajando es un paquete basado en C ++ plug-in de ser cargado en una aplicación de terceros. Me he adjuntado al proceso con el BGF en ambos escenarios y la única diferencia que puedo ver es que un par de dylibs adicionales se cargan en el proceso cuando se ejecuta desde la línea de comandos y que la dirección base de mi biblioteca es ligeramente diferente en el dos escenarios. He intentado cambiar mi vinculación con -prebind y / o -bind_at_load en vano.

Answer 1

Una diferencia importante es que el directorio de trabajo inicial será diferente en cada caso. Las aplicaciones no deben hacer ninguna suposición sobre el directorio de trabajo y se rompen de manera interesante si lo hacen.

Answer 2

Una aplicación lanzada desde el icono del Dock no va a recoger a las mismas variables de entorno que se pueden establecer en la cáscara que está utilizando. Si confía en recoger algo del entorno, tendrá que buscar un enfoque diferente. Usted obtendrá algunos de los env vars, como PATH, CASA, LOGNAME, etc, pero si usted está buscando HOSTTYPE, LANG, OSTYPE, y otros, no van a estar presentes.

Answer 3

En este caso, mi problema fue causado por una diferencia en el orden en que se cargan las bibliotecas compartidas. Una de las bibliotecas de terceros que nuestra aplicación utiliza las bibliotecas de extensión cargas en un espacio de nombres global. Había símbolo conflictos con una versión diferente de la misma biblioteca. El orden en que las bibliotecas de extensión se cargan en el conjunto global cambia en función de si la aplicación se inicia desde el doc o desde la línea de comandos.

Answer 4

En una situación similar, tengo un accidente cuando se ejecuta desde el paquete de aplicación. Una posibilidad es que estamos utilizando la memoria que ya hemos desasignado. P.ej. utilizando un puntero o un campo de una clase después de free() o delete.

Parece que los paquetes de aplicaciones están muy relacionados entre sí con una aplicación diferente, que free/delete ceros / modificar la memoria desasignado.

Este tipo de error puede no aparecer el uso de otras plataformas / compiladores (por ejemplo, Linux / gcc, ventanas / Visual Studio, MacOS / ruido metálico de la línea de comandos) y sólo aparece cuando el programa se ejecuta desde un paquete de aplicación (MacOS / clang de Buscador / muelle).