On Fri, 17 Mar 2006, Al Baker wrote:
> 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.
Now that doesn't make a single bit of sense as the new date support in
PHP 5.1 just tries to *avoid* all OS related things. Copying over those
file is absolutely not going to have any effect. The
timelib_parse_tzfile() function only operates on the built-in library.
Please provide a short reproducing script that shows this segfault. if
you find one put it in a bugreport at http://bugs.php.net.
Derick
> 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
> >
>
>
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
