Site unavailable after module update

Same here. My site become white screen after I updated sub-pathauto and redirect module.

can confirm the same - with module updated to 1.3 site is throwing WSOD on most of the heavier pages, using redirect, global redirect and subpathauto, had a really hard time understanding this, as updated bunch of modules

when downgrading to 1.2 - everything works fine

I can confirm the same. Upgrading to 7.x-1.3 breaks it. Downgrading back to 7.x-1.2 fixes it. My issue was running out of memory when it tried to build the menu.

/**
 * Implements hook_url_inbound_alter().
 */
function subpathauto_url_inbound_alter(&$path, $original_path, $language) {
  // If the current menu item exists at this path, then we should not continue
  // processing.
  $item = menu_get_item($path);
  if (!empty($item) && $item['href'] == $path) {
    return FALSE;
  }

  if ($source = subpathauto_lookup_subpath('source', $path, $original_path, $language)) {
    $path = $source;
  }
}

The call to menu_get_item() is new. In menu_get_item() there is the following:

    // Rebuild if we know it's needed, or if the menu masks are missing which
    // occurs rarely, likely due to a race condition of multiple rebuilds.
    if (variable_get('menu_rebuild_needed', FALSE) || !variable_get('menu_masks', array())) {
      menu_rebuild();
    }

I wonder if maybe there is an infinite recursion happening? I was still getting it dying even when I upped the memory to 1GB, so there is definitely something infinite going on.

Also can confirm the same. After update to 7.x-1.3 site throws wsod. problem is runing out of memory no matter how high I set the php memory limit.

Same here

Sub-pathauto 7.x-1.3 don't work with XML sitemap menu 7.x-2.0-rc1 for me

Same here downgraded to 1.2 fixed it for me.

I can confirm the same. I get recursion when I clear drupal caches. Screenshot attached.

Looks like I may have the same issue. After enabling the 1.3 version of the module everything takes FOREVER to load with things timing out. Looks like I will have to disable the module via a MYSQL table update and then try 1.2 version.

We ran into the same error using Sub-pathauto and XML sitemap.
The attached patch fixes the problem for us.

Meh, the error still happens since the menu is rebuild every time menu_get_item()</em> is called in <code>subpathauto_url_inbound_alter().
Only way to stop this: set variable "menu_rebuild_needed" to FALSE before getting the menu item.

Hello @stBorchert,
thanks a lot for your patch!

Without the patch both of my local and staging environment runs out of PHP-memory, although my local environment has 512 MB. It was not possible to login into drupal, because I got a white-screen on the user-login page.

After patching subpathauto I reduced my local memory to only 256 MB for testing and it works fine on both environments (local and staging). After intensive testing we deployed the patch against the production-site and everything there is ok also.

So I think, this patch should be commited.

Not just memory: this also kills cpu.

Caused a huge headache for me today. The worst thing about this is that it's not necessarily instantly apparent.

The patch in #15 is absolutely CRITICAL, and needs to be applied asap, and module version updated to 1.4.

This is definitely a critical site breaking issue.

Patch code looks good to me and it fixes the problem. +1 for commit.

As this patch conflicts with #1814516: Subpathauto causing admin pages to appear in default theme, just in case anyone wants to use both in a makefile I'm posting a patch combining both patches.

And I'll just unpublish this to make clear this is not the actual patch that's RTBC :)

This patch needs work as call to variable_del('menu_rebuild_needed') inserted here sometimes takes forever. See https://www.drupal.org/project/subpathauto/issues/2451445

So here's the relevant code in #19 that's causing issue:

  if (empty($items[$path])) {
    $menu_rebuild_needed = variable_get('menu_rebuild_needed', FALSE);
    // In no cases rebuild the menu while trying to load the menu item here
    // since that would cause infinite loops if any module calls
    // drupal_get_normal_path() in hook_link_alter().
    variable_del('menu_rebuild_needed');
    $items[$path] = menu_get_item($path);
    if ($menu_rebuild_needed) {
      variable_set('menu_rebuild_needed', TRUE);
    }
  }

I don't think we need to call variable_del() here at all--which then updates the database, only for us to reset the variable a few lines later. I believe all that's needed to prevent the infinite loop possibility is to temporarily set the global 'menu_rebuild_needed' conf variable, then set it back (rather than updating the variables table in the database). This is because variable_get() only returns the value of the conf setting anyway. So I think the code above can be safely changed to:

  if (empty($items[$path])) {
    $menu_rebuild_needed = variable_get('menu_rebuild_needed', FALSE);
    // In no cases rebuild the menu while trying to load the menu item here
    // since that would cause infinite loops if any module calls
    // drupal_get_normal_path() in hook_link_alter().
    unset($GLOBALS['conf']['menu_rebuild_needed']);
    $items[$path] = menu_get_item($path);
    if ($menu_rebuild_needed) {
      $GLOBALS['conf']['menu_rebuild_needed'] = TRUE;
    }
  }