Edit report at http://bugs.php.net/bug.php?id=50918&edit=1
ID: 50918 Updated by: paj...@php.net Reported by: hardon at online dot no Summary: Access violation in php.exe (Bug #49626 redux) Status: Assigned Type: Bug Package: Reproducible crash Operating System: win32 only - Windows PHP Version: 5.3.1 Assigned To: pajoye New Comment: btw, it is not windows specific, crashes occur on other platform as well. Previous Comments: ------------------------------------------------------------------------ [2010-03-17 14:52:42] paj...@php.net Yes, current work around is to actually set the timezone in php.ini ------------------------------------------------------------------------ [2010-03-17 14:48:14] progunster at gmail dot com Looks like it's the same bug. Function Arg 1 Arg 2 Arg 3 Source php5ts!guess_timezone+1c 00b2c5c8 00e4b670 00000001 php5ts!get_timezone_info+1b 00e4b670 00e531b0 00000003 php5ts!php_format_date+1b 00ad5aa4 0000000b 4ba0da0c php5ts!php_log_err+de 010d2128 00e4b670 0006fb80 php5ts!php_error_cb+385 00000020 00abf924 00000000 php5ts!zend_error+498 00000020 00abf8d4 010e46b8 php5ts!php_verror+554 00000000 00abf7f8 00000020 php5ts!php_error_docref0+23 00000000 00e4b670 00000020 php5ts!php_load_extension+146 010e40d8 00000001 00000000 php5ts!php_load_php_extension_cb+15 00e58828 00e4b670 00267d78 php5ts!zend_llist_apply+1c 00cb3bf4 0083afd0 00e4b670 php5ts!php_ini_register_extensions+25 00e4b670 0006fea8 00000001 php5ts!php_module_startup+87c 007760a8 00776048 00000001 php5apache2_2!php_apache2_startup+12 007760a8 007760a8 00000001 php5apache2_2!php_apache_server_startup+7b 0026de18 00632140 005f2068 libhttpd!ap_run_post_config+33 0026de18 00632140 005f2068 httpd+176f 00000003 00267a80 00262868 httpd+1fb2 00720065 004e0000 7ffdc000 kernel32!BaseProcessStart+23 00401ecf 00000000 78746341 ------------------------------------------------------------------------ [2010-02-07 09:49:41] j...@php.net Pierre, it's the order of init which is buggy in Windows. Works fine on all other OSes. ------------------------------------------------------------------------ [2010-02-03 10:37:54] paj...@php.net I reproduced it randomly using TS and NTS version of PHP in the console. Not sure which of the alternative should be used but the analyze is correct. ------------------------------------------------------------------------ [2010-02-02 23:56:14] hardon at online dot no Description: ------------ Bug #49626 is actually a bug, not bougus (have gotten this segfault many times myself). Was unable to reopen/comment on it, so made a new bug. >From the stack trace and looking thru the code its obvious that an error is in progress of being logged, but it segfaults in the process. This is because tsrm_ls[date_globals_id] slot is not allocated and DATEG segfaults. Segfault only visible in ZTS builds (non-ZTS build have a global/static struct, zend_date_globals?), but it is still an error in non-ZTS; date globals are not initialized (to zero) yet, thou hopefully zeroed by compiler, but compiler doesn't guarantee this(?). Can possibly lead to mysterious errors in non-ZTS as well. Why is slot not allocated yet? The "date" extension isn't "started" yet when error is logged (or if HAVE_DATE was not defined, never). I even found the revision that "broke" it (I think it worked "better" before this change): http://svn.php.net/viewvc/php/php-src/trunk/main/main.c?r1=188608&r2=188607&pathrev=188608 But reverting this change is not the right fix, the change just provoked the bug. Errors can be logged at any time during startup so can not rely on "date" extension being initialized (HAVE_DATE can even be undefined). This code shows the "not initialized yet" problem is not new: /* Check config setting for default timezone */ if (!DATEG(default_timezone)) { /* Special case: ext/date wasn't initialized yet */ zval ztz; if (SUCCESS == zend_get_configuration_directive("date.timezone", sizeof("date.timezone"), &ztz) && Thoughts on how to fix: Alt1: initialize date "extension" as early as possible, maybe around here? main.c->php_module_startup: #ifdef ZTS executor_globals = ts_resource(executor_globals_id); + date_globals = ts_resource(date_globals_id); Alt2 (hackish..): define DATEG_VALID that (in ZTS builds) check if date_globals_id is != 0 (hmm, possibly not zeroed by compiler..), and only then use DATEG Alt3: it's a bit weird that main.c require the "date" ext since it is optional (HAVE_DATE). Maybe main.c should not have used anything from "date" in the first place, or "date" should have been a part of the "framework", not an ext. But you guys probably have a better solution:-) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=50918&edit=1
