PHP 5.1.2 segfaults in get_timezone_info

19 years ago by Al Baker — view source

unread

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

19 years ago by Al Baker — view source

unread

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

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

19 years ago by Derick Rethans — view source

unread

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

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