As far as I know, this is the last of two issues we're encountering on a rather large Drupal 7 site running on HHVM (Facebook's Hip-Hop VM). There are two strange issues that were traced back to the line print eval('?>' . $code); which exists in the php.module file in the php_eval function as well as the rules_php_eval function of rules/modules/php.eval.inc (I'll post a related issue for rules later).

The issue manifested as the number 1 being printed after custom blocks that contained PHP code. Even though we're not explicitly calling "return" in the PHP code of the custom blocks, HHVM still seems to think we are. Perhaps the block module is doing that. Not sure. But, it seems like something is returning true, which HHVM is evaluating as a 1 and getting printed after the code that was evaluated since eval is called with the print statement.

To fix it, I simple changed:
print eval('?>' . $code);
To this:
eval('?>' . $code);

So, my question is, why is "print" being used there? It seems to just print the return value of eval if the code being evaluated returns anything. Based on the php docs for eval:

eval() returns NULL unless return is called in the evaluated code, in which case the value passed to return is returned. If there is a parse error in the evaluated code, eval() returns FALSE and execution of the following code continues normally. It is not possible to catch a parse error in eval() using set_error_handler().

What are the implications of this change? I realize this may be an issue that needs to be logged with the HHVM team, but just wanted to post here first to see if there is a scenario in which the absence of the print statement could cause an issue.

Comments

dcarrith’s picture

Issue summary: View changes
dcarrith’s picture

Issue summary: View changes
dcarrith’s picture

It looks like this might be acknowledged as an HHVM issue. https://github.com/facebook/hhvm/issues/2023

However, I still wonder if the "print" is required above.

yaslama’s picture

The issue was closed in hhvm by this commit.

dcam’s picture

Version: 7.26 » 7.x-dev
Status: Active » Fixed
Issue tags: -drupal 7, -php.module, -php_eval, -eval, -hhvm

It sounds like this was fixed in HHVM. Feel free to re-open the issue if I'm mistaken.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.