php 5.2.0 update problem

Hi,

today we've tried to upgrade our server from php 5.1.6 to 5.2.0. After this no one is able to log in anymore, neither customers nor admins. We've reverted back now to 5.1.6 and everything is working fine like before. Nevertheless we would like to upgrade because of all the bugs and security issues in php <= 5.1.6. Does anyone know what the problem with ZC and php 5.2.x could be?

Also: if a customer requests a new password (with php 5.2) the password is send but when trying to use it/log in then apache is closing the connection and php is throwing the same error all the time:

[03-Nov-2006 13:39:48] PHP Fatal error: Call to a member function Execute() on a non-object in /xxx/includes/functions/sessions.php on line 61

which is

 $total = $db->Execute($qid);

in ZC 1.3.x

So neither old passwords or new ones can be used with php 5.2.0 :huh:

Thanks for any help!

What are your compile-options and php.ini options related to sessions settings in your 5.2.0 setup ?

hi DrByte, our php.ini settings have not been changed for 2 years or so since php 4.3.x or so, IIRC. The session related settings are:

www:~ # php -i | grep -i session
session
Session Support => enabled
session.auto_start => Off => Off
session.bug_compat_42 => On => On
session.bug_compat_warn => On => On
session.cache_expire => 30 => 30
session.cache_limiter => nocache => nocache
session.cookie_domain => no value => no value
session.cookie_lifetime => 0 => 0
session.cookie_path => / => /
session.cookie_secure => Off => Off
session.entropy_file => no value => no value
session.entropy_length => 0 => 0
session.gc_divisor => 100 => 100
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 1 => 1
session.hash_bits_per_character => 5 => 5
session.hash_function => 0 => 0
session.name => PHPSESSID => PHPSESSID
session.referer_check => no value => no value
session.save_handler => files => files
session.save_path => /tmp => /tmp
session.serialize_handler => php => php
session.use_cookies => On => On
session.use_only_cookies => Off => Off
session.use_trans_sid => 0 => 0
WDDX Session Serializer => enabled

php gets compiled as always for apache worker 2.x, the same applies since about 2 years but now we're using apache 2.2.3 on an Opteron system with 1MB RAM (hence the lib64 param but otherwise nothing's been changed in the configure at all, I'm using a script for it so no error on this part, mysql version is 4.1.21 BTW), here are the php ./configure options:

Configure Command => './configure' '--with-libdir=lib64' '--prefix=/usr/share' '--bindir=/usr/bin' '--datadir=/usr/share/php' '--includedir=/usr/include' '--infodir=/usr/share/info' '--libdir=/usr/share' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--mandir=/usr/share/man' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--with-apxs2=/usr/sbin/apxs2-worker' '--with-config-file-path=/etc' '--with-cyrus' '--with-dom=/usr' '--with-exec-dir=/usr/lib/php/bin' '--with-layout=GNU' '--with-_lib=lib' '--with-bz2' '--with-curl' '--with-db4' '--with-expat-dir=/usr' '--with-ftp' '--with-gd' '--with-gd-dir=/usr/local/lib' '--with-gdbm' '--with-gettext' '--with-gmp' '--with-freetype' '--with-freetype-dir=/usr' '--with-iconv' '--with-jpg' '--with-jpeg-dir=/usr' '--with-ldap' '--with-mcal=/usr' '--with-mcrypt' '--with-mhash' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-ncurses' '--with-ndbm' '--with-openssl' '--with-pcre-regex' '--with-pear=/usr/share/pear' '--with-png' '--with-png-dir=/usr' '--with-readline' '--with-regex=php,apache,system' '--with-snmp=/usr' '--with-tiff-dir=/usr' '--with-ttf' '--with-xml' '--with-xml-rpc' '--with-xpm-dir=/usr/X11R6' '--with-xslt-sablot' '--with-zlib' '--with-zlib-dir=/usr' '--without-oci8' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-dbx' '--enable-dio' '--enable-discard-path' '--enable-exif' '--enable-fastcgi' '--enable-filepro' '--enable-ftp' '--enable-force-cgi-redirect' '--enable-gd-imgstrttf' '--enable-gd-native-ttf' '--enable-inline-optimization' '--enable-maintainer-zts' '--enable-mcal' '--enable-magic-quotes' '--enable-mbstr-enc-trans' '--enable-mbstring' '--enable-mbregex' '--enable-memory-limit' '--enable-pic' '--enable-shmop' '--enable-sigchild' '--enable-sockets' '--enable-sysvsem' '--enable-sysvmsg' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-ucd-snmp-hack' '--enable-wddx' '--enable-xslt' '--enable-yp' '--enable-zend-multibyte' '--disable-debug'

