Not our bug, but we've got to find a way around this..

https://bugs.php.net/bug.php?id=58084

The automated testers online are running an older vesion of APC so they're fine - but the tests must be rewritten moving forward since this bug has been marked "won't fix" by the PHP team.

CommentFileSizeAuthor
#5 2468949.5.patch749 bytesalexpott
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented
Priority: Critical » Major

So per IRC, @Aki Tendo is seeing lots of fails in the test: Drupal\system\Tests\Cache\ApcuBackendUnitTest.

I wasn't able to reproduce this. If others can reproduce it, I think this issue is at most major, as per:
https://www.drupal.org/core/issue-priority#major-bugs

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented

I can't reproduce this with PHP 5.6 and APCu Version 4.0.6 - what versions of everything are you testing on @Aki Tendo?

Aki Tendo’s picture

Aki Tendo CreditAttribution: Aki Tendo commented

The bug appeared in the vdd vm running PHP 5.4.23. I don't think the inbuilt APC of PHP 5.5 is affected. The online testbots certainly are not. I'll track down the exact version numbers this evening after work.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented

Also @Aki Tendo it would be helpfully to have output of how they fail. The bots are on PHP 5.4.39-1~dotdeb.1 and the APC version is 3.1.13 - we've got evidence that at least the issue title is misleading.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Status: Active » Needs review
FileSize
2468949.5.patch749 bytes

That said the code in ApcuBackend::invalidateMultiple and ApcuBackend::invalidateAll because that's going to be setting the ttl to exceedly high numbers...

Personally I don't think we should be using $expire in ApcuBackend::set() - that looks to be completely bogus. In the invalidate code we'll be setting the ttl to REQUEST_TIME - 1?!?!?! wut.

olli’s picture

olli CreditAttribution: olli commented

#5 sounds like #2272685: Incorrect handling of invalid cache items in apcu backend.

Aki Tendo’s picture

Aki Tendo CreditAttribution: Aki Tendo commented

Tests fail on my Virtual box running

PHPv 5.5.23-1+deb.sury.org~precise+2

apcu
Version 	4.0.6
APCu Debugging 	Disabled
MMAP Support 	Enabled
MMAP File Mask 	/tmp/apc.rlS5hi
Serialization Support 	php
Revision 	$Revision: 328290 $
Build Date 	Jul 2 2014 13:40:51

The bug in the issue summary is the underlying cause - if you set any TTL argument in the apc_store function the variable will *not* visible until the next request. Hence the test's attempt to store then immediately check will always fail (interestingly if no TTL argument is given the value can be immediately retrieved). Tests of this functionality will have to be written in two passes, a store pass on one PHP request, then a retrieve pass.

As mentioned in the summary the bug was marked "won't fix" so rewriting the test in the manner detailed above is likely the only option.

The version number in the title cites the version number cited in the PHP issue bug - if that is wrong my apologies. Also, it's possible the bug was introduced at a different version for APCu

I use the term 'bug' loosely here. My understanding from what research I've done is the PHP team deliberately introduced this as a consequence of an optimization, so again it's a feature that can't be fixed.

The specific test I got to fail (among others) was Drupal\system\Tests\Cache\ApcuBackendUnitTest The strict PHPUnit tests appear to be fine for some reason, so perhaps its a Simpletest issue?

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford at OpenConcept Consulting Inc. commented
Status: Needs review » Needs work

Needs re-roll.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Status: Needs work » Closed (cannot reproduce)