Way to go, PHP. I have no idea why it does that
# /usr/share/drush/drush.php --context_type='site' --platform='/var/aegir/hostmaster-0.4-alpha14-228-g625213c' --server='@server_master' --uri='test.aegir.koumbit.net' --site_path='/var/aegir/hostmaster-0.4-alpha14/sites/aegir.koumbit.net' --site_enabled --language='en' --client_email='webdev@rt.koumbit.net' --profile='hostmaster' --ssl_enabled='2' --ssl_key='koumbit.net' --loaded-config --name='test.aegir.koumbit.net' --debug provision-save 'test.aegir.koumbit.net'
Found command: provision-save (commandfile=provision) [0.12 sec, 7.36 MB] [bootstrap]
Initializing drush commandfile: drush_make [0.12 sec, 7.36 MB] [bootstrap]
Initializing drush commandfile: drush_make_d_o [0.12 sec, 7.37 MB] [bootstrap]
Initializing drush commandfile: provision [0.12 sec, 7.37 MB] [bootstrap]
Load alias @self [0.12 sec, 7.37 MB] [notice]
Erreur de segmentation
ceres:~/.drush$
This is trying to debug a alpha14 to HEAD upgrade, and I took that provision-save command from provision-clone:
drush @hostmaster provision-clone test.aegir.koumbit.net /var/aegir/hostmaster-0.4-alpha14-228-g625213c --debug
wtf?
Comments
Comment #1
anarcat commentedFor the 'french-impared', "Erreur de segmentation" is "Segmentation fault".
That, is just weird.
Comment #2
anarcat commentedThis also crashes the same way:
I didn't have the right clone command... but this still fails.
Comment #3
anarcat commentedThis happens because i am using the platform path instead of the alias.
We should still not core dump.
Comment #4
adrian commentedthis might fix it - http://git.aegirproject.org/?p=provision.git;a=commitdiff;h=3efdd6cb0c55...
Comment #5
anarcat commentedThis still core dumps after the commit, but I have other issues I will follow in other tickets.
Comment #6
anarcat commentedOr rather: the other issues are fixed with the above patch, but not the core dump problem.
This is not php 5.3.
Comment #7
Josh Benner commentedI am also getting segfaults on every provision-save that occurs as a result of running a verify on a site. If I run the provision-save command myself at the command line, it succeeds without a segfault.
This was happening to me with 0.4-beta2. I pulled the latest provision from Git, and I still see this behavior.
PHP 5.2.10.
Comment #8
Anonymous (not verified) commentedAnarcat: Would be interested to know if this fixes it: http://git.aegirproject.org/?p=provision.git;a=commitdiff;h=c214fe6063fd...
Comment #9
anarcat commentedI guess I'll see this when I upgrade our prod server to RC :P
Comment #10
anarcat commentedi am seeing this in a production 0.4-rc1+ server, not sure why yet:
after installing php5-xdebug, I see this:
Comment #11
Anonymous (not verified) commentedI wonder if this is the same infinite loop/recursion Drush Alias/context issue that unconed identified when he was working on Clusters?
#1016890: Create Server as cluster is broken after save
See patch in #4
Comment #12
anarcat commentedThat issue doesn't seem to indicate the same error messages. However, the patch in #4 could fix the issue. Not sure I'll have time to fix it, but this should be fairly simple to reproduce and test.
Comment #13
anarcat commentedSee also http://community.aegirproject.org/node/267
I do think this is a machine that unconed put his finger in. Glad he was able to get it out in time. Not sure i want to get my pinky in there. :P
Comment #14
guypaddock commentedI'm seeing similar behavior... after initial install, things were working fine. Then, after having some strange problems verifying platforms, I purged that install completely and started over. Now, I can't create platforms because "provision-save" seg-faults when verifying new platforms.
I have PHP 5.2.17, Suhosin-Patch 0.9.7, and eAccelerator v0.9.6.1 installed. At first I suspected Suhosin because the core-dump from the segmentation fault indicated infinite recursion among
zend_do_fcall_common_helper_SPEC,suhosin_execute_ex, andexecute. But, even after disabling Suhosin, I was seeing the same behavior (minussuhosin_execute_excalls in the stack trace).When I enable XDebug and set a stack depth limit of 1000, the error message in the Aegir log changes to:
Without Xdebug, the message is:
Xdebug doesn't print any error message to the console, but I enabled profiling and found that
provisionContext->service()on line 334 ofprovision/provision.context.incis invoked 980 times before the stack limit is reached. I believe that's where the infinite loop is.Thoughts?
Comment #15
guypaddock commentedHrm, this is precisely the issue I have:
http://community.aegirproject.org/node/266
Comment #16
guypaddock commentedBTW Here's the log from Aegir for the platform verify task:
When I do a debug_print_backtrace() on the line before the warning "Trying to get property of non-object hosting.module:855" appears, this is what I get:
It looks like
hosting_hosting_platform_context_options()expects$task->ref->web_serverto be set, but it's not, sohosting_context_name()gets passedNULL. Not sure why it's not there in the object, though...Here's the offending code in
hosting_hosting_platform_context_options():Comment #17
steven jones commentedDid you just remove hostmaster and re-install?
It would appear that you're somehow managing to create platforms that don't have a webserver associated with them, which is then cascading down the stack causing lots of errors. Can you confirm that your platforms don't have a webserver and you're still being allowed to create them in the UI?
Comment #18
mrfelton commentedLooks like a similar problem to what I'm experiencing. The following results in a Segmentation Fault:
However, if I remove the
--web_server='@server_server_wwwexamplecom'part then it works.EDIT: Well, turns out @server_server_wwwexamplecom should have actually been @server_wwwexamplecom in our case, so the error was on our part, but still, a useful error message rather than a seg fault might be better!
Comment #19
steven jones commented#1454316: Provision recurses infinitely on reading in context I hope has the fix for this.
Comment #20
omega8cc commentedMaybe it is related to some known PHP bug? See: https://bugs.php.net/bug.php?id=48034
See also:
http://drupal.org/node/1462984#comment-5790468
http://drupal.org/node/1366084#comment-5877974
Comment #21
steven jones commentedIf someone could try the patch in #1454316: Provision recurses infinitely on reading in context, if it works for them, then we can mark this issue as a duplicate.
Comment #22
steven jones commentedFairly certain this issue was a duplicate of #1454316: Provision recurses infinitely on reading in context