From: hardon at online dot no Operating system: Windows PHP version: 5.3.1 PHP Bug Type: Reproducible crash Bug description: Access violation in php.exe (Bug #49626 redux)
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 bug report at http://bugs.php.net/?id=50918&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50918&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50918&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50918&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50918&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50918&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50918&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50918&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50918&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50918&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50918&r=support Expected behavior: http://bugs.php.net/fix.php?id=50918&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50918&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50918&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50918&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50918&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=50918&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50918&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50918&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50918&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50918&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50918&r=mysqlcfg
