Running HHVM 3.1 using Ubuntu 14.04 Final Beta using Nginx with fastcgi.
Fatal error: Stack overflow in
I've tried increasing the stack using -vEval.VMStackElms=524288, but it doesn't seem to make a difference. Any Ideas?
I checked the version it actually is HHVM 3.0 I pull and built it from the 3.1 Tag.
HipHop VM 3.0.0-dev (rel) Compiler: heads/HHVM-3.1-0-g3af5bc29494cedc3457f4d60f1afdd603337d08c Repo schema: 86fe165eb703fdba1680d5e43db3f5a3f836e504.
I'm testing it with Magento. Wordpress seems to work just fine. Works fine with php5-fpm. It's failing when it's trying to load the magento config. /magento/app/code/core/Mage/Core/Model/Config.php on line 1407
If any of your database connections are configured with <use/>, change that line you mentioned in Mage/Core/Model/Config.php from
if (!empty($conn->use)) {
to
$use = (string)$conn->use;
if (!empty($use)) {
The "right way" to do this is of course to make a copy of that class in your local code pool.
This is nowhere near enough info. I also doubt you are using 3.1 since I didn't release it yet.
Try putting prints in you code to narrow down what function is being called recursively. Does the problem happen on php5?
Remove < use /> in etc/local.xml fixed the problem.
Related
I just installed phpLDAPadmin on a test server and a production server. The instance on the test server tells me that it can't start TLS but it works fine otherwise so I'm ignoring the error. The problem with the installation on the production server can't be ignored. When I click on a user in the tree instead of getting an edit window on the right, I instead get another copy of the tree.
screenshot of duplicated tree
It's also returning a warning that using curly braces with an array is deprecated which isn't happening on the test server. I wouldn't expect a deprecation to cause this.
Other than the fact that I screw up things five times on the test server before getting them right, the test server and the production server should be the same.
I'm on RHEL 7.9 with phpLDAPadmin 1.2.5 and PHP 7.4.30. (Yes, I know I should be on RHEL 9 and using Identity Management but I need to buy some time until I can fit that upgrade into my schedule.)
What could be causing this tree duplication?
We're using odoo.sh platform with odoo14. The installed wkhtmltopdf is wkhtmltopdf_paas_wrapper 0.12.5, we can't upgrade to 0.12.6 because the access is very limited we cant use 'sudo' to apt-install. To temporarily solve this, we decided to use the 0.12.5 version. But it returns "Unable to call host printing service (HTTPError)" even with the right arguments. I've already tried it with the staging and production server, but still the same result. The ticket I've sent hasn't been replied to yet. This is so frustrating, I'm going bonkers...please help.
here's a screenshot:
ps: unrecognized argument error was intentional so I can display the available args. I've also crossed out the project domain. Thank you
Apparently, to properly execute the package, it should not have been "wkhtmltopdf" but instead "wkhtmltopdf.bin". I've overridden the ir_actions_report.py to change the package name. Here's the snippet of the original source code:
They shouldve known better, its a paid platform.
I have a Laravel 3 project, running on a plesk 11.5 CentOS 4(dedicated). It used to be on an IIS server, but i had to migrate it to plesk, since the company i'm working for is dumping the IIS server. Everything seemed to be running smoothly, until i logged out from my application, at first i got a WSOD (white screen of death), then i enabled php error reporting, and this is the error that was displayed:
Fatal error: Cannot override final method Laravel\Database\Eloquent\Model::sync()
This is a very strange error, since i have no method called Sync in any of my classes, and needless to say that there was no such error while the project was running on IIS.
I tried several different combinations of session/cache drivers, the only one that seems to be working is the APC driver.
When i have the APC driver enabled for cache and session, the above Fatal error is not displayed and everything works correctly. The PROBLEM is that i have given the Session Lifetime a value of 60(minutes) but it is completely ignored, meaning that the user is logged out after 2 or 3 minutes.
I've been to the Laravel IRC channel with this issue, some people kindly suggested to tweak the APC memory and ttl (time to leave) settings, but with no luck unfortunately :(.
Here are some APC settings from my server configuration:
apc.gc_ttl 3600
apc.shm_size 1024M
apc.shm_strings_buffer 32M
I desperately need help if anyone has any to offer! This is for a live running project and i need to find a solution asap.
I had the exact same issue and couldn't find a solution. I was going round in circles trying to figure out what on earth was going wrong.
I finally came across this post:
Fatal error: Cannot override final method
You need to make sure that the apc.include_once_override setting is set to 0. In your apc.ini file set like so:
apc.include_once_override=0
This error seems to be caused by caching of included classes.
I solved the problem after looking around the plesk panel.
The problem was that i had "Run PHP as FastCGI application" selected.
I switched to "Run PHP as CGI application" and everything works perfectly.
I'm not sure what the exact source of the problem was, only that FastCGI triggered the error.
I'm new to Solr, and am having trouble getting my setup to work. I'm using Solr 3.5.0 running on Tomcat 7.0.23, on Windows 7 Professional. If I copy the single core example into my Solr home, it doesn't work - I get 404 errors from Tomcat for both http://foo/solr/admin/ and http://foo/solr/collection1/admin/. I've tried to convert the multicore example (which works, probably because solrconfig.xml is a lot simpler) to use a single core by deleting the additional folder and changing solr.xml to this:
<solr persistent="false">
<cores adminPath="/admin/cores" defaultCoreName="core0">
<core name="core0" instanceDir="core0" />
</cores>
</solr>
As I understand it, this should mean that I can access core0 using either http://localhost/solr/admin/ or http://localhost/solr/core0/admin/, but only the second URL works - the other just returns a 404 stating "missing core name in path". I thought that defaultCoreName meant I didn't need to specify the core name in the path. Should the defaultCoreName attribute work the way I expected it to, and if so please could you suggest areas of the configuration that I ought to have a look at in order to fix this?
The behaviour you expect is correct. http://localhost/solr/admin/ should give the same result as http://localhost/solr/core0/admin/
Not sure what the problem is, are you running Tomcat on port 80 instead of 8080?
I am upgrading an existing magento website for 1.4 to 1.6.1.0.
I had dumped the existing database,
Copied all the required custom extension in the blank magento version 1.6.1.0
and after running the installation got the following error:
Error in file:
"/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php"
- SQLSTATE[HY000]: General error: 1025 Error on rename of './sales_flat_order' to './#sql2-3af-a7' (errno: 152)
How can I fix this issue?
Upgrading magento is very painful process. I suggest you to import-export data from old to new shop.
I just went through the same heartburn. I found that letting the page try to load until the script got an error or timed out and then trying again eventually worked. The upgrade script will attempt to start where it last stopped.
Before you do that, make a backup of you site and database. If it continually errors in the same spot, restore and try again.
These tips may help improve the odds of a quicker success:
Put the site in maintenance mode (by adding the maintenance.flag file
to the root directory) before starting.
Increase server and php timeouts by a very large amount (3-5minutes).
Cleanup temp and log database tables that you don't care about
(carefully, everybody has different needs here)
I tried several different methods and that is the only thing that worked. It took probably 10 reloads (waiting for a 3min timeout each time). In the end, everything upgraded correctly. No matter what method you choose, if you want to keep your store data, you will have to run the bulky db upgrade scripts that take forever.
I had similar issues when updating from 1.4.2 to latest.
I built a custom maintenance script included in my index.php that only allowes to access my ip. But the update process via shell replaced my index.php so it was accessible for everyone.
That was the cause that the final sql scripts where run by several clients and caused errors like "can't move table" etc. because those steps where already done.
--> Summing it up: Be sure that the site gets called only once, until the upgrade was successful!
The very best way to migrate magento in my opinion, is to import your entire db to an environment that you have your new magento. Then magento will run all scripts and updates and keep your data.
Maybe you find some problems on the upgrade scripts, but it's easier to fix them than fix the problems regarding model/eav's problems on the fly.
I have succeed by doing this on migrate from 1.4.1 to 1.8.1.