php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50918 Access violation in php.exe (Bug #49626 redux)
Submitted: 2010-02-02 23:56 UTC Modified: 2010-08-08 16:23 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:1 (25.0%)
From: hardon at online dot no Assigned: pajoye (profile)
Status: Duplicate Package: Reproducible crash
PHP Version: 5.3.1 OS: win32 only - Windows
Private report: No CVE-ID: None
 [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:-)



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-03 10:37 UTC] 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-07 09:49 UTC] jani@php.net
Pierre, it's the order of init which is buggy in Windows. Works fine on all other OSes.
 [2010-03-17 14:48 UTC] 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-03-17 14:52 UTC] pajoye@php.net
Yes, current work around is to actually set the timezone in php.ini
 [2010-03-17 15:01 UTC] pajoye@php.net
btw, it is not windows specific, crashes occur on other platform as well.
 [2010-03-17 15:43 UTC] progunster at gmail dot com
Added
date.timezone = "Europe/Kiev"
to [Date] section of php.ini, it didn't helped.
Same error, same place.
 [2010-03-17 16:05 UTC] pajoye@php.net
-Status: Assigned +Status: Feedback
 [2010-03-17 16:05 UTC] pajoye@php.net
When does this crash happen exactly? As you seem to be able to reproduce it, always, I would like to know how :)
 [2010-03-18 09:02 UTC] progunster at gmail dot com
Well, after reboot I can't reproduce it anymore.
So, what i did:
1.) Installed httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi 
It Works!
2.) Changed httpd.conf, to disable http and enable https (also created self-signed certificates)
3.) Installed PHP from php-5.3.2-Win32-VC6-x86.msi
Right after that httpd.exe was crashing on start. After reboot it all went gone.
On another computer it was the same.
 [2010-03-31 12:31 UTC] pajoye@php.net
-Status: Feedback +Status: Assigned
 [2010-03-31 12:31 UTC] pajoye@php.net
Let me try to give Derick a bt and details about the crash.
 [2010-04-09 18:53 UTC] bugs-php-net at onethumb dot com
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.
 [2010-08-08 16:23 UTC] pajoye@php.net
-Status: Assigned +Status: Duplicate
 [2010-08-08 16:23 UTC] pajoye@php.net
Duplicate of #51298
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Thu Feb 20 18:01:25 2020 UTC