|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49893 Apache 2.2 Child crash while creating an instance of Zend_Mail_Storage_Pop3
Submitted: 2009-10-15 19:00 UTC Modified: 2010-05-11 18:22 UTC
From: greubel at nkey dot de Assigned: dmitry (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.3.0 OS: *
Private report: No CVE-ID: None
 [2009-10-15 19:00 UTC] greubel at nkey dot de
While creating an instance of Zend_Mail_Storage_Pop3 using an username and NO password, the Apache Connection was ended. In error log and windows event log the message appears, that the child has exited.

Reproduce code:
$storage = new Zend_Mail_Storage_Pop3(array(
          'host' => $mailbox->incomingServer,
          'user' => $mailbox->loginName,
	  'password' => $mailbox->loginPasswd == null ? '' : $mailbox->loginPasswd

Expected result:
A error or exception that the connection to remote host could not be established

Actual result:
Apache Child crash:

[Thu Oct 15 20:43:11 2009] [notice] Parent: child process exited with status 255 -- Restarting.
[Thu Oct 15 20:43:11 2009] [notice] Apache/2.2.14 (Win32) PHP/5.3.0 configured -- resuming normal operations
[Thu Oct 15 20:43:11 2009] [notice] Server built: Sep 28 2009 22:41:08

Windows event log XML output:

- <Event xmlns="">
- <System>
  <Provider Name="Application Error" /> 
  <EventID Qualifiers="0">1000</EventID> 
  <TimeCreated SystemTime="2009-10-15T18:43:08.000Z" /> 
  <Security /> 
- <EventData>


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-15 19:02 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

 [2009-10-16 00:10 UTC] greubel at nkey dot de
require 'Zend/Mail/Storage/Pop3.php';

try {
	$acc = new Zend_Mail_Storage_Pop3(
      'host' => '',
      'user' => '',
      'password' => ''
catch(Exception $e)
	echo $e->getMessage();
	echo "<pre>";
	echo $e->getTraceAsString();
	echo "</pre>";
 [2009-10-16 00:21 UTC] greubel at nkey dot de
I tried to find the source of the problem. If the Zend_Mail_Protocol_Pop3 is used as class to create a communication object, an exception is thrown instead of crash.

Used code:

require 'Zend/Mail/Protocol/Pop3.php';  
try {
	$acc = new Zend_Mail_Protocol_Pop3();
	$acc->login('', '');
catch(Exception $e)
	echo $e->getMessage();
	echo "<pre>";
	echo $e->getTraceAsString();
	echo "</pre>";

The crashing method in Zend_Mail_Storage_Pop3 seems to be the Zend_Mail_Protocol_Pop3::login() method call in the constructor.
 [2009-10-19 10:45 UTC]
Please don't post bugs in 3rd party frameworks as bugs in PHP. As long as you're not able to provide a short reproducing code that does NOT require this is not a bug.
 [2009-10-19 21:07 UTC] greubel at nkey dot de
I see now, it has nothing to do with Zend Framework. The access violation is occured in the garbage collector component in PHP. Please take this analysis dump for more information:

Type of Analysis Performed   Crash Analysis 
Machine Name   CALLIPSO 
Operating System   Windows Vista Service Pack 2 
Number Of Processors   2 
Process ID   3812 
Process Image   C:\Program Files\Apache Software Foundation\Apache2.2\bin\httpd.exe 
System Up-Time   02:29:04 
Process Up-Time   00:04:32 

Thread 1 - System ID 5184
Entry point   msvcrt!_endthreadex+6f 
Create time   19.10.2009 22:20:47 
Time spent in user mode   0 Days 0:0:0.15 
Time spent in kernel mode   0 Days 0:0:0.0 

Function     Arg 1     Arg 2     Arg 3   Source 
php5ts!gc_zval_possible_root+61     03d5fc00     0251c278     00000000    
php5ts!ZEND_ASSIGN_SPEC_CV_VAR_HANDLER+69     01a3fbc0     0251c278     01a3fe3c    
php5ts!execute+29e     03d91014     0251c200     00000000    
php5ts!zend_execute_scripts+f6     00000008     0251c278     00000000    
php5ts!php_execute_script+22d     01a3fe3c     0251c278     00000004    
php5apache2_2!php_handler+5d0     01fec1a8     00954208     01fec1a8    
libhttpd!ap_run_handler+21     01fec1a8     01fec1a8     01fec1a8    
libhttpd!ap_invoke_handler+ae     00000000     02534cb8     01a3ff00    
libhttpd!ap_die+29e     01fec1a8     00000000     01fd51c0    
libhttpd!ap_get_request_note+1ccc     02534cb8     02534cb8     02534cb8    
libhttpd!ap_run_process_connection+21     02534cb8     008a4ea0     01a3ff48    
libhttpd!ap_process_connection+33     02534cb8     01fe4198     00000000    
libhttpd!ap_regkey_value_remove+c7c     02534cb0     70ec09d9     00000000    
msvcrt!_endthreadex+44     01a3ff94     7681d0e9     02131090    
msvcrt!_endthreadex+ce     02131090     01a3ffd4     779319bb    
kernel32!BaseThreadInitThunk+e     02131090     76bcf999     00000000    
ntdll!__RtlUserThreadStart+23     76432670     02131090     00000000    
ntdll!_RtlUserThreadStart+1b     76432670     02131090     00000000    

PHP5TS!GC_ZVAL_POSSIBLE_ROOT+61In httpd__PID__3812__Date__10_19_2009__Time_10_25_19PM__378__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!gc_zval_possible_root+61 in C:\Program Files\PHP-5.3\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x7fc66981 on thread 1

Module Information 
Image Name: C:\Program Files\PHP-5.3\php5ts.dll   Symbol Type:  PDB 
Base address: 0x01400000   Time Stamp:  Mon Jun 29 22:24:07 2009  
Checksum: 0x00000000   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.3.0 
Managed DLL: False   Internal Name:  PHP Script Interpreter 
VB DLL: False   Legal Copyright:  Copyright ? 1997-2009 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal Trademarks:  PHP 
Mapped Image Name:  C:\Program Files\PHP-5.3\php5ts.dll   Original filename:  php5ts.dll 
Module name:  php5ts   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  5,44 MBytes   Product Version:  5.3.0 
Symbol File Name:  C:\Program Files\PHP-5.3\php5ts.pdb   Special Build:  & 

I was not able to locate the exact point of the bug. Because I do not have enough knowlegde about the PHP source code, I can not help further. The symbols file seems to not contain any source information. I downloaded it from

 [2009-10-19 21:37 UTC] greubel at nkey dot de
I was able to get a little bit deeper. The exception has occured inside the GC_ZOBJ_CHECK_POSSIBLE_ROOT macro.

01483381 8a540101        mov     dl,byte ptr [ecx+eax+1]    ds:0023:79d86981=??

Marked line in source view is 

 [2009-10-19 22:37 UTC]
We need a reproduce script to be able to fix this problem.
 [2009-10-20 05:42 UTC] greubel at nkey dot de
I do not have more than in the opening post. I believe, because of the nature of the problem (garbage collector), it would be hard to find a piece of code, where the same problem occurs. Finally to say, it is possible, that it only happens on 32bit vista/xp/2000.

Why it is not possible to use the script I provided first?

Thank you and regards

 [2009-10-20 08:34 UTC]
Please try using this snapshot:
For Windows:

 [2009-10-20 18:54 UTC] greubel at nkey dot de
The access violation has now moved to another place:

php5ts!gc_zobj_possible_root+57     038ffbc0     0273b270     038fe608    
php5ts!gc_zval_possible_root+74     038ffbc0     0273b270     00000000    
php5ts!ZEND_ASSIGN_SPEC_CV_VAR_HANDLER+69     0094fbc0     0273b270     0094fe3c    
php5ts!execute+2fb     039310b0     0273b200     00000000    
php5ts!zend_execute_scripts+f6     00000008     0273b270     00000000    
php5ts!php_execute_script+233     0094fe3c     0273b270     00000004    
php5apache2_2!php_handler+5d0     0275ead8     00a24208     0275ead8    
libhttpd!ap_run_handler+21     0275ead8     0275ead8     0275ead8    
libhttpd!ap_invoke_handler+ae     00000000     02847fc0     0094ff00    
libhttpd!ap_die+29e     0275ead8     00000000     021b51c0    
libhttpd!ap_get_request_note+1ccc     02847fc0     02847fc0     02847fc0    
libhttpd!ap_run_process_connection+21     02847fc0     00974f20     0094ff48    
libhttpd!ap_process_connection+33     02847fc0     021c81a8     00000000    
libhttpd!ap_regkey_value_remove+c7c     02847fb8     a899cc42     00000000    
msvcrt!_endthreadex+44     0094ff94     76bdd0e9     02746848    
msvcrt!_endthreadex+ce     02746848     0094ffd4     775919bb    
kernel32!BaseThreadInitThunk+e     02746848     7383fe36     00000000    
ntdll!__RtlUserThreadStart+23     76b02670     02746848     00000000    
ntdll!_RtlUserThreadStart+1b     76b02670     02746848     00000000
 [2009-10-20 19:53 UTC]
We *still* need a way to reproduce your problem. that means a small script as described already in one of my comments.
 [2009-10-20 20:11 UTC] greubel at nkey dot de
Please close. I'm not able to reproduce the problem with a small script. I tried to strip down the code from ZF to provide the same functionality but provoke the bug. This seems to be not possible on this circumstances.

This code works well:

class foo
	private $sock;
	private $errno;
	private $error;
	public function __construct()
		$this->sock = fsockopen('', 110, $this->errno, $this->error);
    $r = fgets($this->sock);
    echo "$r<br/>";
		fputs($this->sock, "USER\r\n");
		$r = fgets($this->sock);
		echo "$r<br/>";
    fputs($this->sock, "PASS \r\n");
    $r = fgets($this->sock);
    echo "$r<br/>";

    fputs($this->sock, "QUIT\r\n");
    $r = fgets($this->sock);
    echo "$r<br/>";
	public function close()
		$this->sock = null;

$bar = new foo();

So please close.
 [2009-10-20 20:13 UTC] greubel at nkey dot de
Not reproducable
 [2009-10-20 20:57 UTC]
not a bug > bogus.
 [2010-05-11 16:45 UTC]
-Status: Bogus +Status: Assigned -Operating System: Windows Vista +Operating System: * -Assigned To: +Assigned To: dmitry
 [2010-05-11 16:45 UTC]
The bug occurs when exception is caught in destructor during another exception processing

Reproduce code:
class A {
	function __destruct() {
		try {
			throw new Exception("2");
		} catch (Exception $e) {
			echo $e->getMessage() . "\n";
class B {
	function __construct() {
		$this->a = new A();
		throw new Exception("1");
try {
	$b = new B();
} catch(Exception $e) {
	echo $e->getMessage() . "\n";;

Expected result:

Actual result:


==26823== Invalid read of size 4
==26823==    at 0x856480A: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (zend.h:385)
==26823==    by 0x84D7B98: execute (zend_vm_execute.h:104)
==26823==    by 0x84ACA44: zend_execute_scripts (zend.c:1194)
==26823==    by 0x844186E: php_execute_script (main.c:2260)
==26823==    by 0x8572CDE: main (php_cli.c:1192)
==26823==  Address 0x51f1428 is 8 bytes inside a block of size 20 free'd
==26823==    at 0x4B8C90A: free (vg_replace_malloc.c:323)
==26823==    by 0x848B079: _efree (zend_alloc.c:2348)
==26823==    by 0x849C3E3: _zval_ptr_dtor (zend_execute_API.c:444)
==26823==    by 0x84D8156: zend_leave_helper_SPEC (zend_vm_execute.h:226)
==26823==    by 0x84DA521: ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (zend_vm_execute.h:680)
==26823==    by 0x84D7B98: execute (zend_vm_execute.h:104)
==26823==    by 0x84ACA44: zend_execute_scripts (zend.c:1194)
==26823==    by 0x844186E: php_execute_script (main.c:2260)
==26823==    by 0x8572CDE: main (php_cli.c:1192)
 [2010-05-11 18:09 UTC]
Automatic comment from SVN on behalf of dmitry
Log: Fixed bug #49893 (Crash while creating an instance of Zend_Mail_Storage_Pop3)
 [2010-05-11 18:22 UTC]
-Status: Assigned +Status: Closed
 [2010-05-11 18:22 UTC]
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 08:01:32 2024 UTC