Fix: Using Magic 360 Crashes Apache on Windows 7 XAMPP environment

While in the process of using some of MagicToolbox’s awesome website tools for one of the sites I maintain, I ran into a stumper that cost me several hours of head banging.  I’m sharing it for my own sanity down the road and if I help you out in the process, well let’s just say that’s icing on the cake!

I downloaded and installed (according the the instructions) the Magic Zoom and Magic 360 Magento modules and to my amazement they seem to just work out of the box!  The team there really did an excellent job on crafting this toolset!  It wasn’t until I was testing out the Magic 360 that I discovered a set back.  (For the record, I’m running a XAMPP environment on a Windows 7 PC and am more-or-less a newbie on Magento and LAMP in general.)  I was loading the images for a given product and when I saved the product, the Apache server just crashed!  Time and again, after I clicked the Save or Save and Continue in Magento I would see the following:

image

Stepping through the code brought me to their saveProductImagesData function within the Observer.php file.  Within that function is a call to the database with an update statement:

$connection->query("UPDATE {$table} SET columns = {$columns}, gallery = '{$data}' WHERE product_id = {$id}");

From this point, the Zend DB library takes over and it is there that the Apache server crashes.  More specifically, the offending line of code is in the lib/Zend/Db/Statement.php file line 204:

$sql = preg_replace("/$q($qe|\\\\{2}|[^$q])*$q/", '', $sql);

As it turns out, there is a little known bug around the preg_replace function that causes the apache server to crash!  This crash is due to the thread stack size being inadequately set on the Windows Apache configuration and can be adjusted as described by one of the commenters of the bug:

[2011-09-29 12:35 UTC] ferenczy at volny dot cz
Better way to alter Apache stack size is using the ThreadStackSize directive in the Apache's configuration file (httpd.conf). There is a description of the ThreadStackSize directive in Apache's documentation: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadStackSize

So increase of Apache stack size might looks like this (lines from httpd.conf):

<IfModule mpm_winnt_module>
   ThreadStackSize 8*1024*1024
</IfModule>

It sets Apache stack size to 8 MB, so it's the same as a default value on Linux.

A google search of the “preg_replace crashing apache” helped solidify this as being the issue with a similar resolution from a question on stackoverflow titled: How do I increase the stack size for Apache running under Windows 7?.  After following Dawid Ferenczy proposed solution, I was successful in running the Magic 360 product within my development environment.

Advertisements

Magento Dev Environment on Windows 7

In this post, I’m going to walk through how our development team configured our development environment on a Windows OS for Magento.  The impetus for this was to support an out sourced site running Magento in a LAMP environment; keeping in mind the need for continued support of current projects on the Windows stack.  Thus we’ve moved to using XAMPP on Windows to support a company site on Linux.  Fun right!?

