Edit report at http://bugs.php.net/bug.php?id=50918&edit=1
ID: 50918
Updated by: pajoye@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:
Yes, current work around is to actually set the timezone in php.ini
Previous Comments:
------------------------------------------------------------------------
[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] jani@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] pajoye@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