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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
