Posted by bobmct on June 17, 2011 at 3:32pm
Occasionally I've seen this error but lately it occurs EVERY time I try to run Drush. If anyone was able to overcome this would they please share? You can imaging what's progress is like when up against the brick-wall!
Comments
I did once by updating
I did once by updating Drush
Does this happen with all Drush commands or which ones? Can you add --debug ?
Whats your CLI memory_limit ? What versions are you using?
PHP cli mem limit
I have both settings at 256M (I have 24GB RAM to work with).
Additional research shows that the issue is a known php5+mysql function issue resolved in a newer version. Unfortunately I cannot upgrade at this time due to Drupal requirements. Thanks for responding.
Can you share links?
@bobmct: Can you share the links you found indicating how to solve this? I'm having the same problem and have been unsuccessful finding any helpful links so I'd love to see what your research turned up.
Drush segfaults...
Good morning BrightBold,
I wish I could point you to a solution. But I've found nothing. My experience with this issue "appears" to be memory related such that when memory becomes overly saturated or corrupt, this issue occurs. Interestingly enough, I have three instances of Drupal on a single server (Ubuntu 9.04) and drush will segfault on one but not on the others. I've got my php.ini max memory seg currently set to 256M which should be plenty. Our server has 24GB REAL ram.
On a similar note, we use the SecurePages module to force SSL access to all our non-public pages. There is an issue with that Module that causes PHP to fail. And I've found that running 'drush updb' for the particular instance gets things going again. This happens so often that I've set up a cron job to run that command every 15 minutes. That's not a permanent resolve but at least it keeps thing going.
We're in the process of finally migrating to version 6.22 (from 5.18) and it will be interesting to see if/how these issues change upon completion of that move.
Good luck and please post if you ever have any resolutions.
What version of php-cli are
What version of php-cli are you using? Latest version of Drush? D7 latest version?
We are having this very same problem on a server, and we're installing php53-cli which is php-cli 5.3.3, and have php-cli 5.1.6 now. I'll post if this works or not...
Kevin Davison, Web Development Manager
That didn't work... [x@x
That didn't work...
[x@x htdocs]$ drush fl
Segmentation fault
[x@x htdocs]$ drush fl
Segmentation fault
[x@x htdocs]$ drush fl
Segmentation fault
PHP Version 5.3.1
PHP 5.3.3 (cli) (built: Feb 3 2011 15:44:10)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Configure Command './configure' '--prefix=/opt/lampp' '--with-apxs2=/opt/lampp/bin/apxs' '--with-config-file-path=/opt/lampp/etc' '--with-mysql=mysqlnd' '--enable-inline-optimization' '--disable-debug' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-discard-path' '--enable-exif' '--enable-filepro' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-gd-imgstrttf' '--enable-gd-native-ttf' '--with-ttf' '--enable-magic-quotes' '--enable-memory-limit' '--enable-shmop' '--disable-sigchild' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-wddx' '--enable-yp' '--with-ftp' '--with-gdbm=/opt/lampp' '--with-jpeg-dir=/opt/lampp' '--with-png-dir=/opt/lampp' '--with-freetype-dir=/opt/lampp' '--without-xpm' '--with-zlib=yes' '--with-zlib-dir=/opt/lampp' '--with-openssl=/opt/lampp' '--with-expat-dir=/opt/lampp' '--enable-xslt=/opt/lampp' '--with-xsl=/opt/lampp' '--with-dom=/opt/lampp' '--with-ldap=/opt/lampp' '--with-ncurses=/opt/lampp' '--with-gd' '--with-imap-dir=/opt/lampp' '--with-imap-ssl' '--with-imap=/opt/lampp' '--with-gettext=/opt/lampp' '--with-mssql=/opt/lampp' '--with-sybase-ct=/opt/lampp' '--with-interbase=shared,/opt/interbase' '--with-mysql-sock=/opt/lampp/var/mysql/mysql.sock' '--with-oci8=shared,instantclient,/opt/lampp/lib/instantclient' '--with-mcrypt=/opt/lampp' '--with-mhash=/opt/lampp' '--enable-sockets' '--enable-mbstring=all' '--with-curl=/opt/lampp' '--enable-mbregex' '--enable-zend-multibyte' '--enable-exif' '--with-bz2=/opt/lampp' '--with-sqlite=shared,/opt/lampp' '--with-sqlite3=/opt/lampp' '--with-libxml-dir=/opt/lampp' '--enable-soap' '--enable-pcntl' '--with-mysqli=mysqlnd' '--with-mime-magic' '--with-pgsql=shared,/opt/lampp/postgresql' '--with-iconv' '--enable-dio' '--with-pdo-mysql=mysqlnd' '--with-pdo-pgsql=/opt/lampp/postgresql' '--with-pdo-sqlite' '--enable-intl' '--with-icu-dir=/opt/lampp' '--enable-fileinfo' '--enable-phar'
Kevin Davison, Web Development Manager
More comments on seg fault
I don't know why but it appears that when my database gets corrupted somehow I get the drush segmentation fault. I am trying to migrate our site to another instance/sub-domain so after mysqldump'ing the database to a sql file I use sed to make the domain substitutions then load it into a new database. Somehow following that I start to receive those pesky faults.
However, if I reload the new database with the unaltered sql file I DO NOT receive those faults. I wish there was someway to determine what table was the culprit.
So the search goes one . . . :(
Did you...when updating the
Did you...when updating the .mysql extract using SED, did you pay particular attention to the Variables table?
Within the variables table there are references to the original domain within the stored array, so if you change the domain and make the URL shorter or longer you need to recalculate the length of the array, or else you'll get a bunch of PHP warnings.
Although I doubt this is causing the drush issue, I just wanted to put a note to check the variables table when migrating domains...
-matt
For anyone who stumbles upon
For anyone who stumbles upon this through Google. I found that I had many node modules downloaded in my theme that contained .info files, Drupal was trying to parse all of them and running out of memory. You can remove all the .info files and the node modules should still function correctly.
find ./node_modules -name "*.info" -type f|xargs rm -finstead of removing these
instead of removing these info files why don't you just raise the memory limit for PHP?
bending technology to fit businesses.
Thanks
Sure enough. I had just installed some grunt npm modules when I started to experience this problem. I never would have made the connection, but this makes sense. Can we configure Drupal to ignore this directory instead? Permissions, maybe?
Use delete option
find ./node_modules -name "*.info" -type f -deleteincreasing memory does not
increasing memory does not help, as some of the .info-files trigger a bug in the PCRE-library used by specific version s of PHP.
Might be related to
Might be related to this:
https://www.drupal.org/node/1917530
Long text in .info crashes PCRE. I didn't/don't know if it affects *nix, but it sure affects windows.
I was having this problem...
I was having this problem but disabling filecache on one site the problem went out.
The problem is caused surely by nodejs but i don't know what is the origin of it.
Even am having the same problem
Even am having the same problem After installing node.js