Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22498
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals <internals@lists.php.net>
In-Reply-To: <1142580493.27317.30.camel@localhost>
References: <1142580493.27317.30.camel@localhost>
Content-Type: text/plain
Date: Fri, 17 Mar 2006 02:38:57 -0500
Message-ID: <1142581137.27319.35.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.1.2 segfaults in get_timezone_info
From: abaker@php.net (Al Baker)

Ok, I'm not sure what /etc/localtime was but when I copied
over /usr/share/zoneinfo/America/New_York to /etc/localtime the problem
went away and things are working gloriously-well.

Perhaps just a note for the future that if somehow the OS didn't setup
the timezone properly, PHP should default to something rather than
segfaulting.

Regards,
Al

On Fri, 2006-03-17 at 02:28 -0500, Al Baker wrote:
> Hi,
> 
> We're trying to run php 5.1.2 on Windriver Linux (PPC) -- unsupported I
> know -- and most things appear to be working.  However when trying to
> use Smarty (which has calls to date functions for caching), PHP
> segfaults in time().
> 
> Running PHP in GDB shows the trace of failing in memcpy and malloc as
> called from timelib_parse_tzfile (timezone=0x30029008 "",
> tzdb=0x179018c) at ... ext/date/lib/parse_tz.c:91
> 
> The rest of the stack is full of calls to ext/date/php_date.c:319 and
> gdb eventually says Previous frame inner to this frame (corrupt stack?)
> 
> Looking at strace, Smarty_Compiler.class.php goes through and eventually
> does time(NULL) = 138027 a couple times and then mmap(NULL, 100667392,
> PROT_READ|PROT_WRITE, MAP_PRIVATE,MAP_ANONYMOUS, -1, 0) = 0x30029000
> followed by the SIGSEGV @ 0.
> 
> Setting date.timezone in php.ini doesn't solve the problem.  WindRiver
> keeps its timezone files in /usr/share/zoneinfo
> (e.g. /usr/share/zoneinfo/GMT).  There is also a localtime time zone
> file in /etc.
> 
> I don't know if this is a php bug, or perhaps pilot-error on my part on
> either WindRiver Linux configuration or cross-compiling PHP. 
> 
> Thanks,
> Al
>