jnorell

Hi,

I am also having issues with this. I don’t see a visible resolution to this. If there is one can you please send it my way.

Thanks..

Also related, in diagnostics it shows:

Checking if web server can write to ~/plugins/wordfence/tmp FAIL

Because the plugins directory is not writable by the web server by design on pantheon. Could that also be configurable, to use something under wp-content/uploads/ ?

This is not just for the cache, it also affects the firewall. It appears the official stance is you cannot use the wordfence firewall on pantheon hosted sites: https://pantheon.io/docs/unsupported-modules-plugins/#wordfence

So don’t toss this request because caching is gone – please add the ability to put the wflogs directory somewhere else (under wp-content/uploads/ in pantheon’s case).

Thanks…

Definitely a hhvm bug. To report that they understandably want you to compile and run the latest hhvm version, and if possible have a reproducable setup. I wonder if we could narrow down what wordfence is doing when that happens to help reproduce it? Eg. it’s always handling a request that gets blocked, or always running a site scan or anything.

Also if anything like that could be identified, maybe wordfence could do whatever it’s doing a little differently, and avoid triggering the hhvm bug.

I don’t know much about how/what bytecode hhvm caches, and in particular if eval() code is cached, but there’s not any recursive eval going on or something that would generate crazy levels of php calls is there?

For now I’m bumping up the relevant jit_*_size variables whenever this happens to see if it ever gets stable. Once I’m satisfied of that, I’ll simply turn hhvm off for this site (and maybe every other wordpress/wordfence site?), as the memory usage is crazy (hhvm daemon is >256M RSS) for a simple site like this.

the victory was short-lived, hhvm crashed again with the same error as earlier (from syslog this time):

Assertion failure: /tmp/tmp.2YEszDTIHd/hphp/runtime/vm/jit/mc-generator.cpp:1713: bool HPHP::jit::{anonymous}::mcGenUnit(HPHP::jit::TransEnv&, HPHP::jit::CodeCache::View, HPHP::jit::CGMeta&): assertion '0' failed.
data block = cold
message: Attempted to emit 1 byte(s) into a 1410 byte DataBlock with 0 bytes available. This almost certainly means the TC is full. If this is the case, increasing Eval.JitASize, Eval.JitAColdSize, Eval.JitAFrozenSize and Eval.JitGlobalDataSize in the configuration file when running this script or application should fix this problem.

This is a very small/early improvement (possibly absolutely meaningless), but I had hhvm crashed when I came in the last 2 mornings, and this morning it was still running after changing the 4 settings referenced in my console message above.

I went over to https://docs.hhvm.com/hhvm/configuration/INI-settings#jit-settings__jit-translation-cache-size and looked up the default values and then doubled them, via adding to my site php.ini:

hhvm.jit_a_size = 125829120
hhvm.jit_a_cold_size = 50331648
hhvm.jit_a_frozen_size = 83886080
hhvm.jit_global_data_size = 31457280

I’m guessing it was jit_a_cold_size that I had a problem with, given the data block = cold in the error, but bumped them all for good measure.

This website is running the X theme with revolution slider and woocommerce, and not terribly large/bloated with plugins, so may be a common issue wordfence will encounter. If this proves to be “the fix” (or rather, tweaking those appropriately), maybe wordfence could determine if hhvm is in use and recommend adding those to the php.ini for a website just like they specify the auto_prepend setting.

One thought: this completely crashed the hhvm service for this website. That can’t be (only) a wordfence problem; no matter what php code you throw at the interpreter, it’s gotta be a bug in hhvm if it crashes the hhvm process.

Just one more “me too,” I moved a site to a new server last week and set it up with hhvm, and having the same type of crash.

hhvm: 3.14.3~jessie
wordfence: 6.1.12

Also nothing printed by hhvm -l wp-content/wflogs/rules.php

This has happened more than once, but I have the logs/stacktrace (and even hhvm bytecode repository) from last night, when another crawler (91.121.79.180) was crawling this site (a small woocommerce storefront).

# cat /tmp/stacktrace.24250.log

PHP Stacktrace:

