Handle the case when python is loaded by ld.so

[jia-kai]

When python is loaded by ld.so, python executable would not be the actual argv[0] in /proc/self/cmdline . This can be illustrated as:

SPT_DEBUG=1 /lib64/ld-linux-x86-64.so.2  $(which python3) -c 'import setproctitle, os; setproctitle.setproctitle("haha"); os.system("ps -o args --pid {}".format(os.getpid())); '

which outputs

[SPT]: module init
[SPT]: reading argc/argv from Python main
[SPT]: found 3 arguments
[SPT]: walking from environ to look for the arguments
[SPT]: found environ at 0x7ffd3dbdf3da
[SPT]: found argv[2] at 0x7ffd3dbdf367: import setproctitle, os; setproctitle.setproctitle("haha"); os.system("ps -o args --pid {}".format(os.getpid())); 
[SPT]: found argv[1] at 0x7ffd3dbdf364: -c
[SPT]: argv[0] should be at 0x7ffd3dbdf353
[SPT]: found argv[0]: /usr/bin/python3
COMMAND
/lib64/ld-linux-x86-64.so.2 haha  

I could not find a portable way to handle this, and currently only come up with a solution of adding two environment vars: SPT_ARGC_DELTA and SPT_ARGV0. In the above example, setting SPT_ARGC_DELTA=1 SPT_ARGV0=/lib64/ld-linux-x86-64.so.2 would produce desired output.

The patch is at master...jia-kai:master . If you think it is adequate, I can send a PR.

[dvarrazzo]

Specifying the entire fully qualified ld.so executable in an env var seems brittle, and having to specify two env var to make everything work doesn't seem nice either.

[jia-kai]

These two env vars is not a problem and they can be merged into one with a little parsing code. I agree that this method is brittle, and it may segfault if wrong env vars are passed, so I think this patch is not yet qualified to be merged. Do you have any idea for a more robust solution ?

[dvarrazzo]

A more robust solution would be probably to read /proc/self/cmdline and use it as a reference to walk backwards from environ.