Oddity in PHP 4.0.5?

[PaulKroll]

A previously working script is now dying badly. Specifically, there's a line of the form:


$user['UserName'] = $CodeID;

Where CodeID is a 5 or six digit code: whatever I do, $user['UserName'] ends up being only the first digit of the $CodeID.

Of course, this is part of a session: it works fine if it's not. In other words, the complete test to see this atrocity is:

<?php
session_register('user');

$user['UserName'] = &quot;this is[nbsp][nbsp]a test&quot;;
print $user['UserName'];
?>
I'm a little preturbed at the PHP folks right now to say the LEAST...

[Arthur]

I haven't tested on version 4.05 yet, but I can't reproduce the behaviour you describe in version 4.06 (win32 dev. version).

Arthur

[PaulKroll]

...which is better than hearing that you can, frankly. :)

I'm compiling PHP 4.0.6 current dev release on a little local Linux machine to try it out, and will then try compiling 4.0.5 to compare and make sure: I filed a bug report w/PHP.net, and the first thing one of the developers said is &quot;I can't reproduce this in 4.0.6&quot; which, again, is better than hearing it's still a problem, but I want to know how this happened in the first place, and part of that is being able to say to the PHP folks &quot;yes, I CAN reproduce the bug from a fresh install of PHP 4.0.5&quot;

Now, the problem is that the little Linux machine I've got behind me is a 233 Mhz Pentium w/31 Meg/RAM, so this compile is taking FOREVER... :)

[PaulKroll]

Wow. This was interesting.

After trying despertately to reproduce this locally and having no success, I did a session_destroy() at the end of it, and refreshed.[nbsp][nbsp]That did it.

The serialized sessions that are hanging around from the previous, 4.0.4 version, are apparently subtley different from the 4.0.5 sessions. If you have a similar problem, try destroying the session: you may have a straggler on your hands.

[Terra]

Paul, I already have PHP 4.0.5 deployed on the PHOENIX server...[nbsp][nbsp]This was done to fix a nasty memory leak that I was experiencing with PHP 4.0.4pl...

I'm just waiting for the ZendOptimizer to catch up before full deployment across all servers...

I went ahead and tested your example code above and could no reproduce the problem:
http://www.questsupport.net/a39bkd8/session_test.phps
and
http://www.questsupport.net/a39bkd8/session_test.php

Build information:
http://www.questsupport.net/a39bkd8/phpinfo.php

--
Terra
--Hmmm, memory leak or broken sessions, or my favorite - none of the above--
FutureQuest

[Rich]

If you have a similar problem, try destroying the session I've always wanted a problem where I could destroy something to fix it. :)

Rich

[PaulKroll]

I'm having deja vu: I thought I saw something come back from the dead repeatedly over the weekend, at &quot;The Mummy Returns.&quot;

Now, I have a set of pages. They're all PHP scripts, and they all use a central &quot;user&quot; registered session variable. If I destroy the session on the first page, I can make it work &quot;properly&quot; otherwise, it acts like my first example, i.e.:
$user['UserName'] = &quot;Bob&quot;;
print $user['UserName'];

Prints &quot;B&quot; and that's it.[nbsp][nbsp]Once destroyed, I can remove the &quot;session_destroy&quot; and further refreshes to the page are fine: &quot;Bob&quot; is returned in the example, above.

But as soon as it goes to the second page, the second page once again sees the username as &quot;B&quot;... I've tried destroying the session on BOTH pages, and hitting refresh about a dozen times, and deleting the cookie on my browser, and chanting, setting a circle of sulphur, reciting ancient Sumerian texts. No go.

These were running fine under 4.0.4. Sigh.[nbsp][nbsp]

Terra, I'll try to make a simplest-possible-example set and e-mail them to FQ tech support so you can confirm, or deny, my sanity. :)

[Terra]

I would rather you post up the code so that others may test as well...

If you are testing on paulkroll.com, then if you give me an hour - I can shift in the new PHP 4.0.5 onto your xIP pool...

While your at it, please see if you can break both 'mcrypt' and 'mhash' as well...[nbsp][nbsp];)

I'm giving these 2 PHP modules another shot hoping that they aren't brain damaged like they were in PHP3...

I'd rather make sure of it's sanity before deployment...

--
Terra
--If it didn't blow up right the first time - try and try again--
FutureQuest

[This message has been edited by ccTech (edited 05-08-01@2:25 pm)]

[Arthur]

I still haven't been able to reproduce it. I have tried it on 4.05 and 4.06 on Windows and Linux.
Have you had any 'luck' in tracking it down?

BTW Terra, mcrypt keep seg faulting on my Linux box (RedHat 7.1, Apache 1.3.19, PHP 4.05), haven't looked at it deeper, but you may want to keep an eye on it if/when you upgrade to the 2.4 kernel.