#0  include() called at [/var/www/clients/client3/web8/web/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/waf.php:225]
#1  wfWAF->loadRules() called at [/var/www/clients/client3/web8/web/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/waf.php:134]
#2  wfWAF->run() called at [/var/www/clients/client3/web8/web/wp-content/plugins/wordfence/waf/bootstrap.php:259]
#3  include() called at [/var/www/clients/client3/web8/web/wordfence-waf.php:6]

And if helpful (probably not?), this was on console where I had restarted hhvm the previous day:

Assertion failure: /tmp/tmp.Yo6dgSlEaj/hphp/runtime/vm/jit/mc-generator.cpp:1713: bool HPHP::jit::{anonymous}::mcGenUnit(HPHP::jit::TransEnv&, HPHP::jit::CodeCache::View, HPHP::jit::CGMeta&): assertion '0' failed.
data block = cold
message: Attempted to emit 1 byte(s) into a 1338 byte DataBlock with 0 bytes available. This almost certainly means the TC is full. If this is the case, increasing Eval.JitASize, Eval.JitAColdSize, Eval.JitAFrozenSize and Eval.JitGlobalDataSize in the configuration file when running this script or application should fix this problem.

> Have you been using Wordfence on HHVM for a while now?
> Is the first version of Wordfence that has caused any problems?

Just put this site on new server/hhvm last week, so no prior baseline.

> On the Wordfence Firewall page, what is the current Firewall status?

Protection Level: Extended Protection
Firewall Status: Enabled and Protecting

I’ll switch to php-fpm for how; let me know if I can get more info that would help track this down.

I see this same or very similar problem symptom updating an old site, it seems to be purely a woocommerce update problem. All product variations are lacking a ‘regular_price’ after the update (sale prices do carry across).

I have screenshots of before and after (apparently can’t include images here?), but the process was:

– On the old site, I look at a product which has 2 variants, and verify they both have a price set.

– Copied live site to dev server.

– Deactivate all plugins except woocommerce and akismet (can’t deactivate, it gives a php error).

– Change to twentyelven theme.

– Upgrade wordpress from 3.3.2 to 4.3.1, and run database updates.

– Deactivate akismet.

– Upgrade woocommerce from 1.5.7.1 to 2.4.10, and ‘Run the updater’ (woocommerce updates).

And now in the new site, that same product has nothing in ‘Regular Price’ field.

I did print_r($prices) in the is_on_sale() function at one point, and I can see the $prices array has $prices[‘price’] set for all variants, and a few have a $prices[‘sale_price’] set, but absolutely none of them have $prices[‘regular_price’] set, like:
[05-Dec-2015 21:43:12] Array
(
[price] => Array
(
[1700] => 40
[1701] => 80
)

[regular_price] => Array
(
[1701] =>
[1700] =>
)

[sale_price] => Array
(
[1701] =>
[1700] =>
)

)
`

In this case I’ll just manually go through and fix the prices, but I don’t see how this could be anything but a bug?

Hey Cat5,

If you go to the settings of that plugin there are options that you can select to turn off the content on different areas (for example archives, categories, etc.) Go to the sharing tools section and then you will have Sharing buttons above content and sharing buttons below content. There are two areas that you can select under those, Style and Options. Click on Options and it will allow you to uncheck the content that you don’t want those share buttons to appear on. Hope that helps ??

Just guessing, but set your $args array before you use it? Ie. swap the two lines:

$args=array('category'=>'catname');
echo WP_FullCalendar::calendar($args);

It appears to be either an incompatibility issue with a plugin with Composium – Visual Composer Extensions plugin or it is running out of memory. Disabling the Composium -Visual composer Extensions seems to have resolved the issue at this point in time. It seems to work fine with on our demo site which does not have all the plugins installed that are on the live site and is also located on a different server (with or without more memory, I’m not sure).

Thanks for all your help.

Ok, thanks. I don’t see any incompatible plugins at this time. I’ll keep testing and see what plugin it is or if it is the theme.

We have the Happy Child Theme and it appears to be working on the demo site with the latest wordpress and qtranalate-x, WordPress SEO & qtranlate-x, WPBakery Visual Composer w/ qtranlate-x. We have a different version of Happy Child Theme on our demo site so I’m going to test that out and see if that might be the reason for the issue. I’m slowly going through the modules on our live site and adding them to the demo site to see which one is maybe conflicting.

Do you know of any plugins that conflict with qtranlate-x off hand?

Yes, I do.