ID:               48752
 Updated by:       [email protected]
 Reported By:      [email protected]
 Status:           Assigned
 Bug Type:         Date/time related
 Operating System: *
 PHP Version:      5.3.0
 Assigned To:      derick
 New Comment:

here is a patch: http://pastie.org/668460

It makes the last_errors request specific as well as it should be.

However the problem is not completely solved as we need a lock before
the 1st operation on last_errors until we are done. It is not sufficent
to lock it before calling a function or setting it a value. Other
threads may affect it during two calls.

I consider this last_errors as a design mistake, but if you like to
keep it this way then we will need this global lock.


Previous Comments:
------------------------------------------------------------------------

[2009-10-24 22:52:41] [email protected]

Simply script:
$datetime_object = date_create("d");

with the timezone set in php.ini.

The crashes occur only with an invalid date. For some reason the global
last_errors is not NULL anymore (but it is set to NULL during MINIT) but
freed somewhere.

By the way, I do not understand the need to store the warning in a
GLOBALS (for all applications running on the same server) when we work
with object. That's a design flaw as other applications using the same
API at the same time may generate warnings, defeating the whole point of
the warnings (if they did not crash php before). That could affect NTS
server as well.





------------------------------------------------------------------------

[2009-10-24 20:34:36] [email protected]

Apache2 Windows builds are multithreaded (php5__ts__.dll) and therefore
have the same problems.

The problem: Multithread bugs do not have enough priority in PHP as
most people use apache on unix in prefork moder or use FastCGI :(

I would look after this, but I have no deep knowledge of the extension.

------------------------------------------------------------------------

[2009-10-24 20:08:15] Brian dot White at foxfire74 dot com

Is anyone looking into this.  This also happens in the 5.3.0 Windows
build, and, oftentimes, happens a LOT more than 15 minutes.  The PHP
date_create() function calls timelib_error_container_dtor() which
crashes Apache frequently but not on every execution.

Reproduce code:
---------------
<?php
function wp_timezone_override_offset() {
        $timezone_string = 'America/New_York';

        @date_default_timezone_set( $timezone_string );
        $timezone_object = timezone_open( $timezone_string );
        $datetime_object = date_create();
        if ( false === $timezone_object || false === $datetime_object ) {
                return false;
        }
        return round( timezone_offset_get( $timezone_object, $datetime_object
) / 3600, 2 );
}

$gmt_offset = wp_timezone_override_offset();

echo "$gmt_offset\n";
?>

Expected result:
----------------
-4

Actual result: (When it crashes)
--------------
Thread 75 - System ID 2180
Entry point   msvcr90!_endthreadex+6f 
Create time   10/24/2009 3:18:56 AM 
Time spent in user mode   0 Days 0:0:0.991 
Time spent in kernel mode   0 Days 0:0:0.140 

Function     Arg 1     Arg 2     Arg 3   Source 
php5ts!timelib_error_container_dtor+9     00000044     1118e380    
0f10aed8   d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\lib\timelib.c
@ 153 + 6 
php5ts!date_object_period_get_iterator+835     0f1718e0     00000000   
 00000000   d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @
2364 + 1f 
php5ts!zif_date_create+9a     00000000     0f10aed8     00000000  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 2441 + 30 
php5ts!execute+10b9     0eca318c     1118e300     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 313 + 41

php5ts!execute+57ea     0eca2894     1118e380     093ff7a8  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 1601 + e

php5ts!execute+298     1137a5b0     1118e301     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 104 + a 
php5ts!zend_call_function+7b0     00000000     093ff794     0eca2ca4  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_execute_api.c @ 936 + 1b

php5ts!zif_call_user_func_array+63     00000002     0f169ca0    
00000000  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\basic_functions.c @
4755 + 18 
php5ts!execute+10b9     0eca2ca4     1118e300     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 313 + 41

php5ts!execute+57ea     0eca213c     1118e380     093ff920  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 1601 + e

php5ts!execute+298     11474c88     1118e301     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 104 + a 
php5ts!zend_call_function+7b0     00000000     093ff90c     0eca221c  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_execute_api.c @ 936 + 1b

php5ts!zif_call_user_func_array+63     00000002     0f168cf8    
00000000  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\basic_functions.c @
4755 + 18 
php5ts!execute+10b9     0eca221c     1118e300     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 313 + 41

php5ts!execute+57ea     0eca1484     1118e380     093ffa98  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 1601 + e

php5ts!execute+298     0f0b7f38     1118e301     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 104 + a 
php5ts!zend_call_function+7b0     00000000     093ffa84     0eca1578  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_execute_api.c @ 936 + 1b

php5ts!zif_call_user_func_array+63     00000002     0f16b940    
00000000  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\basic_functions.c @
4755 + 18 
php5ts!execute+10b9     0eca1578     1118e300     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 313 + 41

php5ts!execute+57ea     1118e380     093ffb9c     00000000  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 1601 + e

php5ts!execute+298     0ec6dea8     1118e300     1118e380  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_vm_execute.h @ 104 + a 
php5ts!zend_execute_scripts+fe     00000008     1118e380     00000000  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1189 
php5ts!php_execute_script+231     093ffe28     1118e380     00000005  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 2196 + 12 
php5apache2_2!zm_info_apache+1744     0bfb9e00     012522a8    
0bfb9e00  
d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\apache2handler\sapi_apache2.c
@ 648 + e 
libhttpd!ap_run_handler+25     00000000     00000000     00000000    


PHP5TS!TIMELIB_ERROR_CONTAINER_DTOR+9In
httpd__PID__5760__Date__10_24_2009__Time_05_25_07AM__374__Second_Chance_Exception_C0000005.dmp
the assembly instruction at php5ts!timelib_error_container_dtor+9 in
C:\PHP\php5ts.dll from The PHP Group has caused an access violation
exception (0xC0000005) when trying to read from memory location
0x00000044 on thread 75

------------------------------------------------------------------------

[2009-07-01 11:48:55] [email protected]

By the way, this seems to be the only problem left for our PHP 5.3
tests in production :). The server "only" crashes and is restarted by
watchdog once per 15 minutes and always with exactly that crashdump only
with the parameter time_str_len slighly different and of course other
date string values.

Thanks Derick for looking after this!
Uwe

------------------------------------------------------------------------

[2009-07-01 11:39:39] [email protected]

Yes it is threaded! (Sun Java System Webserver using NSAPI as SAPI
module is a one-process webserver with pthreads).

In 5.2.x we never had such problems, the PHP userland code did not
change.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/48752

-- 
Edit this bug report at http://bugs.php.net/?id=48752&edit=1

Reply via email to