Fatal error: Cannot use lexical variable $value as a parameter name in components/select.inc on line 765

Thanks for the patch - now that PHP 7.1 is GA it's important we fix the glitches with it, especially as the backward-incompatible changes are mainly errors on previously allowed back practice.

I tried your patch against 7.x-4.14. All seems to work fine - but site loads fine, and I get nothing in the dblog or PHP error_log file.

But, if I run "drush cc all" on the site I get "Floating point exception". I don't get that if I clear caches within the Drupal UI. I'm afraid I can't at this point pin it down more precisely, except to say that it doesn't happen without this patch, so it's an inadvertent side-effect of patching. Unfortunately, the error gives me no line numbers or other details to track it down further.

The patch is a big improvement - it fixes the WSOD you otherwise get with Webform and PHP 7.1. Maybe the Drush error is just a harmless annoyance. Nevertheless, unless the maintainers decide otherwise, it's probably the kind of thing we ought to track down before committing it.

I can confirm that this is a fatal/WSOD for PHP 7.1 and that the fix works. I was not able to replicate the drush cc bug that JamesOakley experienced; I am thinking (hoping) that was an oddity. Even if it wasn't that is a much less urgent issue than a total WSOD for any sites on PHP 7.1.

Even if it wasn't that is a much less urgent issue than a total WSOD for any sites on PHP 7.1.

Yes: +1

That floating point error is a funny one; the reason it leaves no trace in the logs is that it's more a bug with PHP itself than with the code that PHP is trying to run (I think ...?). It may be caused by something in Drush rather than in Webform, or it could be a one-off.

Either way, it was just noise - it didn't stop anything running. And, as you say, fixing a WSOD is more of a priority than silencing some noise - we can have a separate issue for that once it's been replicated and its cause identified.

Confirm path works.

Thanks!

The patch provided above eliminates the fatal error but then I get error 502, bad gateway. I am using PHP 7.1 and Nginx. I have to disable webform module totally to access my site.

The patch provided above eliminates the fatal error but then I get error 502, bad gateway. I am using PHP 7.1 and Nginx. I have to disable webform module totally to access my site.

Can you try PHP 7.0 instead of 7.1 (with or without the patch)?

@JamesOakley

As to PHP 7.0 without patch everything was working fine.. I have not tested PHP 7.0 with patch.. Currently I have no test machine to test back on PHP 7.0.

I can confirm that 7.x-4.x-dev (2016-Dec-23) silently dies and website returns ERR_EMPTY_RESPONSE.
drush cc all proceeds successfully.

I have 502 Bad Gateway as well. Environment: PHP 7.1, Nginx and Webform 7.x-4.x-dev (2016-Dec-23)

Can this be marked as Active or Needs work?

There are some serious issues that are associated with the suggested patch. Applying the patch makes the whole site not accessible with HTTP error code 502, bad gateway (PHP 7.1, Nginx).

IMPORTANT.. Please keep in mind the possibility that the original issue can be related actually to some PHP 7.1 bug. If so the issue needs to be reported to the PHP development team.

UPDATE:

This issue is not to related to any bug in PHP 7.1, this is the expected behavior.

Fatal error: Cannot use lexical variable $value as a parameter name in components/select.inc on line 765

Will be thrown under PHP 7.1, further information will be uploaded by the PHP team to the Backward incompatible changes for PHP 7.1 page at php.net in near future..

The puzzling thing is that the above patch or even another solution that does not rely on arraywalk() result in Nginx's 502 bad gateway error..

Today I downgraded server's PHP version to 7.0.14 and module works as expected without errors. So this issue is only on PHP 7.1.

If someone could only verify that the patch above works under Apache web server without any issues? Maybe it's Nginx specific..

My setup is Apache 2.4.6, MariaDB 10.2.3 and PHP 7.1.0. Without patch it returned HTTP error 500, but with patch it silently died as in comment #14. Then I downgraded PHP to 7.0.14 and it works with Webform 7.x-4.14 (2016-Aug-28).

@NullIsNot0 ..

Running the relevant code of _webform_action_set_select with the above suggested patch (and with another workarounds) in isolated PHP 7.1 script does not return any errors .. However, under normal Drupal environment it causes bad gateway error 502 or no response (as under apache)..

For now, I downgraded to PHP 7.0.14 .. Still possibility that this is a PHP 7.1 issue and/or in interaction with some yet to be discovered Drupal 7 incompatibility issue with PHP 7.1

Note: the floating point exception actually occurs in the Apache log, and it is what is causing ERR_EMPTY_RESPONSE for me (which would cause a 502 Bad Gateway in a proxy setup).

Error example: [Tue Jan 03 16:27:09.840648 2017] [core:notice] [pid 1501] AH00051: child pid 5847 exit signal Floating point exception (8), possible coredump in /etc/apache2

Since there is no corresponding PHP error to trace, this will be tricky to Xdebug, but I have to get this working, so I will try. (Also just going to google the floating point thing first though.)

Removing extraneous tags.

Found this. Not sure how it applies yet, but seems related. I am also using PHP-FPM (as nginx people most likely would be doing): https://github.com/Microsoft/msphpsql/issues/141