[Terra]

I took some time meshing in 'mcrypt' and thus far everything seems to be OK...

We are using: libmcrypt-2.4.11

All of the internal cipher 'self_test' are checking out OK...
http://www.questsupport.net/a39bkd8/mcrypt_self_test.php

Sam is currently looking deeper into our mcrypt functionality as PHP + Crypto is more in his skillset than mine...

If it does start segfaulting, I will have no hesitation in pulling this module once again...[nbsp][nbsp]The problem with in in PHP3 was 'memory scribbling' by going out of bounds and causing intermittent havoc that was extremely difficult to reproduce/isolate...

It has heavily requested though, so I gave it another chance...

--
Terra
--Sort of like planting a stick of dynamite within the engine--
FutureQuest

[PaulKroll]

Well the long message I was leaving just got nuked by Windows, so this'll be short.[nbsp][nbsp]The $GLOBALS array used to not let you &quot;harm&quot; session variables, and now, it does. So if you're using it to, oh, loop over all the GLOBALS so any incoming GET or POST vars can be cleared of dangerous characters.... well... you'll end up wiping out the session vars, and wiping them out in such a way as to make it necessary to destroy the session before you can do anything with that variable name again.

So ultimately this was my bad. I made an assumption, which was correct for a while, and then, not so.

Could someone get me this day of my life back please? :(

Code sample below: I've run this under PHP4.04plSomething and 4.0.5, and the results are slightly different. In PHP 4.0.4, the user var and associated username don't get corrupted. In PHP 4.0.5, they do.

<?php
session_register('user');
$user['UserName'] = &quot;koala!&quot;;

foreach ($GLOBALS as $key => $value) {

[nbsp][nbsp][nbsp][nbsp][nbsp]print &quot;key = $key, value = $value
\n&quot;;
}
foreach ($GLOBALS as $key => $value) {
[nbsp][nbsp][nbsp][nbsp][nbsp]$finalglob = str_replace(&quot;'&quot;,'',$value);
[nbsp][nbsp][nbsp][nbsp][nbsp]$GLOBALS[$key] = str_replace('&quot;','',$finalglob);
}
print &quot;username = &quot; . $user['UserName'];
?>

[trafficg]

I already have PHP 4.0.5 deployed on the PHOENIX server...[nbsp][nbsp]This was done to fix a nasty memory leak that I was experiencing with PHP 4.0.4pl...

I'm just waiting for the ZendOptimizer to catch up before full deployment across all servers...
Zend Optimizer version 1.1.0 is out and it supports PHP 4.0.5, does this mean we are getting an upgrade soon :-)

Pete
Free Traffic and Website Promotion!
www.TrafficG.com (http://www.TrafficG.com)

[Terra]

Yes, I've already deployed the ZO on Phoenix - just waiting to see how well the combo stands up under production stress...

Most likely I'll roll it over the weekend...

PaulKroll:
Is the glitch you've stumbled on going to break everyone or not?
What are the boundries of the error?
Can you work around it?

If it is minimal, then I will proceed with the upgrade because I'm dealing with a PHP 4.0.4pl1 stability/memory_leak issue...[nbsp][nbsp]I don't like knowing that I'm going to break someones code, however I have to weigh the choices and go the route that benefits the most...

--
Terra
--Grappling with the choices which lead only to purgatory--
FutureQuest

[This message has been edited by ccTech (edited 05-10-01@9:23 pm)]

[pier]

F.y.i,
4.0.5 has dropped the connection_timeout() function.

So anyone using phpcache / jpcache / ..., simply remove the call to this function.

Pier
[ PHP-Documentation forgot to mention this... ]
[This message has been edited by pier (edited 05-11-01@04:37 am)]

[PaulKroll]

Sorry for the delayed response: I've been fighting (with a car for a change...)

Terra: The glitch that got me was a combination of undocumented change to PHP and an assumption on my part that the way PHP was working was the way it would always work.

Why do I picture you laughing out loud when you read that second part...

Anyhow, the specific change to PHP is this: previously, the array of all globals ($GLOBALS) would apparently allow reading and writing of MOST globals, but would not actually write to at least one specific type of global: the session_registered variables.[nbsp][nbsp]If anyone is accessing their session_registered vars through the $GLOBALS array, they need to be aware of this. If anyone is writing to the $GLOBALS array, they need to be aware of this.[nbsp][nbsp]It does not appear to be a bug: it appears the previous behavior had some exceptions that they eliminated.

I've certainly worked around the problem in my code, so I'm good to go for the ZO install.[nbsp][nbsp]It seems unlikely that many folks are writing to $GLOBALS so, um, globally, but it should probably be mentioned. I don't believe the change will &quot;break everyone&quot; but it could seriously confuse someone who IS writing to $GLOBALS and expecting their session data to be immune.