php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57727 Classes error
Submitted: 2007-07-01 05:33 UTC Modified: 2009-11-30 07:25 UTC
From: info at tcknetwork dot com Assigned:
Status: Closed Package: bcompiler (PECL)
PHP Version: 5.1.6 OS: OpenBSD
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: info at tcknetwork dot com
New email:
PHP Version: OS:

 

 [2007-07-01 05:33 UTC] info at tcknetwork dot com 
Description:
------------
Using the native PHP from OpenBSD 4.1
PHP 5.1.6 with Suoshin-Patch 0.9.5 / BCompiler 0.8

At the end of the script, the destruction of the class prototype seems to generate one error (catched by Suoshin patch).

This error is apparently sent only when freeing memory of the script


Reproduce code:
---------------
First test :
--------------------------------
test.php, bcompiled
<? class test {} ?>

called with the console (produces more output)
# php test.php

Second test :
--------------------------------
test.php, bcompiled
<?
class test {
 function test() { echo "1"; }
 function __destruct() { echo "2"; }
}
$t=new test(); $t->test(); unset($t); echo "3";
?>

test2.php, plain :
<? include("test.php"); echo "4"; ?>

# php test2.php

Expected result:
----------------
First test :
--------------------------------
- Nothing should appear
- Return value should be 0


Second test :
--------------------------------
2nd test :
- Output="11234"
- Return=0

Actual result:
--------------
First test :
--------------------------------
- Display Suoshin-patch error message :
"ALERT - possible memory corruption detected - unknown Hashtable destructor"
- return value = 1 (due to suoshin patch)

Second test :
--------------------------------
- Output="11234ALERT - possible memory corruption..."
- Return=1

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-21 19:09 UTC] randallid at ymail dot com 
i get the error: 
ALERT - possible memory corruption detected - unknown Hashtable destructor (attacker 'REMOTE_ADDR not set', file 'unknown')

for a simple echo class (though it executes correcty)

PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Dec 17 2008 16:15:53)
 [2009-04-09 07:56 UTC] sipdude at gmail dot com 
I'm getting the same error ("ALERT - possible memory corruption detected - unknown Hashtable destructor")
when using pecl-mailparse-2.1.5 on FreeBSD 7.1 together
with php-5.2.9 and Suhosin-patch. What triggers the error
is mailparse_msg_get_part($mime_resource, $structure_part)
 [2009-04-10 11:16 UTC] queria at sa-tas dot net 
same error

PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: Mar 12 2009 21:22:29)
OpenSuse 11.1
bcompiler installed via pecl install bcompiler

Complex website 'bcompiled'
and end up with error (in log) when accessing index.php

on gentoo and windowsxp website used to work ok after bcompile

when run via cli - php index.php - it outputs everything as it should be (complete html...) but at the end this error appears

any solution or how can i dig more info for you?
 [2009-05-05 07:57 UTC] bones at betelmed dot be 
Same error on Debian  with PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) 

I have this message if I run the script with client and if I run on apache webserver, my browser say would you like to save this page ? and don't run it.
 [2009-05-05 09:44 UTC] alan at akbkhome dot com 
I think this is a bug with the suhosin patch, looking at 
the patch, it looks like it does not correctly check for 
all possible destructor types. - Asked Stefan (&co) to 
have a look
 [2009-05-07 07:03 UTC] stefan dot esser at sektioneins dot de 
Bcompiler does something illegal

	apc_deserialize_hashtable(
		&zce->properties_info, 
		(void*) apc_create_zend_property_info, 
		(void*) apc_free_zend_property_info,
		(int) sizeof(zend_property_info) , 
		(char) exists TSRMLS_CC);
	zce->properties_info.pDestructor = (dtor_func_t)&zend_destroy_property_info;

it modifies the internals of a HashTable without using API functions. In this case pDestructor which is protected by Suhosin.

If you absolutely must change the pDestructor field there is only one workaround: you must register the pDestructor with Suhosin-Patch. This is very simple: just create a dummy HashTable somewhere in your code with zend_hash_init() and the selected pDestructor and just kill it afterwards. Once the pDestructor value is used within a zend_hash_init() call it is known to Suhosin and allowed.
 [2009-05-07 09:12 UTC] alan at akbkhome dot com 
Try adding this code to 
504:php_bcompiler_init_globals()

#ifdef ZEND_ENGINE_2 
HashTable* ht = NULL;
zend_hash_init(
      ht, 0, NULL, &zend_destroy_property_info, 0)
);
#endif
 [2009-05-07 15:20 UTC] stefan dot esser at sektioneins dot de 
I think you mean

#ifdef ZEND_ENGINE_2 
HashTable ht;
zend_hash_init(
      &ht, 0, NULL, (dtor_func_t)&zend_destroy_property_info, 0)
);
#endif
 [2009-05-07 15:21 UTC] stefan dot esser at sektioneins dot de 
Ahh and to not leak memory you should put a

zend_hash_destroy(&ht);

directly behind the zend_hash_init() call
 [2009-11-29 14:46 UTC] val@php.net 
Please try the latest SVN version or package version 0.9.1 (to be released soon). The bug should be fixed there.
 [2009-11-30 07:18 UTC] info at tcknetwork dot com 
I ran again the same test on an updated version of OpenBSD and 
it seems to be working fine so far. My configuration is below. 
Please not that it conflicts with ZendEncoder (and possibly 
IonCube).

OpenBSD 4.6 GENERIC.MP#89 i386
PHP 5.2.10 with Suhosin-Patch 0.9.7 (cli) (built: Jul  1 2009 
11:46:27), Zend Engine v2.2.0, with Suhosin v0.9.27.
 [2009-11-30 07:25 UTC] val@php.net 
Thank you! I close this one, since the problem with Suoshin-Patch is fixed.

Please note that bcompiler isn't supposed to work with ZendEncoder, IonCube and similar modules that intercept include() call handling (the only exception is APC, because we made APC-bcompiler compatibility fix).

I believe that in bcompiler 1.0 we'll have this issue addressed. As a temporary solution, you could probably turn modules on/off on a per-site basis.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 21:01:30 2024 UTC