Ah, wait. My VM is using mod_php, and it still happens. Seems both can crash the web server, just where the error is shown changes a bit.

I turned off OpCache to get a clearer backtrace while trying to debug this via GDB, but now it's not happening. So it's actually something about having OpCache enabled. Maybe there's an OpCache configuration setting that would fix this, as I don't really want to turn it off entirely. Now I have something new to google, at least.

...OK, seems to be this! https://bugs.php.net/bug.php?id=73668

I'm not sure why we would be dividing by 1, but the GDB backtrace led me to this.

So, there is apparently some division or something happening somewhere. Here is a link to my trace in case anyone wants to dig deeper: https://gist.github.com/wizonesolutions/bd3ff7ca15d716de3752ae0813a52eb6

I'm going to try to isolate where Webform might be dividing by -1 somewhere.

This crash seems to happen even before Drupal's index.php is run. None of my breakpoints are catching.

I think at this point, downgrading to PHP 7.0 is the best idea. I'm not sure how to go deeper.

Let's re-try this when the next version of PHP 7.1 comes out.

Updating issue summary with sub-issue.

Disabling Webform does stop the issue, meaning that Drupal is in the mix somehow. But it isn't clear to me what magic combination of actions form the steps to reproduce or why disabling Webform somehow stops the issue.

When the issue is occurring, I can't even set a breakpoint on

define('DRUPAL_ROOT', getcwd());

in /index.php

Gonna try again, as this is driving me crazy.

This also happens in the commit (9e5c80f) right after the patch had been committed. I thought it might have been something else, but that is apparently not the case. I suspect that the issue prior to this patch was simply obscuring the issue, and that it isn't this patch that caused it.

I am somewhat tempted to re-mark this as Fixed, as there is nothing we can do about it here (as far as I can see). @Liam Morland, what do you think?

Sounds good to me. I don't have a PHP 7.1 environment at the moment, so I can't test.

Update

In fact, there is a bug in opcache in PHP 7.1.0 that causes the unrelated issue discussed above. The fix has already been committed to PHP 7.1.x master and will be available in the next release PHP 7.1.1. Indeed, the 502 bad gateway error is not related to the patch above.

PHP 7.1 bug number 73847

It doesn't appear to be a bug but rather a feature: https://github.com/php/php-src/commit/eb25e1496277079423bdf2dee5aa4133c4...

PHP 7.1.1 confirm that the patch in #3 works for me.

@#39 The patch has been committed. Running the latest development version should work.

Confirm as well: PHP 7.1.1 the patch in #3 works for me. Can we get this committed? RTBC +1

It already has been in commit 9e5c80f.

Patch that applies against 4.10 for those not running the latest version.

Patch #3 works for me in PHP 7.1.1.

Just wanted to confirm patch #3 works for me as well on PHP 7.1.2. Is this RTBC?

>> Is this RTBC?

No, it was committed on 4th January, and is now "Closed (fixed)"

I re-rolled this for 7.x-4.14 because I could not get #3 to apply in my install profile.

The patch #47 works for me. Thank you

The patch #47 works for me. Thank you

Doh: That moment when you add a related issue, but by mistake link back to the issue you're posting in.

Yep patch #47 worked for me also. Thx

Patch #47 works for me. Are there plans to commit this patch to the project anytime soon?

@droath - the patch is committed (it's in -dev), so we're just waiting on the next point release. See the related issue.

#3 works for me too

@everyone

We really don't need lots of people saying that a patch works.

Just use 7.x-4.15. It includes the fix for this, which was committed long ago.

If you use 7.x-4.15 and still have the problem, please then post back here, or start a new issue if it might be a different problem.

Yes, after updating Webform module from 7.x-4.14 to 7.x-4.16 error got fixed.

Thanks.

Gracias los dos formas funcionas tanto la solución de Actualización, como las opciones #47 #43

Thanks the two ways you work both the Update solution, and the options # 47 # 43

@owenshidori: I realise I'm repeating myself (#56), but just use the latest version of Webform and the solution is included. No patches are required

Patch #47 works for me. Thank you!

This has already been committed. You should not require a patch. If you are running the latest version and are still having a problem, please open a child ticket.

Path #47 works for me. Thank you!

What version of webform are you using? This problem has been fixed since version 7.x-4.15. If you are using that version or later, you should not use the patch.

same issue i faced when i changed php to php 7.2 on drupal 7

i made following changes on select.inc on webform module

array_walk($checkbox_values, function(&$value, $key) use($value) {
$value = (int)(strval($key) === $value);
});

to

array_walk($checkbox_values, function(&$option_value, $key) use($value) {
$option_value = (int)(strval($key) === $value);
});

and it worked

Please try the latest version. If you are still having this problem, please open a child ticket.

Works fine with the latest version

@mdmanouwer

Thanks you very much. It worked like a charm.

Patch #47 works for me to resolve the error. Thank you.

Sivaprasad - you shouldn't be using an outdated version of webform. You must be at least 5 versions behind the latest to need to patch to fix this.

Rerolled against 7.x-4.x-dev from git. the two spaces actually matter to fix this issue for me.