View block in page variant causes recursive cache fetch loop

I have this bug too when adding a view block to the page variant. I updated the title to be more specific. I have this problem only with the following module set.

page_manager 8.x-1.0-alpha23+13-dev
panels 8.x-3.0-beta4+45-dev
ctools 8.x-3.0-alpha26+4-dev

page_manager dev needs ctools dev and panels dev because of various functionality and bug fixes. The page variant is a panel variant type so we can use custom layouts.
This bug is quite a blocker for using page_manager with views.

The page variant keeps running the functions jotted down below. Turning opcache off does nothing but turning APC OFF does help "fix" it. But turning apc off is not an option. We run PHP 5.6 on Centos 7

134	2.0384	25930480	 apcu_fetch ( )	.../ApcuBackend.php:88
135	2.0385	26015208 Drupal\views\ViewExecutable->unserialize( )	.../ApcuBackend.php:88
136	2.0398	26043640	 Drupal\views\ViewExecutable->initHandlers( )	.../ViewExecutable.php:2507
137	2.0398	26044608	 Drupal\views\ViewExecutable->_initHandler( )	.../ViewExecutable.php:888
138	2.0398	26044608	 Drupal\views\Plugin\views\display\DisplayPluginBase->getHandlers( )	.../ViewExecutable.php:1030
139	2.0400	26053520	 Drupal\node\Plugin\views\field\Path->init( )	.../DisplayPluginBase.php:888
140	2.0400	26053520 Drupal\views\Plugin\views\field\FieldPluginBase->init( )	.../Path.php:24
141	2.0400	26053520	 Drupal\views\Plugin\views\HandlerBase->init( )	.../FieldPluginBase.php:108
142	2.0400	26053520	 Drupal\views\Plugin\views\PluginBase->init( )	.../HandlerBase.php:102
143	2.0400	26053656	 Drupal\node\Plugin\views\field\Path->defineOptions( )	.../PluginBase.php:138
144	2.0400	26053656	 Drupal\views\Plugin\views\field\FieldPluginBase->defineOptions( )	.../Path.php:33
145	2.0400	26056968	 Drupal\views\ViewExecutable->getStyle( )	.../FieldPluginBase.php:419
146	2.0400	26056968	 Drupal\views\ViewExecutable->initStyle( )	.../ViewExecutable.php:852
147	2.0400	26057016	 Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin( )	.../ViewExecutable.php:872
148	2.0402	26059768	 Drupal\views\Plugin\views\style\StylePluginBase->init( )	.../DisplayPluginBase.php:813
149	2.0403	26060568	 Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin( )	.../StylePluginBase.php:122
150	2.0403	26060568	 Drupal\Component\Plugin\PluginManagerBase->createInstance( )	.../DisplayPluginBase.php:810
151	2.0403	26060704	 Drupal\Core\Plugin\Factory\ContainerFactory->createInstance( )	.../PluginManagerBase.php:84
152	2.0404	26060704	 Drupal\Core\Plugin\DefaultPluginManager->getDefinition( )	.../ContainerFactory.php:16
153	2.0404	26060752	 Drupal\Core\Plugin\DefaultPluginManager->getDefinitions( )	.../DiscoveryCachedTrait.php:22
154	2.0404	26060752	 Drupal\Core\Plugin\DefaultPluginManager->getCachedDefinitions( )	.../DefaultPluginManager.php:172
155	2.0404	26060752	 Drupal\Core\Plugin\DefaultPluginManager->cacheGet( )	.../DefaultPluginManager.php:206
156	2.0404	26060752	 Drupal\Core\Cache\ChainedFastBackend->get( )	.../UseCacheBackendTrait.php:37
157	2.0404	26061104	 Drupal\Core\Cache\ChainedFastBackend->getMultiple( )	.../ChainedFastBackend.php:111
158	2.0404	26061544	 Drupal\Core\Cache\ApcuBackend->getMultiple( )

It seems the error is consistent when using a Panels variant type. If you use the PageBlockDisplayVariant (Block page variant type) shipped with page_manager variant you can add view blocks. I suspect it has something to do with the cache redirects check in the PageBlockDisplayVariant::buildRegions and the cache dependency. Can someone confirm this? I can't seem to get a handle on this.

I have the same problem, but only when I apply the patch #25 from #2759479: Proof of concept: Replace uasort() with dedicated stable-sort-by-weight functions, where possible.

This is connected for any cache backend, except of cache.backend.memory because it's not "true" cache. When fastServiceName variable of Drupal\Core\Cache\ChainedFastBackendFactory class contains name of "true" cache service then data will be serialized before setting to cache. Then, during reading from cache, data will unserializing and some of __wakeup() methods will lead to recursion. Now we need to know which data going to cache and is there potential recursions.

I am seeing the same behavior.
It's on a Pantheon dev site (nginx)
Using these modules/versions:

Drupal core 8.1.9
ctools 8.x-3.0-alpha27
Page Manager 8.x-1.0-alpha24
Panels 8.x-3.0-beta4+47-dev (2016-Aug-21)

On my local copy with no caching the problem seems to go away.

Following up on @mu5a5hi's comment above, we're building a D8 site using the latest (-dev) versions of all the relevant Panels-related modules.

We were able to create several Panels variants using menu blocks and custom blocks without any issues.

