|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2006-09-27 15:34 UTC] rachmel at avaya dot com
Description:
------------
When changing the Linux's timezone (changing /etc/localtime) to something other than CEST and running php script with date related functions, the php crashes and causes a segmentation fault.
Reproduce code:
---------------
<?php
echo date("l");
?>
Expected result:
----------------
should print the current day of the week.
Actual result:
--------------
segmentation fault (core dumped)
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 15:01:29 2024 UTC |
When not setting the default time zone, php seems to use the localtime, as defined on Linux. Even when setting the timezone with date_timezone_default_set() , for example, with the value of "Pacific/Fiji" , i get a segmentation fault when I call date("1"), or any other date related function. Does php use Linux's timezone files?I am not sure I can do that - in the meantime, it seems that if php has a default timezone conigured, it ignores the localtime definitions on the Linux kernel. However, if I change the default timezone to "Pacific/Fiji" for example, i can reproduce the crash with a call to "date("1"). it is interesting, that a call to phpinfo() doesn't crash, although it does display the time zone chosen. Are there any leads you can think about that might cause this problem? Where in the php code can I find the date function, so I can try and debug it from there? Thanks.Hi, I think I found the problem. in one of the date extention files: parse_tz.c , there is a conversion macro called: timelib_conv_int() that has two modes - depends if WORDS_BIGENDIAN is defined or not. I located the test that defines it in the php configure file, and it looks like this: echo $ac_n "checking whether byte ordering is bigendian""... $ac_c" 1>&6 echo "configure:43563: checking whether byte ordering is bigendian" >&5 if eval "test \"`echo '$''{'ac_cv_c_bigendian_php'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else ac_cv_c_bigendian_php=unknown if test "$cross_compiling" = yes; then ac_cv_c_bigendian_php=unknown else cat > conftest.$ac_ext <<EOF So, what happens is - i cross compile, and then the bigendian becomes uknown => the WORDS_BIGENDIAN is not defined => the timezone database is read in the wrong way => malloc tries to use that information to allocate memory and fails. Can you explain why it is that way?