Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Enabling "Optimize CSS files" and drupal dies. It's a nasty bug.
Tested on XAMPP for Windows 1.7.1
To fix empty the cache table and set the preprocess_css variable back to 0
Comment | File | Size | Author |
---|---|---|---|
#1 | 543892-1-css-aggregation.patch | 1.3 KB | Anonymous (not verified) |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThe way css is preprocessed at the moment, all @imports in a css file are loaded, optimised.
Why is this a problem?
If a.css imports b.css which imports c.css, then c.css will be loaded and optimised. It will then replace the import statement in b.css. The resultant css (including the section that is already optimised) will be optimised, after which it will replace the import statement in a.css. At this point a.css (with the already optimised b.css and c.css) will be optimised before finally saving it. This means that many files may be processed multiple times with no benefit. In addition to this, it causes a large section of text to be sent to the regex (since all @imports are resolved.) This can cause a segfault in libpcre on some installations.
The patch?
Simply reorders the operations. The new order is optimise, fix the @imports. This means that each file is optimised only once, thus it keeps the size of the text sent to the regex from growing too large.
Comment #2
JacobSingh CreditAttribution: JacobSingh commentedWhile this looks like too simple a solution, I'm tempted to say that it is the right patch.
I'm just surprised that no one has run into this yet.
Would like to get a review from the original author if possible.
Comment #3
mikeytown2 CreditAttribution: mikeytown2 commentedk give me 30 min or so, i'll test this out.
Comment #4
JacobSingh CreditAttribution: JacobSingh commentedI guess some more review is coming, changing status.
Comment #5
mikeytown2 CreditAttribution: mikeytown2 commentedJust checked and this does not fix the error I am having; going to upgrade to XAMPP 1.7.2 and try again.
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedStill fails with 1.7.2
I get
The connection to the server was reset while the page was loading.
Comment #7
JacobSingh CreditAttribution: JacobSingh commented@mikeytown2: Can you check your apache logs? Also does this happen only on your customized Drupal install or a fresh one?
In Joshua's case, it is only when he's got a ton of CSS files (and big ones), standard Drupal doesn't do this. Would like to see if it is a separate issue.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedBrand new install. Get from cvs, apply patch, and install in new database. Where would the apache logs be located? Checked files in xampplite\apache\logs and didn't find any interesting errors
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commentedHere's the last entry in the access log - Me turning on css optimization
Comment #10
JacobSingh CreditAttribution: JacobSingh commented@mikeytown2: Your problem sounds like a different problem...
If you see nothing when css aggregation is turned on, it is most likely going to show up as some type of error in your access log, php error log or apache error log.
In Joshua's case (I know because we work together), he was getting Segfaults, and after debugging PHP he figured out it was in the libpcre library (preg_*) and that's how he traced it to this. But on his, normal Drupal installs worked fine - also, he's on Linux.
Best,
Jacob
Comment #11
JacobSingh CreditAttribution: JacobSingh commentedHmm... That's normal looking. That means that the resulting request didn't make it in your log, probably due to a PHP segfault. Is there a php error log in XAAMP?
-J
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedYeah, php error log is empty... Going to comment out stuff, and locate the bug. The "not so fun way" to figure this out.
Comment #13
mikeytown2 CreditAttribution: mikeytown2 commentedIf I comment this out, then it works
// Perform some safe CSS optimizations is causing the problems
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedComment #15
mikeytown2 CreditAttribution: mikeytown2 commentedLooking at 6.x it appears that the regex was executed in a different order
http://api.drupal.org/api/function/drupal_load_stylesheet/6
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedOrder has nothing to do with it
This is the regex code that causes php to fail
Comment #17
mikeytown2 CreditAttribution: mikeytown2 commentedFor some strange reason, if a css comment is >= 364 characters this code fails; only on windows platforms, using XAMPP (php 5.2.9 & 5.3.0).
Inside
5.x: http://api.drupal.org/api/function/drupal_build_css_cache/5
6.x: http://api.drupal.org/api/function/drupal_load_stylesheet/6
7.x: http://api.drupal.org/api/function/drupal_load_stylesheet_content/7
Bug is in 7.x inside the modules/system/system.css file, introduced with this commit
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/system.css?...
Last css comment is over 363 characters
Confirm bug exists in 6.x & 7.x; most likely in 5.x as well.
Edit: Link to old PHP bug, that is very similar.
http://bugs.php.net/bug.php?id=38512
Comment #18
JacobSingh CreditAttribution: JacobSingh commentedThis might win random bug of the year award. It got down to tracking CVS commits, but seems to be somewhere in here when the long comments where committed. Perviously there wasn't any in Drupal Core.
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/system.css?...
Comment #19
JacobSingh CreditAttribution: JacobSingh commentedI think @MikeyTown2's issue is different one:
See #584370: Enable Optimize CSS files on performance page & Drupal dies for a rehash of what Joshua found - which is not just windows specific.
Comment #20
rct240 CreditAttribution: rct240 commentedDELETEME: After some testing my comment was proven erroneous.
Comment #21
mattyoung CreditAttribution: mattyoung commented.
Comment #22
donquixote CreditAttribution: donquixote commentedIf this helps to reproduce:
http://drupal.org/node/444228#comment-2089300
Totally a PHP / PCRE preg_replace bug.
I reduced it to a small standalone script.
And on PHP.net
http://bugs.php.net/bug.php?id=46551
(I hate the PHP bugtrack system)
Comment #23
Tri CreditAttribution: Tri commentedHi all.
Read more about this here. There are also patches against HEAD and 6.14.
Please test them and report back there.
Comment #24
mikeytown2 CreditAttribution: mikeytown2 commented#444228: Optimize CSS option causes php cgi to segfault in pcre function "match"