#38975 [Com]: date() function causes php crash

ID: 38975 Comment by: makavy at avaya dot com Reported By: rachmel at avaya dot com Status: Feedback Bug Type: Reproducible crash Operating System: WindRiver Linux PHP Version: 5.1.6 New Comment: 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 Previous Comments: ------------------------------------------------------------------------ [2006-10-03 15:14:33] tony2001@php.net 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 http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php 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-03 11:54:42] rachmel at avaya dot com Tried the latest CVS version - still crashes, using the same code. ------------------------------------------------------------------------ [2006-09-27 15:45:27] tony2001@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip ------------------------------------------------------------------------ [2006-09-27 15:34:34] 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) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=38975&edit=1