php.net |  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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: greubel at nkey dot de
New email:
PHP Version: OS:

 

 [2009-10-15 19:00 UTC] greubel at nkey dot de
Description:
------------
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="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Application Error" /> 
  <EventID Qualifiers="0">1000</EventID> 
  <Level>2</Level> 
  <Task>100</Task> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2009-10-15T18:43:08.000Z" /> 
  <EventRecordID>1685</EventRecordID> 
  <Channel>Application</Channel> 
  <Computer>Callipso</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data>httpd.exe</Data> 
  <Data>2.2.14.0</Data> 
  <Data>4ac181d6</Data> 
  <Data>php5ts.dll</Data> 
  <Data>5.3.0.0</Data> 
  <Data>4a4922e7</Data> 
  <Data>c0000005</Data> 
  <Data>00083381</Data> 
  <Data>d44</Data> 
  <Data>01ca4dc6c4770430</Data> 
  </EventData>
  </Event>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-15 19:02 UTC] pajoye@php.net
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
<?php
require 'Zend/Mail/Storage/Pop3.php';

try {
	$acc = new Zend_Mail_Storage_Pop3(
		array(
      'host' => 'pop.gmx.de',
      'user' => 'someone@gmx.de',
      '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:

<?php
require 'Zend/Mail/Protocol/Pop3.php';  
try {
	$acc = new Zend_Mail_Protocol_Pop3();
	$acc->connect('pop.gmx.de');
	$acc->login('someone@gmx.de', '');
}
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] jani@php.net
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 http://windows.php.net/downloads/releases/php-debug-pack-5.3.0-Win32-VC6-x86.zip.

Regards
 [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.

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

Marked line in source view is 

GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
 [2009-10-19 22:37 UTC] pajoye@php.net
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

Maik
 [2009-10-20 08:34 UTC] jani@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [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] pajoye@php.net
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:

<?php
class foo
{
	private $sock;
	private $errno;
	private $error;
	
	public function __construct()
	{
		$this->sock = fsockopen('pop.gmx.net', 110, $this->errno, $this->error);
    $r = fgets($this->sock);
    echo "$r<br/>";
		
		fputs($this->sock, "USER mike.greubel@gmx.de\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()
	{
		fclose($this->sock);
		$this->sock = null;
	}
}

$bar = new foo();
$bar->close();
?>

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

Reproduce code:
---------------
<?php
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:
----------------
2
1

Actual result:
--------------
2

valgrind
--------

==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] dmitry@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=299254
Log: Fixed bug #49893 (Crash while creating an instance of Zend_Mail_Storage_Pop3)
 [2010-05-11 18:22 UTC] dmitry@php.net
-Status: Assigned +Status: Closed
 [2010-05-11 18:22 UTC] dmitry@php.net
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
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Fri Jan 31 18:01:31 2025 UTC