This library does not work when invoking a Phar via a relative path

[TysonAndre]

When the phar is invoked manually (e.g. php -d zend_extension=xdebug.so build/phan.phar), xdebug-handler fails to detect that the file exists.

Adding debugging statements, I see that the Phar path (i.e. $args[0]) gets replaced by '--' (EDIT: Because it fails to detect that the file exists, xdebug-handler attempts to pass the phar (I assume) over stdin, which doesn't work. That causes the phar to hang after the restart, with no output)

Patching getCommand() to use the following check would make it not replace the relative path with --: if (!file_exists($args[0]) && !file_exists(getcwd() . '/' . $args[0])) {

• Obviously, you'd have to check if something is an absolute path, the above snippet is not what you'd really want to use. Something more like the below would make sense. I'm not sure if that's 100% correct -- You may wish to limit this to Phars only for now via https://secure.php.net/manual/en/phar.running.php (Feel free to use the below helper)

    public static function absScriptPath(string $relative_path)
    {   
        // Make sure its actually relative
        if (\DIRECTORY_SEPARATOR === \substr($relative_path, 0, 1)) {
            return $relative_path;
        }
        // Check for absolute path in windows, e.g. C:\ (https://en.wikipedia.org/wiki/Drive_letter_assignment)
        if (\DIRECTORY_SEPARATOR === "\\" &&
                \strlen($relative_path) > 3 &&
                \ctype_alpha($relative_path[0]) &&
                $relative_path[1] === ':' &&
                \strspn($relative_path, '/\\', 2, 1)) {
            return $relative_path;
        }

        return getcwd() . DIRECTORY_SEPARATOR . $relative_path;
    } 

https://stackoverflow.com/a/18378785 sounds like it describes the generic problem for Phars:

Working with file paths and Phar archives in PHP can be tricky. The PHP code inside of a Phar file will treat relative paths as being relative to the Phar archive, not relative to the current working directory.

---

My use case is building phars for https://github.com/phan/phan/releases

[weirdan]

That -- replacement is only needed when reading code from stdin, and there are alternative ways to detect this situation (check $argv[0] for a known fixed string, for example, like it was done in the original PR 😄 ).

[TysonAndre]

That -- replacement is only needed when reading code from stdin

Other things to mention:

• The phar file exists at that relative path. Despite the path existing, xdebug-handler is attempting to read code from stdin, which is part of the bug I mentioned. The -- replacement is a symptom of that bug.
• The restart handler is hanging when trying to write the code from stdin. (I'm not sure if PHP allows you to pass a Phar file to stdin. The equivalent would be php < path/to/my.phar, which gives a fatal error)

[johnstevenson]

Curious, I cannot reproduce this using a composer.phar (with a dev version of xdebug-handler that outputs debug messages if XDEBUG_HANDLER_OUTPUT=1 https://github.com/johnstevenson/xdebug-handler/tree/debug-output)

$ php composer/composer.phar --version
Checking COMPOSER_ALLOW_XDEBUG
The xdebug extension is loaded (2.5.0)
Process restarting (COMPOSER_ALLOW_XDEBUG=internal|2.5.0|0)
Running C:\php-7.1.1\php.exe -c C:\Users\John\AppData\Local\Temp\DA84.tmp composer/composer.phar --version
Checking COMPOSER_ALLOW_XDEBUG
Restarted (102 ms). The xdebug extension is not loaded
Composer version 1.7-dev (f741dcb764e8bcfae0f71066d7400b25873b52eb) 2018-03-11 10:39:40
Restarted process exited: 0

So what am I missing? Are you using an auto_prepend file?

[TysonAndre]

You can see the script the affected project uses to generate the Phar at https://github.com/phan/phan/blob/master/internal/package.php. It has several customizations).

The stub that is being generated can be seen below (or at https://github.com/phan/phan/releases/tag/0.12.3):

The phar creation script for phan is invoking Phar->createDefaultStub(). It seems like composer.phar uses a completely different stub.

And https://secure.php.net/manual/en/phar.interceptfilefuncs.php is being invoked by the phar file because of that default stub. I haven't looked into disabling that invocation (It has more drawbacks then benefits in my use case). https://secure.php.net/manual/en/phar.createdefaultstub.php

The loader stub (from createDefaultStub()) also calls Phar::interceptFileFuncs() to allow easy bundling of a PHP application that accesses the file system.

#!/usr/bin/env php
<?php

$web = 'index.php';

if (in_array('phar', stream_get_wrappers()) && class_exists('Phar', 0)) {
Phar::interceptFileFuncs();
set_include_path('phar://' . __FILE__ . PATH_SEPARATOR . get_include_path());
Phar::webPhar(null, $web);
include 'phar://' . __FILE__ . '/' . Extract_Phar::START;
return;
}

[TysonAndre]

To summarize: This only affects phar files that call https://secure.php.net/manual/en/phar.interceptfilefuncs.php

• xdebug-handler should work even if Phar::interceptFileFuncs gets called, though? Or emit an error (A quick search didn't reveal a standard way to detect interceptFileFuncs)

The Phar creation script I used was probably adapted from a different project's phar creation script without closely looking at it. I can probably get rid of the setStub entirely.

[johnstevenson]

Thanks for the extra info. I'll have a play.

[TysonAndre]

https://github.com/composer/composer/blob/c8aea719b145ca78a79a60913db5c312883e8ace/src/Composer/Compiler.php#L242-L281

Actually, composer is the exception here, so I'd expect everything except composer to have the same issue. Composer is using a stub that's completely separate from the default stub.

[weirdan]

The phar file exists at that relative path. Despite the path existing,

This shouldn't matter, as xdebug-handler should not be checking its existence at all. It should just pass all arguments as unchanged as they could be to the child process, with one exception: when PHP is started to interpret the code from STDIN it sets $argv[0] = "Standard input code". This (or 'php://stdin' in older versions) should be either removed or (preferrably) replaced with '--'.

xdebug-handler is attempting to read code from stdin, which is part of the bug I mentioned.

Not really. xdebug-handler does not read anything from stdin, it just starts another PHP process (which may read code from stdin, if it doesn't get a filename).

The -- replacement is a symptom of that bug.

It's not the symptom, it's the exact cause of the bug. It's that replacement that makes child process attempt to execute stdin (because it doesn't get the filename, which was replaced by '--').

[johnstevenson]

I can now reproduce the problem in 0.12.3 (having removed the work-around in codebase.php). Phar::interceptFileFuncs seems to be the culprit, because if I remove it from the default stub when compiling, everything works:

// package.php

$phar->buildFromIterator($iterator, $dir);
//$phar->setStub("#!/usr/bin/env php\n" . $phar->createDefaultStub('src/phan.php'));
$stub = $phar->createDefaultStub('src/phan.php');
$stub = str_replace('Phar::interceptFileFuncs();', '', $stub);
$phar->setStub("#!/usr/bin/env php\n" . $stub);

Incidentally, in your work-around you could use Phar::running(false) instead, which returns "the full path on disk to the phar archive". I've only tested this on Windows but it works with and without Phar::interceptFileFuncs. Of course this might not be pertinent as I see you have been making changes to the phar building process.

Anyway, there is obviously a bug in xdebug-handler, because chdir would also cause this error, so I need to fix this and perhaps also provide a mechanism for the script path to be set.

[TysonAndre]

Of course this might not be pertinent as I see you have been making changes to the phar building process.

I fixed it (just for that repo, on the master branch) already by overriding the default stub with a replacement that didn't call interceptFileFuncs.

[johnstevenson]

Cool. My fix will also handle Phar::interceptFileFuncs discrepancies.