Closed (duplicate)
Project:
Drupal core
Version:
7.x-dev
Component:
system.module
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
8 Aug 2009 at 23:29 UTC
Updated:
3 Oct 2009 at 23:12 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Anonymous (not verified) 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 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 commentedk give me 30 min or so, i'll test this out.
Comment #4
JacobSingh commentedI guess some more review is coming, changing status.
Comment #5
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 commentedStill fails with 1.7.2
I get
The connection to the server was reset while the page was loading.Comment #7
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 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 commentedHere's the last entry in the access log - Me turning on css optimization
Comment #10
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 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 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 commentedIf I comment this out, then it works
// Perform some safe CSS optimizations is causing the problems
Comment #14
mikeytown2 commentedComment #15
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 commentedOrder has nothing to do with it
This is the regex code that causes php to fail
Comment #17
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 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 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 commentedDELETEME: After some testing my comment was proven erroneous.
Comment #21
mattyoung commented.
Comment #22
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 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 commented#444228: Optimize CSS option causes php cgi to segfault in pcre function "match"