php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #20389 user defined session handler is broken
Submitted: 2002-11-12 08:19 UTC Modified: 2002-11-29 07:33 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: scott at budomail dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4.2.3 OS: Solaris
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: scott at budomail dot com
New email:
PHP Version: OS:

 

 [2002-11-12 08:19 UTC] scott at budomail dot com 
System SunOS 5.8 Generic_108528-14
sun4u sparc SUNW,UltraAX-i2 (Solaris 8)
with Apache 1.3.24 and Apache 1.3.26

This also affects PHP 4.2.2.

If session.save_handler is set to user, the user
defined functions appear to not be called.

Furthermore - When Apache is restarted, after the
configuration directive has been set to "user"
it will very often fail to parse PHP code. I suppose
this can be considered equivalent to a crash.

My test scripts worked perfectly on my Mac OS X
development machine, so I am reasonably sure that
there is not an error in my code.

My configure command:
 './configure' '--prefix=/._ark-deploy/php--4.2.3' '--with-mysql=/._ark-deploy/mysql--3.23.51' '--with-apxs=/._ark-deploy/apache--1.3.26/bin/apxs' '--with-config-file-path=/ark/etc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot=/._ark-deploy/sablotron--0.96.1' '--with-sablot-js' '--with-expat-dir=/._ark-deploy/expat--1.95.4' '--with-gd=/._ark-deploy/gd--1.8.4' '--with-png-dir=/._ark-deploy/libpng--1.2.4' '--with-jpeg-dir=/._ark-deploy/jpeg--6b' '--with-freetype-dir=/._ark-deploy/freetype--2.1.2' '--with-java=/usr/java' '--with-ming=/._ark-deploy/ming--0.2a' '--enable-trans-sid'

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-12 08:36 UTC] derick@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-11-26 20:02 UTC] sniper@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2002-11-27 04:36 UTC] scott at budomail dot com 
The reason that I didn't feedback on the was that the suggested fix was to move to a later build of PHP for Solaris . Since all our Solaris machines are in Production I couldn't risk the upgrade.

I beleive this is still a significant problem
 [2002-11-27 06:18 UTC] wez@php.net 
You have the option of trying 4.2.3 + some fixes or trying the release candidate of 4.3.

The 4.2.x branch is as stable (or more stable) than the 4.2.3.  If we were going to release a 4.2.4, that would be it.

However, we are not going to do that; we are focusing on 4.3 instead.

There is not much more we can do for you without access to your boxes, and why should we do that?  You are the one being paid to look after your boxes, not us.

Please test a newer version as suggested so that we can determine if the problem has been corrected already.
If it has not, then someone may *volunteer* to look into the problem and resolve it.

[Remember; you can test a newer version of PHP by running a separate apache instance on another port.]
 [2002-11-27 06:24 UTC] cynic@php.net 
"The 4.2.x branch is as stable (or more stable) than the 4.2.3."

did you mean the 4.3.x branch? :)
 [2002-11-27 06:43 UTC] scott at budomail dot com 
OK, fair comment - I can do that. It's just that I had so many problems with the last upgrade that I didn't want to do it again (our system layout is *very* unusual) but your request is a reasonable one  and I would like to help - so, to clarify, we're talking about moving 4.3.0 here, right?
 [2002-11-27 07:37 UTC] wez@php.net 
The choice is yours; we'd really appreciate some feedback on the 4.3 branch, but you do have the option of the 4.2 branch.

IMO, 4.3 branch is more likely to fix the problem, but may introduce others (but is actually pretty stable, as far as we can tell so far).

Apparently, our snaps page no longer carries the 4.2 branch as the stable snap; if you want to try it, you can check it out of CVS (php.net/anoncvs.php; the branch tag is PHP_4_2).
[You will need some build tools to generate configure]
 [2002-11-27 15:50 UTC] scott at budomail dot com 
Hi. I decided to go for a snapshot, and chose the latest and greatest: php4-STABLE-200211271830.

Seems to be a bug in configure:

checking Checking for libjava... 
configure: error: unable to find Java VM libraries in /usr/java

The Java libraries on this machine have not moved since the 4.2.3 build and the configure options are identical, so I think that there is a good chance that the problem is with configure, around line 37071 - part of the libjava.so search process. Do you want a copy of the config.log?

I've run out time this evening, but I'll ahve another look at the problem soon.
 [2002-11-28 04:46 UTC] sniper@php.net 
Fixed the summary line..and you propably don't have JAVA_LIBPATH set when you get that java error..
(it's required)
 [2002-11-29 05:18 UTC] scott at budomail dot com 
Hi sniper (?),

Though I bow to your superior experience, I have to add that the location of the Java installation is being passed into configure with the --with-java option. This is what configure is for, and should be acceptable, right?

Would you like me to try to build again and copy down the exact configure line that got invoked and mail it to you? It's the same one that got called on previous successful builds.

I see that RC2 has just been released... I'll have another go with that later.

Regards,

Scott
 [2002-11-29 05:54 UTC] chregu@php.net 
Hi scott

try with --with-java=/usr/java/
and see if that helps (trailing slash problem)

I thought, this bug was fixed, i'll have a look again

chregu
 [2002-11-29 07:33 UTC] chregu@php.net 
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Hi scott

try with --with-java=/usr/java/
and see if that helps (trailing slash problem)

I thought, this bug was fixed, i'll have a look again

chregu
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat May 04 08:01:29 2024 UTC