¿Por qué es sysctl la producción de E_INVAL en Mac OS X?

Question

A continuación es una depurada (error/null cheques omitido) fragmento de C/Obj-C código que utiliza sysctl para obtener la argv de un determinado proceso con PID 50.

...
int getProcessArgs[3] = { CTL_KERN, KERN_PROCARGS, 50 };
sysctl(getProcessArgs, 3, NULL, &length, NULL, 0);
char* processArgs = malloc(length * sizeof(char));
sysctl(getProcessArgs, 3, processArgs, &length, NULL, 0);
...

La primera llamada a sysctl (para determinar el tamaño de la matriz de tipo string argv) se realiza correctamente.Devuelve la longitud es de ~1600, más grande de lo que yo esperaba, pero supongo que no es irrazonable.Malloc se realiza correctamente.La segunda llamada a sysctl devuelve -1, asignando un valor a errno a 22, E_INVAL.

He mirado en otro código, incluida la de esta pregunta, pero no puede ver el problema con la mía.Lo que me estoy perdiendo?

Answer 1

Traté de envolver el código en un programa, y funciona bien y se imprime el otro proceso del argv etc al indagar acerca de uno de mis propios procesos, es decir, uno con el mismo uid como el proceso de invocación sysctl().

El "más grande de lo que yo esperaba" aspecto es debido a que el proceso de la variables de entorno son devueltas, así como los argumentos de línea de comandos.(No es obvio lo que el formato de toda esta información.)

Al indagar sobre un diferentes usuario del proceso, tengo la misma EINVAL a partir de la segunda sysctl que he estado viendo.Supongo que esto se considera irrazonable curiosidad acerca de otras personas, procesos, pero se podría pensar que la primera sysctl iba a fallar también.

(Al indagar sobre un inexistente pid, el primer sysctl falla con EINVAL.)

Todo esto parece ser masivamente underdocumented:en Leopard, KERN_PROCARGS ni siquiera aparece en la sysctl el hombre de la página.