STDIN/STDOUT/STDERR issues with namespace

Question

STDIN/STDOUT/STDERR issues with namespace

aewing opened this issue 10 years ago · comments

There is an inconsistency with the way that PHP and HHVM handle STDIN while inside of a namespace.

Currently, the following code would work in PHP but not in HHVM:

<?php
namespace Test;
class Test {
    public static function prompt($ask) {
        echo $ask . ' : ';
        return fgets(STDIN);
    }
}
Test::prompt('Testing');

However, if you access STDIN from the root namespace (\STDIN) in HHVM, it works.

Paul Bissonnette commented 10 years ago

👍

Drew · Answer 1 · Tue May 06 2014 13:37:35 GMT+0800 (China Standard Time)

I'm fairly certain this is the cause of issue #2234 and #2502

Carsten Brandt · Answer 2 · Tue May 06 2014 15:04:15 GMT+0800 (China Standard Time)

same issue is valid for STDERR and STDOUT as well, see yiisoft/yii2#3367 and yiisoft/yii2#2926

Drew · Answer 3 · Tue May 06 2014 15:11:54 GMT+0800 (China Standard Time)

@cebe I had noticed STDOUT, but I have also added STDERR to the title.

Michael Anderson · Answer 4 · Tue Jun 03 2014 03:39:13 GMT+0800 (China Standard Time)

Just so everyone can see this in action, it is happening to me as well:

https://www.dropbox.com/s/bd5zvjcyxn6awyu/Screenshot%202014-06-02%2014.38.48.png

Would love to see this get some love! Thanks :)

Hannes Van De Vreken · Answer 5 · Thu Jun 05 2014 21:21:53 GMT+0800 (China Standard Time)

+1. For now we can use cli options to not stop the execution to request stuff from the user.

James Miller · Answer 6 · Thu Jun 12 2014 07:56:06 GMT+0800 (China Standard Time)

I've got a patch in the works that should fix this.

Sebastian Krebs · Answer 7 · Tue Aug 05 2014 04:54:03 GMT+0800 (China Standard Time)

In the nightly

$hhvm --version                                                                                                                                                                             
HipHop VM 3.3.0-dev+2014.07.31 (rel)
Compiler: heads/master-0-gaf1ed367ff13ec0e72e5f0b9305f4474517b10da
Repo schema: ed145c75fc152c69b900d2fe5dd920eda542a002

it's still (or again) an issue. It happens to me with the DialogHelper from Symfony.

Sander Bol · Answer 8 · Wed Aug 20 2014 17:10:34 GMT+0800 (China Standard Time)

Just in case it helps, here's a reproducable case:

<?php
namespace Test;
var_dump(STDIN); // null in hhvm, resource in php5
var_dump(\STDIN); // resource in hhvm, resource in php5

Relevant PHP documentation:
http://php.net/manual/en/language.namespaces.fallback.php
"For functions and constants, PHP will fall back to global functions or constants if a namespaced function or constant does not exist."

This bug should be considered fairly important because anyone trying to use Symfony on HHVM will run into this as soon as they want to use the cli tools. Fabien Potencier indicated in symfony/symfony#11250 that the Symfony Project is not willing to change their code to accomodate this bug, so the fix will have to come from the HHVM side.

Fred Emmott · Answer 9 · Fri Aug 22 2014 01:21:47 GMT+0800 (China Standard Time)

Both of those test cases work fine in 3.2.0

@kander, yours actually seems fine in earlier versions too? http://3v4l.org/PNLcK

Antonio Ribeiro · Answer 10 · Mon Aug 25 2014 04:38:13 GMT+0800 (China Standard Time)

Not working for me in 3.2.0:

Source

 $ cat /tmp/t
<?php
namespace Test;
var_dump(STDIN); // null in hhvm, resource in php5
var_dump(\STDIN); // resource in hhvm, resource in php5

Executing

 $ hhvm /tmp/t
NULL
resource(1) of type (stream)

Version

 $ hhvm --version
HipHop VM 3.2.0 (rel)
Compiler: tags/HHVM-3.2.0-0-g01228273b8cf709aacbd3df1c51b1e690ecebac8
Repo schema: c52ba40f4a246d35a88f1dfc1daf959851ced8aa

Linux Kernel

uname -a
Linux titanis 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Linux Release

$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS"
NAME="Ubuntu"
VERSION="14.04.1 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.1 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

Sander Bol · Answer 11 · Tue Aug 26 2014 15:08:40 GMT+0800 (China Standard Time)

HI @fredemmott - the output from 3v4l does indeed look fine... however it does not match what I'm seeing locally. That leads me to believe there's an environment-specific issue at work here. I think it's too quick to just dismiss the issue as "can't reproduce" - let's instead work together and see what it takes to reproduce it?

My environment should be easily reproducable: it's a https://puphpet.com/ VM running on Virtualbox, with HHVM enabled. My puphpet config file is here: https://gist.github.com/kander/58bd00323e418cfe4274

Could you check if you can reproduce the issue in that environment?

Mark Penner · Answer 12 · Sun Sep 07 2014 12:43:13 GMT+0800 (China Standard Time)

👍 This breaks Laravel's artisan in v3.2.0, which is the latest stable version on Ubuntu 14.04.

