Un bug de PHP 5.2.6 hace que, si instalas Zend Optimizer 3.3.9 con Zend Debugger 20110410 (probado en Debian GNU/Linux de 32bits), cuando cargas cualquier página compilada con Optimizer por segunda vez y posteriores (sólo funciona la primera carga), se produzca un «segmentation fault». El error que muestra al usuario es que el servidor cerró la conexión, pero en el error.log se ve el segmentation fault.
Después de seis horas investigando y haciendo pruebas y de comprobar que todo estaba bien instalado, descubrí que la solución es fácil, actualizar PHP. Pero cuidado…
Zend Optimizer sirve para poder utilizar código PHP compilado y cifrado para que sea imposible modificarlo o leerlo, es decir, Optimizer es una protección contra copias para vender código PHP privativo.
Para el que esté usando un código compilado, en nuestro caso un cliente que tiene un servidor dedicado con varios webs desarrollados con MOTO CMS, el Zend Optimizer es totalmente imprescindible o dejan de funcionar las webs, por tanto, hay que dejarlo instalado.
Ahora, el problema surgió cuando cuando nuestro cliente nos solicitó que instaláramos un depurador de código, nuestra primera opción es siempre Xdebug, un depurador de código abierto, que lamentablemente es incompatible con Zend Optimizer, así que probamos con Zend Debugger, con la errónea suposición de que al ser ambos de Zend iba a funcionar.
Llegados a este punto y tras horas tratando de hacer que funcionara con paquetes oficiales, vimos que la única opción razonable era pasar a PHP 5.3, pero antes de hacer esto en un servidor en producción, procedí a hacer pruebas en otro servidor con esta «problemática» versión de PHP ya instalada, y esto fue lo que descubrí.
Bien, Zend ha cambiado su herramienta para compilar y proteger código, que ahora se llama Zend Guard en vez de Optimizer (un nombre mucho más adecuado), pero hay más cambios y precisamente tienen que ver con el paso de PHP 5.2 a PHP 5.3.
Zend Optimizer sólo funciona en php 5.2 y anteriores y Zend Guard sólo funciona en PHP 5.3 y posteriores, así que al pasar a la versión 5.3, la única opción viable es cambiar Optimizer por Guard runtime. Por si queda alguna duda, intenté arrancar Optimizer en PHP 5.3 y como ya suponía, ni se carga.
Y aquí viene el problema, los archivos protegidos con Zend Optimizer, son incompatibles con Zend Guard, si intentas ejecutarlos te devuelve esta error:
Fatal error: Incompatible file format: The encoded file has format major ID 1, whereas the Loader expects 4
Esto significa, que antes de pasar a PHP 5.3 es necesario hablar con el proveedor del software privativo y pedirle una versión compatible con Zend Guard y además, habrá que hacer la actualización a PHP 5.3 y luego trabajar uno por uno en todos los webs que utilizaban Optimizer para pasarlos a Guard, eso, si el proveedor tiene una nueva versión compilada para Zend Guard.
Aun en el caso de que no hubiéramos necesitado un depurador, el solo hecho de plantearse pasar de PHP 5.2 a PHP 5.3 en un servidor en producción, es una pesadilla, porque este es sólo un ejemplo más de los muchos problemas que supone una actualización de esta revisión de PHP. Otro ejemplo también publicado aquí, es sobre el gestor de virtuales VCHS2, que deja de funcionar con este cambio de revisión de PHP.
También quiero aprovechar este ejemplo para llamar la atención sobre las desventajas de usar programas privativos, en esta ocasión, pagar por usar un CMS comercial se castiga con la imposibilidad de usar el depurador que te de la gana, de hecho con la imposibilidad de usar cualquier depurador, y se castiga con la imposibilidad de actualizar el sistema operativo (ya que supondría también el cambio a PHP 5.3).
El castigo al que legítimamente paga las licencias es hacerle la vida imposible por la desconfianza del vendedor y para regocijo de Zend que vende su aplicación de cifrado de código como una suscripción anual de nada menos que 600€, lo que podría conducir a que si el desarrollador baja sus ventas, la aplicación quede sin soporte, con las consecuencias que ya hemos visto.
Por otro lado, creo que PHP se merece un tirón de orejas por los excesivos cambios de lo que debería haber sido una simple revisión, porque muchas programaciones dejan de funcionar al actualizar a la versión 5.3 y al contrario que sucede en los cambios de versión, por ejemplo de PHP 4 a PHP 5, mantener una revisión 5.2 es imposible usando los paquetes de la distribución (a no ser que decidas compilar el Apache, algo poco práctico), porque en cuanto pasas un upgrade al sistema operativo instala automáticamente la revisión 5.3. Con todo el respeto que le tengo al PHP, tengo que decir que esto ha sido un terrible error.
Finalmente, sin una solución fácil, hemos optado por olvidarnos de instalar un depurador en este servidor y usar otro sin Zend Optimizer ni Zend Guard para ese propósito.
Edgar Alvarez
Que has usado en lugar de Zend Optimizer ni Zend Guard ? yo tengo el mismo problema que tu, y no doy con la solución
Juan
No he encontrado solución, pero voy a probar con PHPFarm a ver si puedo dejar los virtuales de MOTO CMS con PHP 5.2 y hacer que el resto funcione en PHP 5.3.