Fix bug GH-11246 cli/get_set_process_title initialisation failure on MacOS

[lucasnetau]

Fixes #11246, when executing on MacOS it was found that the environ area my not be contiguous.

Checking the original Postgres implementation https://github.com/postgres/postgres/blob/master/src/backend/utils/misc/ps_status.c the PHP code fails if either argv or environ is non-contiguous whereas the original code only fails if argv is ever non-contiguous.

Additionally the end_of_area variable is changed even if we hit a non-contiguous environ section, another divergence from the original code

[lucasnetau]

A separate patch is needed to apply to PHP8.2 and master due to commit b468d6f which change int to bool and inverted some logic with a variable rename. If this PR is accepted should I raise a second one against PHP8.2?

[lucasnetau]

@Girgias do you have any idea why MACOS_DEBUG_NTS is failing? I cannot replicate locally, however I am building on macOS 13, whereas CI is using macOS 11

[Girgias]

Sorry I don't, and I don't have access to a MacOS machine. Maybe @bwoebi knows as IIRC they have access to such a machine.

[lucasnetau]

Issue found using ASAN in the runner. I've pushed a commit to this PR and #11273

[lucasnetau]

@Girgias could you please approve the workflow again (and for PR #11273) ? I'm not sure who to add as a reviewer for CLI, no one listed under Code Owners

[lucasnetau]

WINDOWS_X64_NTS failed with a transient network issue

fatal: unable to access 'https://github.com/php/php-sdk-binary-tools.git/': Failed to connect to github.com port 443 after 21079 ms: Couldn't connect to server

[iluuu1994]

Please verify if my understanding is correct.

environ points to the strings after argv, and should be contiguous at the start of the program if the environment hasn't been modified yet, or new environment variables were added. We assume string that aren't contiguous don't belong to the initial environment strings and may not be used for the process title (ps_buffer_size). So it seems the space for the title on macOS might be slightly limited, but by how much is not clear without testing.

It also seems that the strdup below for strings that aren't part of ps_buffer_size is useless because it may not be written over by set_process_title, but we shouldn't change that in a patch.

Your patch looks good to me. It would be interesting to know why the environment strings are non-contiguous on macOS, and whether these strings live somewhere else or whether there's some empty space between environment strings. I'll test this later today on my MacBook.

[lucasnetau]

@iluuu1994, I tried to find out before but came up with nothing when building my own small c program, your comment made me go back and take a look with some debugging in the php-src, here is what I found:

On macOS when the environ is non-contiguous there is an additional variable seen injected after the expected last _ variable when executing from a bash prompt, that variable being __CF_USER_TEXT_ENCODING.

Going through the Apple technote (https://developer.apple.com/library/archive/technotes/tn2228/_index.html) __CF_USER_TEXT_ENCODING is being injected by Core Foundation. It only appears when linked against that with -framework CoreServices

0x7ff7b6351ed0: _=sapi/cli/php
**NCONTIG** 0x6040000012d0: __CF_USER_TEXT_ENCODING=0x1F5:0:15

So the risk of limited space appears to be no less than any other platform.

A quick reproduction that needs to be compiled with -framework CoreServices flag

#include <unistd.h>
#include <stdio.h>
#include <string.h>

extern char **environ;

int main(int argc, char *argv[])
{
        char* end_of_area = NULL;
        int non_contiguous_area = 0;
        int i;

        /*
         * check for contiguous argv strings
         */
        for (i = 0; (non_contiguous_area == 0) && (i < argc); i++)
        {
            if (i != 0 && end_of_area + 1 != argv[i])
                non_contiguous_area = 1;
            end_of_area = argv[i] + strlen(argv[i]);
        }

        for (i = 0; environ[i] != NULL; i++)
        {
            
            if (end_of_area + 1 == environ[i]) {
            	end_of_area = environ[i] + strlen(environ[i]);
                printf("%p: %s\n", environ[i], environ[i]);
            } else {
                printf("**NCONTIG** %p: %s\n", environ[i], environ[i]);
            }
        }

}

[iluuu1994]

@lucasnetau Thanks for the explanation! This looks good to me then, thanks for the patch!