Francois Zaninotto · Answer 13 · Wed Sep 10 2014 00:04:48 GMT+0800 (China Standard Time)

Same here, using composer with hhvm 3.2, the error is still here.

Fred Emmott · Answer 14 · Wed Sep 10 2014 00:47:10 GMT+0800 (China Standard Time)

Sorry, running a VM is too close to arbitrary code.

Can you try both of these:

[fredemmott@devbig076 ~] hhvm -v Eval.Jit=0 test.php
resource(1) of type (stream)
resource(1) of type (stream)
[fredemmott@devbig076 ~] hhvm -v Eval.Jit=1 test.php
resource(1) of type (stream)
hhvm: hphp/runtime/base/countable.h:80: assert_refcount_realistic: Assertion `count <= StaticValue || (uint32_t)count <= (uint32_t)RefCountMaxRealistic' failed.
Core dumped: Aborted
Aborted

You will only get that abort() in a debug build - there should be a debug package for your distribution. interestingly enough I still can't get NULL for the first one.

Fred Emmott · Answer 15 · Wed Sep 10 2014 00:47:27 GMT+0800 (China Standard Time)

Can you also try with a nightly package, and with a debug package of 3.2.0?

Drew · Answer 16 · Sun Sep 21 2014 09:14:02 GMT+0800 (China Standard Time)

Looks good for me now in 3.3 and 3.4 (nightly) (Nice work!)

dbg (3.2) still fails with the following:

$ hhvm test.php
Testing : hhvm: /tmp/tmp.NDtSUGa2KF/hphp/runtime/base/ref-data.h:139: int32_t HPHP::RefData::getRealCount() const: Assertion `m_cow == 0 || (m_cow == 1 && m_count >= 1)' failed.
Segmentation fault

Fred Emmott · Answer 17 · Sun Sep 21 2014 09:52:27 GMT+0800 (China Standard Time)

does that include the debug package of 3.3 or a debug nightly? Is so, I'll close this. We don't backport fixes to 3.2, so I wouldn't expect it to start working.

Antonio Ribeiro · Answer 18 · Sun Sep 21 2014 10:55:13 GMT+0800 (China Standard Time)

$ hhvm -v Eval.Jit=0 /tmp/test.php
resource(1) of type (stream)
resource(1) of type (stream)

$ hhvm -v Eval.Jit=1 /tmp/test.php
resource(1) of type (stream)
Core dumped: Segmentation fault
Segmentation fault (core dumped)

This is the my current HHVM version:

HipHop VM 3.3.0 (rel)
Compiler: tags/HHVM-3.3.0-0-g0a3cfb87b8a353fc7e1d15374f4adc413e37aba9
Repo schema: 9a391d9a03e15fccba1cde6d35c05b7cdd380238
Extension API: 20140829

Also tried nightly:

HipHop VM 3.4.0-dev+2014.09.20 (rel)
Compiler: heads/master-0-g850d4fddd26ee0c2a0022e390d6403ad9c4ecf79
Repo schema: 26d73686e172a637fde1298dc9c73a4bab227cde
Extension API: 20140829

So I have to disable Jit for good?

Fred Emmott · Answer 19 · Tue Sep 23 2014 01:33:25 GMT+0800 (China Standard Time)

Can still reproduce an assertion failure with this case:

<?php
namespace Test;
var_dump(STDIN);
var_dump(\STDIN);

Both are now streams, however:

[fredemmott@devbig076 ~] hhvm -v Eval.Jit=0 test.php
hhvm -vresource(1) of type (stream)
resource(1) of type (stream)
[fredemmott@devbig076 ~] hhvm -v Eval.Jit=1 test.php
resource(1) of type (stream)
hhvm: hphp/runtime/base/countable.h:80: assert_refcount_realistic: Assertion `count <= StaticValue || (uint32_t)count <= (uint32_t)RefCountMaxRealistic' failed.
Core dumped: Aborted
Aborted

Drew · Answer 20 · Tue Sep 23 2014 10:13:05 GMT+0800 (China Standard Time)

Not sure how this worked 2 days ago, it's failing again today.

EDIT: My example does seem to work -- using fgets(STDIN) inside of a namespace, also assigning STDIN to a variable ($stream = STDIN) works.

It seems that var_dump(\STDIN) in particular is causing the problem.
Assigning \STDIN to a variable ($stream = \STDIN) works

Drew · Answer 21 · Tue Sep 23 2014 10:22:24 GMT+0800 (China Standard Time)

To clarify the following will not result in an assertion:

<?php
namespace Test;
$stream = STDIN;
var_dump($stream);
$stream = \STDIN;
var_dump($stream);

Nor this:

<?php
var_dump(\STDIN);

But this will:

<?php
namespace Test;
var_dump(\STDIN);

Antonio Ribeiro · Answer 22 · Thu Oct 23 2014 18:29:16 GMT+0800 (China Standard Time)

Just to confirm that this is fixed on Nightly:

HipHop VM 3.4.0-dev~nightly.2014.10.23 (rel)

For

<?php

namespace Test;

$stream = STDIN;
var_dump($stream);

$stream = \STDIN;
var_dump($stream);

var_dump(STDIN);

var_dump(\STDIN);

I got:

resource(1) of type (stream)
resource(1) of type (stream)
resource(1) of type (stream)
resource(1) of type (stream)