Fix infinite loop in DrupalBoot::scanUpForUri (on Windows) #3435
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Should I file a corresponding issue or is this pull request on your radar? For Windows users this fix is quite critical. |
|
Looks good. Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Testing Drush 9.2.1 on XAMPP on Windows, I discovered this nice bug. Any Drush command would use 30% of the CPU and never finish. After some digging it was clear that DrupalBoot::scanUpForUri was the guilty one.
The bug is only present if you start in the Drupal site root. If you start inside the core or sites folder, the infinite loop isn't triggered. If you start in the Drupal site root, $root and $scan are identical, and as a result (of flawed logic IMHO) scanUpForUri ends up scanning all the way to the file system root.
On Linux scanUpForUri stops when it's gets to the file system root because $scan and $next becomes equal. On Windows this doesn't happen because of a nice bug in dirname:
dirname('C:/somedir')returnsC:\, not the canonicalC:/.The fix in the pull request is the minimal fix that stops the infinite loop. I considered fixing the root issue, the scanning to the root of the file system, but since I wasn't 100% sure if it could be useful in other use-cases I left it it as is.