Additionally we use imap and pdflib modules plus eaccelerator, but even without all that the error from line 61 remains. Otherwise the shop is loading fine, it's just the login that doesn't work but I didn't have time to check everything since the shop has to be operational so I went back to 5.1.6 for now. Because there are no other errors then I guess something must have been changed which breaks the ZC login in some way. Been looking around in open bugs/php.net but couldn't find anything related yet ... :sleepy:

Oops, sorry, I meant 1GB RAM of course ;)

ca18:

Been looking around in open bugs/php.net but couldn't find anything related yet ...

Well ... it was only released yesterday.

Yes, but they had some problems and there where several RC's so I guess not much(other than the security issues reported by Esser etc) should've changed since the latest RC. So any 5.2.0 problems, RC or not, should be known by now with the "final".

The only one similar would be this one:

http://bugs.php.net/bug.php?id=39331

I got the exact same error after upgrading to php v5.2.0 this morning. Looks like $db is not initialized in session.php?

Thanks for the info linksys, at least I'm not alone with it now :smile:

linksys:

I got the exact same error after upgrading to php v5.2.0 this morning. Looks like $db is not initialized in session.php?

Yes, it is, on line 51 (as far as line 61 is concerned).

DrByte:

Yes, it is, on line 51 (as far as line 61 is concerned).

Or the new PHP altered the behavior of the "global" statement so the value of $db is not passed into functions or got overwritten?

I am poking around in the code...just baffled. Interesting...

I just installed PHP 5.2.0 on a test windows machine running IIS, along with Zen Cart v1.3.6, and it works without any errors.

I have found something interesting:

http://drupal.org/node/61900

DrByte:

I just installed PHP 5.2.0 on a test windows machine running IIS, along with Zen Cart v1.3.6, and it works without any errors.

I have a little different setup:

1. On CentOS 4.4
2. Upgraded from Zencart 1.3.5.0.2 to v1.3.6. Worked all good with PHP 5.1.6

Then I upgraded PHP to 5.2.0 and got this error.

SuSE 10.0 with kernel 2.6.x.y here.

ca18:

I have found something interesting:

http://drupal.org/node/61900

Hey DrByte, I think the above link likely addresses the same issue here. Look at the "Finally Tracked This Down" part and the "Problem Background" part:

Finally Tracked This Down

This is a bug PHP's behavior with global variables. I have a simplified test case which shows the problem in operation and offers a fix.

This has been hard to resolve - this "login issue" can manifest itself from other bugs that involve session ID's and cookies. This is yet another issue.

Looks similar. I don't see a resolution there that's of much use to anyone other than the PHP folks ... :mellow:

I put a var_dump($db) before line 61 in sessions.php and it printed NULL.

The question is, why this global variable issue only affects the session code? Other zen-cart functions all work well - browsing products, adding to cart, etc... I would expect other functions also use "global" to pass in class objects, don't they?

:sleepy: My clients on my server also have the same issue... There seems to be a issue with ZenCart and php-5.2. In order to correct the issue I had to roll back php to 5.1.6.

Any Idea when a fix/patch will be released?

If one of you is interested in providing me with FTP+admin access to your PHP 5.2.0 server, I'll be happy to debug and come up with a solution.

PM me with details and I'll look at it this evening ...