I wanted to check out the new default that uses gulp so I installed everything (on Linux - libsass, gulp globally, gulp save-dev in the subtheme, etc.) and started up gulp in the theme folder. Gulp started up and I tested sass. It looked like it was all working fine because the CSS was added, but when I tried to click on anything in the admin menu for the website the browser would tell me "The connection was reset." I couldn't load any page in the admin. I tried to use drush cc to clear the cache and that's when I saw "Segmentation fault (core dumped)." I cleared the cache for each item with drush and everything cleared normally. But when I tried to clear the cache for "theme-list" that's when I saw "Segmentation fault (core dumped)."

Looks like I am totally locked out of the site. I tried to disable the theme with drush and mysql but nothing worked. I'm thinking that I did or installed something wrong which created the glitch since no one else is experiencing the same problem. It's my first time using gulp so I'm not sure what to look for or how it all works in this case. I searched for a while and found nothing.

Anyone else happen to see or hear anything like this yet?

Comments

slipperysky created an issue. See original summary.

slipperysky’s picture

slipperysky CreditAttribution: slipperysky commented

I think I found the problem. The stock default install is fine.

What happened is I also installed the browser-sync plugin thinking I would use it later. Even though browser-sync wasn't set up in the gulpfile and was taken out of the package.json, it was still causing the segmentation fault. It looks like the browser-sync plugin folder only needs to exist inside the node_modules folder to create this problem, but I don't know for sure. I'll just not use browser-sync for now.

Here's where I found a similar problem:
Clearing Cache with Browser-sync 1.3.0 Results in a Segment Fault: 11 error
https://www.drupal.org/node/2309023

slipperysky’s picture

slipperysky CreditAttribution: slipperysky commented

I switched back to using the livereload that's already in omega. I installed gulp-livereload and it works great.

I actually wasn't having a problem with any of the gems in the "Dusty" starterkit because all I had to do was make sure I was using at least ruby 2.2.2, but gulp with libsass is obviously so much faster.

wesruv’s picture

wesruv CreditAttribution: wesruv at Lullabot commented

I just had this same problem with a Grunt, Panopoly and Zen setup, guessing it's BrowserSync + Drupal :(

I love me some browsersync, might try to get it working later.

fubhy’s picture

fubhy CreditAttribution: fubhy commented
Status: Active » Fixed

This is not related to any npm module or any functionality per se. It's because there are weird .info files in some of the npm modules in node_modules (which are in your theme) resulting in Drupal trying to read them as a theme.info file although they aren't. That causes it to crash on cache reload. Simply search for .info files in your node_modules folder and delete them or change the file_scan_directory() function (in drupal core) to use 'nomask' => '/(\.\.?|node_modules|CVS)$/'," instead of "'nomask' => '/(\.\.?|CVS)$/',". There are surely also patches for that somewhere in the core issue queue.

e.g. see #2329453: Ignore front end vendor folders to improve directory search performance

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

slipperysky’s picture

slipperysky CreditAttribution: slipperysky commented

Thanks for the information fubhy. Sorry about posting late, I meant to get back sooner.

I just wanted to put a little more info here in case anyone else was looking. I found something you can add to the bottom of the package.json that will remove the .info files after the install.

{

  "scripts": {
    "postinstall": "find node_modules -type f -name '*.info' | xargs rm"
  }
}

I'm not remembering where I saw that, but I am still messing around with the gulpfile.js and package.json. Browser-sync is starting to work and I'm not experiencing the segmentation fault now.

I'll probably keep using Livereload on a few recent "Default" libsass websites and then I have other older sites that are using the "Dusty" Ruby version. I did start getting some errors with Dusty, especially when cloning projects to fresh Linux installs, but the errors weren't that hard to fix, at least for now. I'll just keep fixing the errors until the time is right to convert everything to use libsass.

There's more info developing over here about setting up the gulp files:
Switch current omega sub-theme to the new LibSass

karolus’s picture

karolus CreditAttribution: karolus as a volunteer commented

Fuhby, per your suggestions, I renamed the single .info file I found in the node_modules directory, and all is OK now.

Per changing the file_scan_directory() function in core, wouldn't that be going against Drupal best practices?