ID: 38975
Updated by: [EMAIL PROTECTED]
Reported By: rachmel at avaya dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: WindRiver Linux
PHP Version: 5.1.6
Assigned To: derick
New Comment:
Please provide an account on a WindRiver Linux machine for debugging.
Previous Comments:
------------------------------------------------------------------------
[2006-10-16 18:24:56] 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-12 21:26:22] [EMAIL PROTECTED]
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-12 19:23:23] 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-11 10:02:56] [EMAIL PROTECTED]
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-10 20:21:45] 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/libc.so.6
#1 0x0f885eb0 in malloc () from /lib/libc.so.6
#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>
Thanks,
Erez
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/38975
--
Edit this bug report at http://bugs.php.net/?id=38975&edit=1