We decided to go with the XAMPP Package to install Apache, MySQL and PHP.  The version may be unimportant, but XAMPP 3.1.0 Beta 6 was used at the time of this writing.  When finished with our environment, we had three sites we could hit from our development machines:

  1. The XAMPP Startup/Splash page on the root (Example: http://local.dev:100/)
  2. A fresh Installation of Magento at a subdomain (Example: http://magento.local.dev:100/)
  3. A copy of the company site (running Magento) configured at a subdomain (Example: http://company.local.dev:100/)

The following is a list of downloads we found useful for setting up the development environment:

  1. XAMPP (the platform)
  2. NetBeans IDE (the development tool)
  3. XDebug (debugger for PHP)
  4. WinSCP (used to move files off Linux server on to development machine)
  5. Git (Distributed Version Control System)
  6. 7-zip (used to unzip compressed database and folders from Linux environment)
  7. MySQL WorkBench (MySQL GUI for development)

Below is a general outline of steps taken to establish these three sites on our development machines:

  1. Using a Zip Package of XAMPP
  2. We Kicked off the setup_xampp.bat file after storing the folder structure in the desired location
  3. Configured Port to use 100 instead of 80 (optional) due to IIS using port 80 (under install-path\xampp\apache\conf\httpd.conf)
  4. Added new domain names in the Hosts file (c:\windows\system32\drivers\etc\hosts)
  5. Configured Virtual Hosts File (install-path\xampp\apache\conf\extra\httpd-vhosts.conf)
    1. Referenced domain names from the Hosts file
    2. Added MAGE_IS_DEVELOPER_MODE “1” to Each Virtual Host configured
    3. Each Virtual Host referenced a folder under the default install-path\xampp\htdocs\ path using the DocumentRoot attribute

      Sample vhost file

      Sample vhost file

  6. Launch/Restart Apache and MySQL services under XAMPP control panel  (install-path\xampp\xampp-control.exe)
    1. open default website based on configured domain and port and confirm “XAMPP For Windows” site opens
    2. Local XAMPP Site Complete
  7. Obtained Copy of Magento Enterprise Edition (Community will suffice)
    1. Copied Magento folder structure under the install-path\xampp\htdocs\ path
    2. Created a new database for Magento using mysql (or MySql Workbench)
    3. Site opened with installation page for Magento.
    4. Began Installation
    5. Magento Out of the Box Development Site Complete
  8. Obtained Copy of Company Site (developed on Magento)
    1. Used WinSCP to retrieve a copy of Company Site from Linux servers (or pull from Git repository)
    2. Retrieved a copy of the database as well (using MySqlDump)
    3. Retrieve a copy of the media folder as well
    4. Create database schema for the new database in mysql (or MySql Workbench)
    5. Imported SQL file into new database
    6. Confirm app/code/etc/local.xml exists and configured accordingly
    7. Change domain name in core_data_config table to reflect development URL
    8. Run Site
    9. Company Magento Site Complete

Magento: Fatal error: spl_autoload() … line 132

So in dealing with Magento, I’ve ran across the following error:

Fatal error: spl_autoload(): Class Zend_Log_Exception could not be loaded …/lib/Zend/Log/Writer/Stream.php on line 132

We were attempting to use Memcache but each time it was enabled, the site would throw the above mentioned error on the page.  So we had it isolated to Memcache (disable Memcache in local.xml and error goes away) .  Reviewing the log files on the server (/var/log/system.log), we discovered the following:

ERR (3): Warning: ini_set(): Cannot find save handler ‘memcache’  in …app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 56

The code was trying to use a memcache handler, but couldn’t find it.  A review of the PHPINFO() output further confirmed that memcache was not a recognized handler:

clip_image001

The session had a memcached handler, but not a memcache handler! 

On the server, I typed php on the command line and discovered the following:

PHP Warning:  PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/memcache.so’ – /usr/lib64/php/modules/memcache.so: cannot open shared object file:  No such file or directory in Unknown on line 0

So armed with that knowledge, I check the location to see if, indeed, the file exists.  I discovered the memcached.so file does, but memcache.so file does not!

image

So someone failed to recognize that there are two code bases for Memcache(d): 
     Memcache:  http://php.net/manual/en/book.memcache.php
     Memcached:  http://php.net/manual/en/book.memcached.php

The code appeared to be referencing the Memcache handler, but the only code base installed was the Memcached!  After discovery, the Memcache code base was installed on the servers and resolved the issues.

We were able to confirm the presence of the Memcache handler in the PHPINFO() output:

image

The error went away and we were able to proceed! 

Name and Location are Key!

She’s going to bark at you if you don’t treat her with respect!  That’s why it’s key to provide the proper name and proper location  for any Magento files.  Any time you see the following in Magento, assume you got your wires crossed and start rechecking everything in the path:

 

( ! ) Fatal error: Call to a member function load() on a non-object in C:\xampp\htdocs\MagentoE\app\code\core\Mage\Core\Model\Abstract.php on line 225
Call Stack
# Time Memory Function Location
1 0.0006 145344 {main}( ) ..\index.php:0
2 0.0041 330992 Mage::run( ) ..\index.php:87
3 0.0150 983144 Mage_Core_Model_App->run( ) ..\Mage.php:683
4 1.7253 7152144 Mage_Core_Controller_Varien_Front->dispatch( ) ..\App.php:354
5 1.7378 7894792 Mage_Core_Controller_Varien_Router_Standard->match( ) ..\Front.php:176
6 1.7412 8120632 Mage_Core_Controller_Varien_Action->dispatch( ) ..\Standard.php:250
7 1.9243 11377120 MyModule_Complexworld_IndexController->indexAction( ) ..\Action.php:419
8 1.9247 11400536 Mage_Core_Model_Abstract->load( ) ..\IndexController.php:10

In this instance My Module Class’ model was in the correct location, but the name of the class for the model didn’t match the expected name Magento was hunting for:

<?php
class MyModuel_Complexworld_Model_Resource_Eavblogpost
extends Mage_Eav_Model_Entity_Abstract
{

}

Can you spot the problem in the code above? Yeah, a simple misspelling can cause a lot of grief in this system!  This hasn’t bit me yet, but I anticipate it will the more I trudge through this mammoth system.

EAV Resource Models

In Magento, resource model classes that rely on the EAV model are required to extend from Mage_Eav_Model_Entity_Abstract. 

If you instead extend from the standard model (Mage_Core_Model_Abstract) you’ll end up with an error such as this:

Resource is not set.
#0 Abstract.php(136): Mage::throwException('Resource is not...')
#1 Abstract.php(225): Mage_Core_Model_Abstract->_getResource()
#2 Abstract.php(225): Mage_Core_Model_Abstract->load(Object(MyModule_ComplexWorld_Model_Eavblogpost), 1, NULL)
#3 IndexController.php(10): Mage_Core_Model_Abstract->load(1)
#4 Action.php(419): MyModule_Complexworld_IndexController->indexAction()
#5 Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('index')
#6 Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#7 App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
#8 Mage.php(683): Mage_Core_Model_App->run(Array)
#9 index.php(87): Mage::run('', 'store')
#10 {main}

Here is the code that generated this error:

<?php

class MyModule_Complexworld_Model_Resource_Eavblogpost

extends Mage_Core_Model_Abstract

//This should be Mage_Eav_Model_Entity_Abstract

{

}

Setting Developer Mode in Magento outputs Errors to screen

 

I updated the <VirtualHost> element in my Apache configuration file (apache/conf/extra/httpd-vhosts.conf) to include the environment variable “MAGE_IS_DEVELOPER_MODE”:

<VirtualHost *:80>
    documentroot "c:/xampp/htdocs/magento"
    servername magento.server.dev
    SetEnv MAGE_IS_DEVELOPER_MODE "1"
</VirtualHost>

By doing this, I can see any error that may have occurred during process of request.  This was done as a result of following the Magento For Developers: Part 5 – Magento Models and ORM Basics, which led me to the Wiki article Configure Magento error page, and a StackOverflow article discussing how to set up the environment variable.

As stated in the Wiki article, Magento handles outputs this way to eliminate the need of changing the index.php file for a production, staging or development server.

On the XAMPP War-Path…

Pulling my head out of the Windows stack for a while, not that ASP.NET doesn’t work for me – it does; I’m simply tasked to support another stack.  A world somewhat foreign to me.  The world of Apache, MySQL, and PHP.  Not sure what the X and P surrounding the AMP stand for if that’s any indication to how new I am at this.

So I downloaded XAMPP and installed it on my Windows 7 64bit OS.  I didn’t run anything as a service because I didn’t want to add additional processes to my start-up routine.  So I tried to fire up the Apache service from the XAMPP Control panel (v.3.0.12) and it starts and immediately shuts down.  I have my suspicions that it may be conflicting with my IIS utilizing port 80.  So I step into the config file (httpd.conf) and change the port and now I’m up and running it appears.

image

If you are a XAMPP guru or even a PHP guru, let me know as I’m about to perform the equivalent of swimming across the English Channel and would like a personal floatation device to keep me bouyed in this endeavor.