Description: ------------ Hi, I noticed that use of after() and before() methods of the Date class can lead to crashes on PHP (4.3.3, 4.3.8)/Apache (1.3.21 and 1.3.31) /Win XP (SP1). On Linux it seems to work fine, but I didn't have the time yet to test if the performance are o.k. with using the methods I mentioned. This was first noticed on complex script so it was hard to isolate the problem as it didn't occur every time I loaded the script. It seems to me that it could be some infinite loop. Reproduce code: --------------- 10 Loops of checking if some date is between 2 other dates crashes PHP. It works with less loops too but it is not so regular. <?php require_once('Date.php'); $date = new Date(); for ($i = 0; $i < 10; $i++) { $start_date = new Date('2003-12-05'); $end_date = new Date('2004-08-31'); $open = ($date->after($start_date) || $date->equals($start_date)) && ($date->before($end_date) || $date->equals($start_date)); echo "Result: $open<br />"; } ?> Expected result: ---------------- Expected to see result but PHP crashes.

It's 3am. I've just spent 3 hours trying to debug our PHP before finding out that the bug was actually in PEAR... At least change the status of this package away from "stable". This is a serious bug. And I am not a happy bunny.

Oh by the way, the problem is due to repeatedly calling Date_TimeZone::inDaylightTime(). The getenv/putenv approach to time zone conversion obviously has problems.

This happens even if it's called once per page load, provided that page gets enough traffic. Guess it fights over get/putting the env variables.

This isn't just a win32 problem. Happens on Debian Linux here..

On 11/3/2004, "rj at audioscrobbler dot com" <pear-dev@lists.php.net> wrote: >page gets enough traffic. Guess it fights over get/putting the env >variables. We cannot fix php bugs in date. >Oh by the way, the problem is due to repeatedly calling >Date_TimeZone::inDaylightTime(). The getenv/putenv approach to time >zone conversion obviously has problems. Actually no other way to manage the TZ "safely", in a result point of view. >finding out that the bug was actually in PEAR... A php crash is _not_ a PEAR::date (or any other php script) bug. >At least change the status of this package away from "stable". > This is a serious bug. And I am not a happy bunny. As said before, sorry, but not up to date. Date is _stable_. Note that I cannot reproduce the php crashes using apache2 and php4.3.8 on linux. I do not have a apache1 to try it, can you give a try with apache2 on windows? I set it on feedback even it is bogus (not a date issue). Until I can localize the real problem (env or other things) and then move to php bugs. I can try to reproduce it next week with apache1 --Pierre

Here's the PHP and Apache versions we were having this problem on: www:~# /usr/local/apache/bin/httpd -v Server version: Apache/1.3.32 (Unix) www:~# php -v PHP 4.3.9 (cli) (built: Nov 3 2004 01:27:52) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov with Advanced PHP Debugger (APD) v0.9.1, , by George Schlossnagle The server is diskless, and netboots from a debian image on another debian box.

Give it a try without Turck MMCache and without APD. If it still crashes post a comment here. I will try to make a short script to reproduce this problem. If not try with apd and MMcache (not together), if one (or both) raises a segv, post a bug into the respective helpdesk system (pecl.php.net for apd). and close this bug. Regards, --Pierre

I've also had this problem - It was intermittent and crashing my php (4.3 on IIS6/Win2003 ISAPI) with a mix of HTTP 500 error and PHP Access Violation. The solution was replacing this function (new version shown here) in TimeZone.php function inDaylightTime($date) { return date("I"); // line added $env_tz = ""; if(getenv("TZ")) $env_tz = getenv("TZ"); putenv("TZ=".$this->id); $ltime = localtime($date->getTime(), true); putenv("TZ=".$env_tz); return $ltime['tm_isdst']; } Credit to Yves, who posted this solution here: http://www.phpwsforums.com/archive/index.php/t-526.html

I've been banging my head against this one for a while too (see http://bugs.php.net/bug.php?id=32422) Might I suggest that, even though this is a php (or even a msvcrt) bug, the Date::inDayLightTime documentation is changed to say something along the lines of "WARNING: this has been known cause intermittent access violation crashes" rather than "may not work". At least that would save a few headaches.

I was having issues with php crashing apache on freebsd. After debugging it, I saw that it was related to the putenv function which is used in the inDaylightTime function. The problem occurs when it attempts to set the environment variable, in this case TZ, back to a NULL value. The solutions I came up with was to set the environment variable, TZ, to the $id used when creating the Date_TimeZone class. function Date_TimeZone($id) { global $_DATE_TIMEZONE_DATA; if(Date_TimeZone::isValidID($id)) { putenv("TZ=".$id); # Bug Fix $this->id = $id; $this->longname = $_DATE_TIMEZONE_DATA[$id]['longname']; $this->shortname = $_DATE_TIMEZONE_DATA[$id]['shortname']; $this->offset = $_DATE_TIMEZONE_DATA[$id]['offset']; if($_DATE_TIMEZONE_DATA[$id]['hasdst']) { $this->hasdst = true; $this->dstlongname = $_DATE_TIMEZONE_DATA[$id]['dstlongname']; $this->dstshortname = $_DATE_TIMEZONE_DATA[$id]['dstshortname']; } else { $this->hasdst = false; $this->dstlongname = $this->longname; $this->dstshortname = $this->shortname; } } else { $this->id = 'UTC'; $this->longname = $_DATE_TIMEZONE_DATA[$this->id]['longname']; $this->shortname = $_DATE_TIMEZONE_DATA[$this->id]['shortname']; $this->hasdst = $_DATE_TIMEZONE_DATA[$this->id]['hasdst']; $this->offset = $_DATE_TIMEZONE_DATA[$this->id]['offset']; } } I'm not sure if this will produce a solution for everybody else, but it works for me.

As soons as you removed ENV usages, you solve part of the problem yes (put/setenv are not thread safe).

marking as "No Feedback" please re-open if the issue persists