|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38975 date() function causes php crash
Submitted: 2006-09-27 15:34 UTC Modified: 2007-04-16 06:10 UTC
Avg. Score:4.4 ± 1.2
Reproduced:10 of 10 (100.0%)
Same Version:3 (30.0%)
Same OS:3 (30.0%)
From: rachmel at avaya dot com Assigned:
Status: Wont fix Package: Reproducible crash
PHP Version: 5.1.6 OS: WindRiver Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2006-09-27 15:34 UTC] rachmel at avaya dot com
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:
echo date("l");


Expected result:
should print the current day of the week.

Actual result:
segmentation fault (core dumped)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-27 15:45 UTC]
Please try using this CVS snapshot:
For Windows:

 [2006-10-03 11:54 UTC] rachmel at avaya dot com
Tried the latest CVS version - still crashes, using the same code.
 [2006-10-03 15:14 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read for *NIX and for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

 [2006-10-10 20:21 UTC] makavy at avaya dot com
I'm adding information about this bug as I'm working with the BUG originator (Nir).
- This occurs on a powerpc (ppc) processor
- The zoneinfo files where created using zic.
  (Maybe zic has problems with ppc, or maybe it's big-little endian issues with the zineinfo files...????)

The backtrace looks like this:
(gdb) backtrace
#0  0x0f88cb7c in memcpy () from /lib/
#1  0x0f885eb0 in malloc () from /lib/
#2  0x1008f1c0 in timelib_parse_tzfile ()
#3  0x1006c714 in get_timezone_info ()
#4  0x1006c714 in get_timezone_info ()
#5  0x1006c714 in get_timezone_info ()
#6  0x1006c714 in get_timezone_info ()
#7  0x1006c714 in get_timezone_info ()
#8  0x1006c714 in get_timezone_info ()
#9  0x1006c714 in get_timezone_info ()
#10 0x1006c714 in get_timezone_info ()
#11 0x1006c714 in get_timezone_info ()
#12 0x1006c714 in get_timezone_info ()
#13 0x1006c714 in get_timezone_info ()
Previous frame inner to this frame (corrupt stack?)

As you can see there is something wrong with gdb on ppc, we have a script that reconstructs the backtrace, and the output looks like this:
(gdb) bt_script
frame #: stack_frame_ptr        backchain_ptr   LR_save_word
frame 0: 0xXXXXXXXX:            0xXXXXXXXX      $1 = 0xf88cb7c <memcpy+324>
frame 1: 0x7fffce10:            0x7fffce20      $2 = 0x18000000
frame 2: 0x7fffce20:            0x7fffce40      $3 = 0xf885eb0 <malloc+200>
frame 3: 0x7fffce40:            0x7fffcea0      $4 = 0x1008f1c0 <timelib_parse_tzfile+472>
frame 4: 0x7fffcea0:            0x7fffced0      $5 = 0x1006c714 <get_timezone_info+228>
frame 5: 0x7fffced0:            0x7fffcf90      $6 = 0x1006c818 <php_format_date+128>
frame 6: 0x7fffcf90:            0x7fffcfc0      $7 = 0x1006d9d4 <zif_date+128>
frame 7: 0x7fffcfc0:            0x7fffd030      $8 = 0x102da424 <zend_do_fcall_common_helper_SPEC+3224>
frame 8: 0x7fffd030:            0x7fffd120      $9 = 0x102d9660 <execute+484>
frame 9: 0x7fffd120:            0x7fffd280      $10 = 0x102ae0b8 <zend_execute_scripts+392>
frame 10: 0x7fffd280:           0x7ffff580      $11 = 0x10251a30 <php_execute_script+688>
frame 11: 0x7ffff580:           0x7ffff9e0      $12 = 0x1035cdb4 <main+4276>
frame 12: 0x7ffff9e0:           0x7ffffc00      $13 = 0xf82f940 <__libc_init_first+328>
frame 13: 0x7ffffc00:           0x7ffffc10      $14 = 0xf82fa80 <__libc_start_main+196>

 [2006-10-11 10:02 UTC]
I can not reproduce this at all. You didn't quite mention which timezone you are using, and did you set the timezone in php with the php.ini setting "date.timezone" or the function date_timezone_default_set()? Please provide more information.
 [2006-10-12 19:23 UTC] makavy at avaya dot com
It does not matter which timezone I use. any one of the files that 'zic' creates has this problem.

What i did to set the time zone is create a symbolic link to one of the zoneinfo files:
/etc/localtime -> /usr/share/zoneinfo/[Continent]/[city]

I did not do anything in php.ini file, or issue a php command for that.
 [2006-10-12 21:26 UTC]
Well, PHP doesn't give a damn about that :) If you request a page with just "error_reporting(E_ALl);phpinfo();" in it, what will it show as timezone? 
 [2006-10-16 18:24 UTC] rachmel at avaya dot com
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?
 [2006-10-16 18:30 UTC]
Please provide an account on a WindRiver Linux machine for debugging.
 [2006-10-18 16:52 UTC] rachmel at avaya dot com
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?

 [2006-10-18 16:57 UTC]
date() is in ext/date/php_date.c
And I don't see any problems on all OSes around, including 5 Linuxes on different architectures.
 [2006-10-18 17:00 UTC] rachmel at avaya dot com
ok, I will look into it.
Do you think that using the timezonedb upgrade should make any difference?

 [2006-10-18 17:04 UTC]
No, I don't think it matters.
 [2006-10-25 10:41 UTC] rachmel at avaya dot com

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

  if test "$cross_compiling" = yes; then
  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?
 [2007-04-13 14:31 UTC]
We don't support cross compilation. Feel free to come up with a patch yourself though.
 [2007-04-15 06:44 UTC] rachmel at avaya dot com

Well, changing the above lines in the configure script to:

if test "$cross_compiling" = yes; then

fixed the bug for us. 


 [2007-04-16 06:10 UTC]
Right, but that would possibly break it for others of course...
 [2010-10-16 19:22 UTC] zeyar dot oo dot p at gmail dot com
My whole site was crashed after updating PHP and CSS scripts. And server replies by saying "Zero Sized Reply". Please let me know how to debug this problem. Can third party javascripts bring your script to a crash?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 21 14:01:33 2024 UTC