|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2010-02-02 23:56 UTC] 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:-) PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 01 08:00:02 2025 UTC |
I'm experiencing this bug (or something extremely similar) on PHP v5.3.2 on CentOS 5.4. Essentially, if I build PHP with --enable-maintainer-zts (for use with Apache's worker mpm) and try to load any extensions, PHP instantly segfaults at /ext/date/php_date.c:844 in guess_timezone() when it tries to call DATEG(timezone): (gdb) run Starting program: /home/onethumb/zts/php-5.3.2/sapi/cli/php [Thread debugging using libthread_db enabled] [New Thread 0x2b1fea7adc00 (LWP 20681)] Program received signal SIGSEGV, Segmentation fault. 0x000000000042ab9d in guess_timezone (tzdb=0xea1f60, tsrm_ls=0x1f370500) at /home/onethumb/zts/php-5.3.2/ext/date/php_date.c:844 844 if (DATEG(timezone) && (strlen(DATEG(timezone)) > 0)) { I have date.timezone properly set in php.ini. Running without any extensions confirms. Hardcoding guess_timezone() to return a valid timezone simply moves the crash farther into php_date, to the next DATEG() call in timezone caching. Extensions I've tried include very common PECL extensions like zip, apc, and memcached, among others. Adding any "extension = " line to php.ini appears to trigger this crash.