php segfault using php 5.3 and Zend Loader 5.5.0

[zvika]

Hi

There might be incompatibilities between encoded files generated by latest zendenc53 and PHP 5.3.2 - or older zendenc53 generated files and PHP 5.3.3 and above.

Please install Zend Server and try the encoded application again.

If you cannot install Zend Server for any reason (will replace distro PHP on the target server),
you can try backported PHP5 packages from a higher Ubuntu distro PPA (see the following question for example):
http://askubuntu.com/questions/77468/ho ... -mysql-5-5

The most supported stack for Zend encoded applications is Zend Server, which includes PHP 5.3.9 in the latest version 5.6.

If you need sample PHP 5.3 encoded scripts for testing, send me a PM.

[stuckmojo]

There might be incompatibilities between encoded files generated by latest zendenc53 and PHP 5.3.2 - or older zendenc53 generated files and PHP 5.3.3 and above.

What does that mean exactly?

How much versions of zendecn53 exists? Is there really more than one?

Encoded files will not work on 5.3.2 and higher?!

Please bring some ligth into that statements... they are scary :-/

[zvika]

Hi Stuckmojo

Here is a summary for the old / new command line binaries:

1. On Linux, there are 2 sets of binaries in Zend Guard 5.5 release.

New executable: /path/to/ZendGuard-5_5_0/plugins/com.zend.guard.core.resources.linux.x86_5.5.0/resources/bin/zendenc53
Old executable: /path/to/ZendGuard-5_5_0/plugins/com.zend.guard.core.resources.linux.x86_5.5.0/resources/zendenc53

2. New binaries - are the ones to use for PHP 5.3.3 and above.

3. Old binaries - are still there in case someone needs to encode for PHP 5.3.2.

4. Guard License: If you start using the new binaries (starting out with command line encoding if you used the GUI so far), copy the zend_guard.zl from resources/ dir to resources/bin/ dir so it will be recognized and not run in evaluation mode.

Most of the encoded applications are working fine with both binaries.
We recommend to try alternative zendenc53 in case broken PHP code segment is identified and reported to us as a bug, until we debug and fix the issue.

Hope this answers your concerns.

[hen3265]

Hi zvika,

we also compiled on our developer machine (PHP 5.3.3) for the target machine (also PHP 5.3.3) with the default ZendGuard-5_5_0/bin/zendenc53 which seems to use the old version (resources/zendenc53) of the compiler and, in some cases, got segmentation faults running the compiled code.

So now I tried to compile with resources/bin/zendenc53 and compiling seemed to work fine...
...if the compiled code will work without segfaulting... we'll see tomorrow.

But I have another question:

What if a customer runs PHP 5.3.2 (Remember: Our dev machine has 5.3.3) and we like to compile for the target machine (5.3.2) on our dev machine (5.3.3), which compiler version do we need to use then to not get segfaults? - resources/zendenc53 or resources/bin/zendenc53 ?

Or do both systems, dev and target system need to run the same versions of PHP ?
Or do both need to run either PHP <= 5.3.2 or both need to run PHP >= PHP 5.3.3 ?

8<----- Snip 8<-----

Btw.: Imho this subject should be mentioned in the Zend-Guard-Release-Notes-v5-5.txt under "2. Known issues and Limitations"

Many thanks in advance,
yours Henri Schomäcker

[zvika]

Hi

Most users should already have PHP 5.3.3+ versions since many bugfixes where introduced.
Zend Server which is the most supported runtime for Zend Guard on PHP 5.2/5.3 already contains later versions for long time,
so another option is to suggest your users to use Zend Server as runtime PHP for Guarded applications.

If there is a client still running PHP 5.3.2, and if you get a segfault report from them,
the first thing is to provide a full / trial application encoded with resources/zendenc53 (old binaries).
The segfault might come from other reasons, and might not appear at all - depending on the PHP code and encoding / runtime options and environments.

I hope this helps.

[dom6084]

Hi,

I am trying to get a commercial PHP application running; it's installed inside /main.
So with /main/index.php it does not segfault, but as soon as a parameter string is passed (even if meaningless) it does.
Examples:
/main/index.php?foo=bar :- segmentation fault.
/main/info.php?foo=bar :- OK.
/main/login.php :- segmentation fault
(info.php is encoded, but just runs phpinfo();)

O/S is Debian 6.0.6, a "vanilla" installation with PHP, Apache, etc added. No control panel.
Kernel is 2.6.32-5-amd64 #1 SMP Mon Feb 25 00:26:11 UTC 2013 x86_64
PHP is PHP 5.3.3-7+squeeze14 with Suhosin-Patch (cli) (built: Aug 6 2012 14:18:06)
loader is ZendGuardLoader-php-5.3-linux-glibc23-x86_64 / php-5.3.x / ZendGuardLoader <dot> so
PHP code is definitely encoded for PHP 5.3.
Apache Server version: Apache/2.2.16 (Debian)

"This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH"

Any ideas?