It was only when we created a new Views block display and tried to add that to a new Panels variant did this issue rear its ugly head.

The local environment works fine (using Acquia Dev Desktop with the following configured in development.services.yml:

services:
  cache.backend.null:
    class: Drupal\Core\Cache\NullBackendFactory

Our shared development environment is on Pantheon, and trying to create the same Panels variant results in an 502 Bad Gateway (nginx) error. So, this seems to fit the profile for what others are seeing.

We also tested this on a fresh Drupal 8 install with the same versions of all the related modules and saw the exact same behavior.

-mike

@mu5a5hi's, @ultimike as I said, an error will appear every time when you will use any cache: APC, Database, other one - does not matter. By default it'll be apc, but if you are not have it installed (as PHP extension), then you'll not have troubles.

I am facing the same problem. On debugging, I found the recursion when calling apcu_fetch on cid 'views:row'. Now, apcu_fetch unserializes the data itself and hence, I cannot figure out the serialized string except the fragment that causes recursion in unserializing ViewExecutable again. The serialized string being called on ViewExecutable::unserialize is something like this:

a:9:{i:0;s:17:"view_machine_name";i:1;s:7:"block_1";i:2;a:0:{}i:3;N;i:4;a:0:{}i:5;a:0:{}i:6;a:0:{}i:7;N;i:8;b:0;}

This sets up the recursion again in ViewExecutable::initHandlers() which again tries to fetch cid 'views:row' from cache and so on.

I figure something sets the whole view executable object when trying to save the view but I couldn't figure that out. I hope this helps someone take the next step.

In case it helps, I have attached the stack trace with calls and some annotations.

@hussainweb, I have fixed the problem after your research! Wait for a patch with tests from me.

@BR0kEN, awesome! Please share what caused it. I tried to find an object in that array in vain.

Damn, I was wrong. I didn't fix it. :( But have additional debugging notes now:

\Drupal\views\ViewExecutable
\Drupal\views\Plugin\views\display\DisplayPluginBase

Everything starts from \Drupal\views\ViewExecutable::unserialize(). Then we go to \Drupal\views\ViewExecutable::_initHandler() many times in the loop. From there's we goes to \Drupal\views\Plugin\views\display\DisplayPluginBase::getHandlers(). There's Views::handlerManager($handler_type)->getHandler($info, $override) which hang the process because of processing the same item many times.

Then, if we replace old implementation of \Drupal\views\ViewsData::get() by

  /**
   * Gets data for a particular table.
   *
   * @param string $key
   *   The name of table to retrieve.
   *
   * @deprecated NULL $key deprecated in Drupal 8.2.x and will be removed in
   * 9.0.0. Use getAll() instead.
   *
   * @link https://www.drupal.org/node/2723553
   *
   * @return array|bool
   *   An array of table data or FALSE if data does not exists.
   */
  public function get($key) {
    $this->getAll();

    return isset($this->storage[$key]) ? $this->storage[$key] : FALSE;
  }

we will pass the $handler = Views::handlerManager($handler_type)->getHandler($info, $override) condition inside of \Drupal\views\Plugin\views\display\DisplayPluginBase::getHandlers(), but will stop on $handler->init($this->view, $this, $info);.

Currently, I've did two hacking approaches to solve this:

1. Disabling fast cache backend at all

   Implement service provider in one of custom modules. Like so:

   namespace Drupal\custom_module;
   
   use Drupal\Core\DependencyInjection\ContainerBuilder;
   use Drupal\Core\DependencyInjection\ServiceModifierInterface;
   
   class CustomModuleServiceProvider implements ServiceModifierInterface {
   
     /**
      * Service container.
      *
      * @var ContainerBuilder
      */
     private $container;
   
     /**
      * {@inheritdoc}
      */
     public function alter(ContainerBuilder $container) {
       $this->container = $container;
       $this->alterCacheBackendChainedFast();
     }
   
     /**
      * Change service for fast cache backend factory.
      *
      * Disable the cache programmatically since "page_manager" module have
      * big troubles with it. This is done here to prevent using any "true"
      * cache which will lead to nesting level recursion or segmentation faults.
      *
      * WARNING: DELETE THIS COMPLETELY WHEN AN ISSUE WILL BE RESOLVED.
      *
      * @link https://www.drupal.org/node/2771889
      * @see \Drupal\Core\Cache\ChainedFastBackendFactory
      */
     private function alterCacheBackendChainedFast() {
       $this->container
         ->getDefinition('cache.backend.chainedfast')
         ->addArgument(NULL)
         ->addArgument('cache.backend.memory');
     }
   
   }
   

2. Use static cache to prevent recursion

   1. Define protected static $done = []; property for \Drupal\views\Plugin\views\display\DisplayPluginBase class.
   2. Replace if ($handler = Views::handlerManager($handler_type)->getHandler($info, $override)) { by if (empty(static::$done[$type][$id]) && $handler = Views::handlerManager($handler_type)->getHandler($info, $override)) {
   3. Add static::$done[$type][$id] = TRUE; above the $handler->init($this->view, $this, $info);

The first approach - quite dramatically and require more resources since part of cache will be disabled.
Second one - is very temporary. We need to figure out why the same data processes so many times.

Have you tried #2831521: Avoid unserialization of blockPluginCollection in BlockDisplayVariant - I had to import a clean database but it worked for me.