ID: 50918 Updated by: j...@php.net Reported By: hardon at online dot no Status: Assigned Bug Type: Reproducible crash -Operating System: Windows +Operating System: win32 only - Windows PHP Version: 5.3.1 Assigned To: pajoye New Comment:
Pierre, it's the order of init which is buggy in Windows. Works fine on all other OSes. Previous Comments: ------------------------------------------------------------------------ [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/?id=50918&edit=1
