#48228 [Ver-Csd]: Possible memory corruption when PHP compiled using GCC 4.3.x

2009-05-27 Thread iddekingej at lycos dot com
 ID:   48228
 User updated by:  iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
-Status:   Verified
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Linux 64bit gcc
 PHP Version:  5.*, 6CVS (2009-05-27)
 New Comment:

I can confirm that this bug is probably caused by a compiler bug as
mentioned in bug #48408.

When I compiled PHp with 4.1 and run the test script I didn't see the 
(tried to allocate 140498868988960 bytes) message.

I also added the debug output as described at [21 May 9:17pm UTC] and
the arg_type_stack.top=-3 bug didn't happen.


Previous Comments:


[2009-05-27 19:24:02] j...@php.net

See also bug #48408



[2009-05-21 21:17:25] iddekingej at lycos dot com

I have some more information about this bug:

THis bug happens in the following situation:

$l_a-someMethod(other_fy())

When in other_fy() a exception is raised this bug occurs.

This bug doesn't happen when calling a normal function 

e.g.
someMethod(other_fy())


This bug happens in apache as module and in the CLI. (only in the cli
there is no visible clue that something did go wrong).


In the function ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (zend_vm_execute.h).

I placed some debug output (EX(fbc)-common.function_name and
EG(arg_types_stack).top)
before:

while (EX(fbc)) {
  EX(called_scope) =
(zend_class_entry*)zend_ptr_stack_pop(EG(arg_types_stack));
  if (EX(object)) {

and after

zend_object_store_ctor_failed(EX(object) TSRMLS_CC);
}
 }
 zval_ptr_dtor(EX(object));
  }

After the exception is raised this function is called. 
The first time it is called, the variable fbc=NULL and
arg_types_stack.top =3. Because 
EX(fbc)=NULL the while loop is skipped.

When this function is called the second time and fbc is not
null(Contains data from the method check) , 
and arg_type_stack.top is still 3. After the while loop
arg_type_stack.top=-3, which is afcourse wrong . Because of this 
some memory corruption occurs.

So  maybe when calling a method and a expception is raised when the
parameters are calculated the variable fbc is not set correctly 
or there is a missing zend_ptr_stack_3_push(EG(arg_types_stack),
EX(fbc), EX(object), EX(called_scope));



[2009-05-21 11:03:40] lbarn...@php.net

Verified with gcc 4.3.3 with -O2 on 5.2 and 5.3. (./configure
--disable-all)

Shorter reproduce script:

?

function do_throw() {
throw new Exception();
}

class aa 
{
function check()
{
}

function dosome()
{
$this-check(do_throw());
}
}
$l_aa=new aa();

$l_aa-dosome();
?

The following patch against 5.3 may help to see the problem:

Index: Zend/zend_ptr_stack.h
===
RCS file: /repository/ZendEngine2/zend_ptr_stack.h,v
retrieving revision 1.22.2.2.2.1.2.3
diff -u -p -r1.22.2.2.2.1.2.3 zend_ptr_stack.h
--- Zend/zend_ptr_stack.h   31 Dec 2008 11:15:32 -  1.22.2.2.2.1.2.3
+++ Zend/zend_ptr_stack.h   21 May 2009 10:56:26 -
@@ -107,6 +107,9 @@ static inline void zend_ptr_stack_push(z
 static inline void *zend_ptr_stack_pop(zend_ptr_stack *stack)
 {
stack-top--;
+   if (stack-top  0) {
+   return *(void**)0;
+   }
return *(--stack-top_element);
 }


The following patch avoids the crash (don't know exactly why):

Index: Zend/zend_vm_def.h
===
RCS file: /repository/ZendEngine2/zend_vm_def.h,v
retrieving revision 1.59.2.29.2.48.2.90
diff -u -p -r1.59.2.29.2.48.2.90 zend_vm_def.h
--- Zend/zend_vm_def.h  8 Apr 2009 13:19:34 -   1.59.2.29.2.48.2.90
+++ Zend/zend_vm_def.h  21 May 2009 11:01:28 -
@@ -4296,7 +4296,8 @@ ZEND_VM_HANDLER(149, ZEND_HANDLE_EXCEPTI
zval_ptr_dtor(EX(object));
}
EX(called_scope) = DECODE_CTOR(EX(called_scope));
-   zend_ptr_stack_2_pop(EG(arg_types_stack), (void**)EX(object),
(void**)EX(fbc));
+   EX(object) = zend_ptr_stack_pop(EG(arg_types_stack));
+   EX(fbc) = zend_ptr_stack_pop(EG(arg_types_stack));
}
 
for (i=0; iEX(op_array)-last_brk_cont; i++) {



[2009-05-21 07:41:11] iddekingej at lycos dot com

It is the default apache2 for kubuntu 8.10: apache2 2.2.9/Prefork



[2009-05-21 00:46:57] j...@php.net

What MPM are you using in Apache? (and when you give feedback, change 
the status to 'Open

#48228 [Fbk-Opn]: Possible memory corruption

2009-05-21 Thread iddekingej at lycos dot com
 ID:   48228
 User updated by:  iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.3.0RC2
 New Comment:

It is the default apache2 for kubuntu 8.10: apache2 2.2.9/Prefork


Previous Comments:


[2009-05-21 00:46:57] j...@php.net

What MPM are you using in Apache? (and when you give feedback, change 
the status to 'Open'..)



[2009-05-11 20:37:48] iddekingej at lycos dot com

Thanks, but the latest snapshot din't fix the problem.

I managed to debug apache and php and found the following:

The field alloc_globals-mm_heap-reserve_size is (wrongly) overwritten
with some address while freeing memory.  This value contains therefore a
large number.
Next, in zend_mm_shutdown the following code is executed

  if (heap-reserve_size) {
 heap-reserve = _zend_mm_alloc_int(heap, heap-reserve_size 
ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC);
  }
This failed because reserve_size contains a very large number.

The corruption of alloc_globals-mm_heap-reserve_size happens in the
function  _zend_mm_free_int.This function is called from
shutdown_executor about line 327.
That is zend_ptr_stack_destroy(EG(arg_types_stack));

In the function _zend_mm_free_int a local var mm_block is loaded with
mm_block = ZEND_MM_HEADER_OF(p);
This header contains size=0,next=0 (hmm size=0 sounds wrong). 
The value in alloc_globals-mm_heap-reserve_size is corrupted later
on at the line *cache = (zend_mm_free_block*)mm_block; (about line
1968). 
So I guess that cache contains a wrong pointer.



This is as far as I could debug php.



[2009-05-11 09:45:55] j...@php.net

Please try using this CVS snapshot:

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

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





[2009-05-10 22:47:19] iddekingej at lycos dot com

Description:

The included example code was made for finding the reason
php5.3RC2/apache2 crashed with some php website (the websie is not
publicly available). The script didn't crash apache but failed
differently.
The script should fail with a 'undefined variable', it does but it also
displays the message Fatal error: Allowed memory size of 536870912
bytes exhausted (tried to allocate 140498868988960 bytes) in Unknown on
line 0. (The large number is probably a memory location).

This error only happens in the following situation:
* as a web page (CLI works OK)
* restart apache
* Load the page and the memory exhausted message is displayed.
* Reload the page and no memory exhausted message

Software/machine:
* 64Bit amd
* Kubuntu  8.10
* Apache 2.2.9
* PHP(5.3RC2) compiled with : 
'./configure' '--enable-zip' '--enable-soap' '--enable-sockets'
'--with-gd' '--with-pgsql' '--with-apxs2=/usr/bin/apxs2'
'--with-gettext' '--enable-cli' '--enable-mbstring'





Reproduce code:
---
?
function ex_handler($p_exception)
{
? Error:i?=$p_exception-getMessage()?/ibr/br/?
}

function
er_handler($p_errorno,$p_errstr,$p_errfile,$p_errline,$p_context)
{ 
   $l_exception=new Exception(Error $p_errorno at $p_errline in
'$p_errfile':$p_errstr); 
   throw $l_exception;
}

  set_Exception_Handler(ex_handler);
 
set_Error_Handler(er_handler,E_STRICT|E_WARNING|E_ALL|E_ERROR|E_NOTICE);
  class aa 
  {
function check($p_a,$p_b,$p_c)
{
  echo $p_a;
}

function dosome($p_b,$p_d,$p_e,$p_f,$p_g,$p_h)
{
   return 
$this-check(3,3,array(xx=$p_b,xzx=$p_d,xx=$p_e,yy=$p_c));
}
 }
  $l_aa=new aa();
 
$l_aa-dosome('2',3,4,5,'sddd','ddd');
?

Expected result:

* Undefined variable 


Actual result:
--
* Undefined variable 
* Fatal error: Allowed memory size of 536870912 bytes exhausted (tried
to allocate 140498868988960 bytes) in Unknown on line 0. 





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



#48228 [Ver]: Possible memory corruption

2009-05-21 Thread iddekingej at lycos dot com
 ID:   48228
 User updated by:  iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
 Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.2, 5.3
 New Comment:

I have some more information about this bug:

THis bug happens in the following situation:

$l_a-someMethod(other_fy())

When in other_fy() a exception is raised this bug occurs.

This bug doesn't happen when calling a normal function 

e.g.
someMethod(other_fy())


This bug happens in apache as module and in the CLI. (only in the cli
there is no visible clue that something did go wrong).


In the function ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (zend_vm_execute.h).

I placed some debug output (EX(fbc)-common.function_name and
EG(arg_types_stack).top)
before:

while (EX(fbc)) {
  EX(called_scope) =
(zend_class_entry*)zend_ptr_stack_pop(EG(arg_types_stack));
  if (EX(object)) {

and after

zend_object_store_ctor_failed(EX(object) TSRMLS_CC);
}
 }
 zval_ptr_dtor(EX(object));
  }

After the exception is raised this function is called. 
The first time it is called, the variable fbc=NULL and
arg_types_stack.top =3. Because 
EX(fbc)=NULL the while loop is skipped.

When this function is called the second time and fbc is not
null(Contains data from the method check) , 
and arg_type_stack.top is still 3. After the while loop
arg_type_stack.top=-3, which is afcourse wrong . Because of this 
some memory corruption occurs.

So  maybe when calling a method and a expception is raised when the
parameters are calculated the variable fbc is not set correctly 
or there is a missing zend_ptr_stack_3_push(EG(arg_types_stack),
EX(fbc), EX(object), EX(called_scope));


Previous Comments:


[2009-05-21 11:03:40] lbarn...@php.net

Verified with gcc 4.3.3 with -O2 on 5.2 and 5.3. (./configure
--disable-all)

Shorter reproduce script:

?

function do_throw() {
throw new Exception();
}

class aa 
{
function check()
{
}

function dosome()
{
$this-check(do_throw());
}
}
$l_aa=new aa();

$l_aa-dosome();
?

The following patch against 5.3 may help to see the problem:

Index: Zend/zend_ptr_stack.h
===
RCS file: /repository/ZendEngine2/zend_ptr_stack.h,v
retrieving revision 1.22.2.2.2.1.2.3
diff -u -p -r1.22.2.2.2.1.2.3 zend_ptr_stack.h
--- Zend/zend_ptr_stack.h   31 Dec 2008 11:15:32 -  1.22.2.2.2.1.2.3
+++ Zend/zend_ptr_stack.h   21 May 2009 10:56:26 -
@@ -107,6 +107,9 @@ static inline void zend_ptr_stack_push(z
 static inline void *zend_ptr_stack_pop(zend_ptr_stack *stack)
 {
stack-top--;
+   if (stack-top  0) {
+   return *(void**)0;
+   }
return *(--stack-top_element);
 }


The following patch avoids the crash (don't know exactly why):

Index: Zend/zend_vm_def.h
===
RCS file: /repository/ZendEngine2/zend_vm_def.h,v
retrieving revision 1.59.2.29.2.48.2.90
diff -u -p -r1.59.2.29.2.48.2.90 zend_vm_def.h
--- Zend/zend_vm_def.h  8 Apr 2009 13:19:34 -   1.59.2.29.2.48.2.90
+++ Zend/zend_vm_def.h  21 May 2009 11:01:28 -
@@ -4296,7 +4296,8 @@ ZEND_VM_HANDLER(149, ZEND_HANDLE_EXCEPTI
zval_ptr_dtor(EX(object));
}
EX(called_scope) = DECODE_CTOR(EX(called_scope));
-   zend_ptr_stack_2_pop(EG(arg_types_stack), (void**)EX(object),
(void**)EX(fbc));
+   EX(object) = zend_ptr_stack_pop(EG(arg_types_stack));
+   EX(fbc) = zend_ptr_stack_pop(EG(arg_types_stack));
}
 
for (i=0; iEX(op_array)-last_brk_cont; i++) {



[2009-05-21 07:41:11] iddekingej at lycos dot com

It is the default apache2 for kubuntu 8.10: apache2 2.2.9/Prefork



[2009-05-21 00:46:57] j...@php.net

What MPM are you using in Apache? (and when you give feedback, change 
the status to 'Open'..)



[2009-05-11 20:37:48] iddekingej at lycos dot com

Thanks, but the latest snapshot din't fix the problem.

I managed to debug apache and php and found the following:

The field alloc_globals-mm_heap-reserve_size is (wrongly) overwritten
with some address while freeing memory.  This value contains therefore a
large number.
Next, in zend_mm_shutdown the following code is executed

  if (heap-reserve_size) {
 heap-reserve = _zend_mm_alloc_int(heap, heap-reserve_size 
ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC);
  }
This failed because reserve_size contains a very large number.

The corruption of alloc_globals-mm_heap

#48228 [Com]: Possible memory corruption

2009-05-20 Thread iddekingej at lycos dot com
 ID:   48228
 Comment by:   iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
 Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.3.0RC2
 New Comment:

No feedback was provided

This bug is closed wrongly because I did give feedback.


The request was to try a snapshot. I did try the snapshot and it din't
solve the problem. So I did responded (at 11 May 8:37pm UTC) and wrote
that it didn't solve the problem and give extra information about the
cause so I think I responed apriopiate.


Previous Comments:


[2009-05-19 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2009-05-11 20:37:48] iddekingej at lycos dot com

Thanks, but the latest snapshot din't fix the problem.

I managed to debug apache and php and found the following:

The field alloc_globals-mm_heap-reserve_size is (wrongly) overwritten
with some address while freeing memory.  This value contains therefore a
large number.
Next, in zend_mm_shutdown the following code is executed

  if (heap-reserve_size) {
 heap-reserve = _zend_mm_alloc_int(heap, heap-reserve_size 
ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC);
  }
This failed because reserve_size contains a very large number.

The corruption of alloc_globals-mm_heap-reserve_size happens in the
function  _zend_mm_free_int.This function is called from
shutdown_executor about line 327.
That is zend_ptr_stack_destroy(EG(arg_types_stack));

In the function _zend_mm_free_int a local var mm_block is loaded with
mm_block = ZEND_MM_HEADER_OF(p);
This header contains size=0,next=0 (hmm size=0 sounds wrong). 
The value in alloc_globals-mm_heap-reserve_size is corrupted later
on at the line *cache = (zend_mm_free_block*)mm_block; (about line
1968). 
So I guess that cache contains a wrong pointer.



This is as far as I could debug php.



[2009-05-11 09:45:55] j...@php.net

Please try using this CVS snapshot:

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

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





[2009-05-10 22:47:19] iddekingej at lycos dot com

Description:

The included example code was made for finding the reason
php5.3RC2/apache2 crashed with some php website (the websie is not
publicly available). The script didn't crash apache but failed
differently.
The script should fail with a 'undefined variable', it does but it also
displays the message Fatal error: Allowed memory size of 536870912
bytes exhausted (tried to allocate 140498868988960 bytes) in Unknown on
line 0. (The large number is probably a memory location).

This error only happens in the following situation:
* as a web page (CLI works OK)
* restart apache
* Load the page and the memory exhausted message is displayed.
* Reload the page and no memory exhausted message

Software/machine:
* 64Bit amd
* Kubuntu  8.10
* Apache 2.2.9
* PHP(5.3RC2) compiled with : 
'./configure' '--enable-zip' '--enable-soap' '--enable-sockets'
'--with-gd' '--with-pgsql' '--with-apxs2=/usr/bin/apxs2'
'--with-gettext' '--enable-cli' '--enable-mbstring'





Reproduce code:
---
?
function ex_handler($p_exception)
{
? Error:i?=$p_exception-getMessage()?/ibr/br/?
}

function
er_handler($p_errorno,$p_errstr,$p_errfile,$p_errline,$p_context)
{ 
   $l_exception=new Exception(Error $p_errorno at $p_errline in
'$p_errfile':$p_errstr); 
   throw $l_exception;
}

  set_Exception_Handler(ex_handler);
 
set_Error_Handler(er_handler,E_STRICT|E_WARNING|E_ALL|E_ERROR|E_NOTICE);
  class aa 
  {
function check($p_a,$p_b,$p_c)
{
  echo $p_a;
}

function dosome($p_b,$p_d,$p_e,$p_f,$p_g,$p_h)
{
   return 
$this-check(3,3,array(xx=$p_b,xzx=$p_d,xx=$p_e,yy=$p_c));
}
 }
  $l_aa=new aa();
 
$l_aa-dosome('2',3,4,5,'sddd','ddd');
?

Expected result:

* Undefined variable 


Actual result:
--
* Undefined variable 
* Fatal error: Allowed memory size of 536870912 bytes exhausted (tried
to allocate 140498868988960 bytes) in Unknown on line 0. 





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



#48228 [NoF-Opn]: Possible memory corruption

2009-05-20 Thread iddekingej at lycos dot com
 ID:   48228
 User updated by:  iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.3.0RC2
 New Comment:

This bug is closed wrongly because I did give feedback.

The request was to try a snapshot. I did try the snapshot and it din't
solve the problem. So I did responded (at 11 May 8:37pm UTC) and wrote
that it didn't solve the problem and give extra information about the
cause so I think I responed apriopiate


Previous Comments:


[2009-05-20 18:45:30] iddekingej at lycos dot com

No feedback was provided

This bug is closed wrongly because I did give feedback.


The request was to try a snapshot. I did try the snapshot and it din't
solve the problem. So I did responded (at 11 May 8:37pm UTC) and wrote
that it didn't solve the problem and give extra information about the
cause so I think I responed apriopiate.



[2009-05-19 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2009-05-11 20:37:48] iddekingej at lycos dot com

Thanks, but the latest snapshot din't fix the problem.

I managed to debug apache and php and found the following:

The field alloc_globals-mm_heap-reserve_size is (wrongly) overwritten
with some address while freeing memory.  This value contains therefore a
large number.
Next, in zend_mm_shutdown the following code is executed

  if (heap-reserve_size) {
 heap-reserve = _zend_mm_alloc_int(heap, heap-reserve_size 
ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC);
  }
This failed because reserve_size contains a very large number.

The corruption of alloc_globals-mm_heap-reserve_size happens in the
function  _zend_mm_free_int.This function is called from
shutdown_executor about line 327.
That is zend_ptr_stack_destroy(EG(arg_types_stack));

In the function _zend_mm_free_int a local var mm_block is loaded with
mm_block = ZEND_MM_HEADER_OF(p);
This header contains size=0,next=0 (hmm size=0 sounds wrong). 
The value in alloc_globals-mm_heap-reserve_size is corrupted later
on at the line *cache = (zend_mm_free_block*)mm_block; (about line
1968). 
So I guess that cache contains a wrong pointer.



This is as far as I could debug php.



[2009-05-11 09:45:55] j...@php.net

Please try using this CVS snapshot:

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

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





[2009-05-10 22:47:19] iddekingej at lycos dot com

Description:

The included example code was made for finding the reason
php5.3RC2/apache2 crashed with some php website (the websie is not
publicly available). The script didn't crash apache but failed
differently.
The script should fail with a 'undefined variable', it does but it also
displays the message Fatal error: Allowed memory size of 536870912
bytes exhausted (tried to allocate 140498868988960 bytes) in Unknown on
line 0. (The large number is probably a memory location).

This error only happens in the following situation:
* as a web page (CLI works OK)
* restart apache
* Load the page and the memory exhausted message is displayed.
* Reload the page and no memory exhausted message

Software/machine:
* 64Bit amd
* Kubuntu  8.10
* Apache 2.2.9
* PHP(5.3RC2) compiled with : 
'./configure' '--enable-zip' '--enable-soap' '--enable-sockets'
'--with-gd' '--with-pgsql' '--with-apxs2=/usr/bin/apxs2'
'--with-gettext' '--enable-cli' '--enable-mbstring'





Reproduce code:
---
?
function ex_handler($p_exception)
{
? Error:i?=$p_exception-getMessage()?/ibr/br/?
}

function
er_handler($p_errorno,$p_errstr,$p_errfile,$p_errline,$p_context)
{ 
   $l_exception=new Exception(Error $p_errorno at $p_errline in
'$p_errfile':$p_errstr); 
   throw $l_exception;
}

  set_Exception_Handler(ex_handler);
 
set_Error_Handler(er_handler,E_STRICT|E_WARNING|E_ALL|E_ERROR|E_NOTICE);
  class aa 
  {
function check($p_a,$p_b,$p_c)
{
  echo $p_a;
}

function dosome($p_b,$p_d,$p_e,$p_f,$p_g,$p_h)
{
   return 
$this-check(3,3,array(xx=$p_b,xzx=$p_d,xx=$p_e,yy=$p_c));
}
 }
  $l_aa=new aa();
 
$l_aa-dosome('2',3,4,5,'sddd','ddd');
?

Expected result:

* Undefined variable 


Actual result:
--
* Undefined variable 
* Fatal error: Allowed memory size

#48228 [Com]: Possible memory corruption

2009-05-11 Thread iddekingej at lycos dot com
 ID:   48228
 Comment by:   iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.3.0RC2
 New Comment:

Thanks, but the latest snapshot din't fix the problem.

I managed to debug apache and php and found the following:

The field alloc_globals-mm_heap-reserve_size is (wrongly) overwritten
with some address while freeing memory.  This value contains therefore a
large number.
Next, in zend_mm_shutdown the following code is executed

  if (heap-reserve_size) {
 heap-reserve = _zend_mm_alloc_int(heap, heap-reserve_size 
ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC);
  }
This failed because reserve_size contains a very large number.

The corruption of alloc_globals-mm_heap-reserve_size happens in the
function  _zend_mm_free_int.This function is called from
shutdown_executor about line 327.
That is zend_ptr_stack_destroy(EG(arg_types_stack));

In the function _zend_mm_free_int a local var mm_block is loaded with
mm_block = ZEND_MM_HEADER_OF(p);
This header contains size=0,next=0 (hmm size=0 sounds wrong). 
The value in alloc_globals-mm_heap-reserve_size is corrupted later
on at the line *cache = (zend_mm_free_block*)mm_block; (about line
1968). 
So I guess that cache contains a wrong pointer.



This is as far as I could debug php.


Previous Comments:


[2009-05-11 09:45:55] j...@php.net

Please try using this CVS snapshot:

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

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





[2009-05-10 22:47:19] iddekingej at lycos dot com

Description:

The included example code was made for finding the reason
php5.3RC2/apache2 crashed with some php website (the websie is not
publicly available). The script didn't crash apache but failed
differently.
The script should fail with a 'undefined variable', it does but it also
displays the message Fatal error: Allowed memory size of 536870912
bytes exhausted (tried to allocate 140498868988960 bytes) in Unknown on
line 0. (The large number is probably a memory location).

This error only happens in the following situation:
* as a web page (CLI works OK)
* restart apache
* Load the page and the memory exhausted message is displayed.
* Reload the page and no memory exhausted message

Software/machine:
* 64Bit amd
* Kubuntu  8.10
* Apache 2.2.9
* PHP(5.3RC2) compiled with : 
'./configure' '--enable-zip' '--enable-soap' '--enable-sockets'
'--with-gd' '--with-pgsql' '--with-apxs2=/usr/bin/apxs2'
'--with-gettext' '--enable-cli' '--enable-mbstring'





Reproduce code:
---
?
function ex_handler($p_exception)
{
? Error:i?=$p_exception-getMessage()?/ibr/br/?
}

function
er_handler($p_errorno,$p_errstr,$p_errfile,$p_errline,$p_context)
{ 
   $l_exception=new Exception(Error $p_errorno at $p_errline in
'$p_errfile':$p_errstr); 
   throw $l_exception;
}

  set_Exception_Handler(ex_handler);
 
set_Error_Handler(er_handler,E_STRICT|E_WARNING|E_ALL|E_ERROR|E_NOTICE);
  class aa 
  {
function check($p_a,$p_b,$p_c)
{
  echo $p_a;
}

function dosome($p_b,$p_d,$p_e,$p_f,$p_g,$p_h)
{
   return 
$this-check(3,3,array(xx=$p_b,xzx=$p_d,xx=$p_e,yy=$p_c));
}
 }
  $l_aa=new aa();
 
$l_aa-dosome('2',3,4,5,'sddd','ddd');
?

Expected result:

* Undefined variable 


Actual result:
--
* Undefined variable 
* Fatal error: Allowed memory size of 536870912 bytes exhausted (tried
to allocate 140498868988960 bytes) in Unknown on line 0. 





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



#48228 [NEW]: Possible memory corruption

2009-05-10 Thread iddekingej at lycos dot com
From: iddekingej at lycos dot com
Operating system: Linux
PHP version:  5.3.0RC2
PHP Bug Type: Scripting Engine problem
Bug description:  Possible memory corruption 

Description:

The included example code was made for finding the reason
php5.3RC2/apache2 crashed with some php website (the websie is not publicly
available). The script didn't crash apache but failed differently.
The script should fail with a 'undefined variable', it does but it also
displays the message Fatal error: Allowed memory size of 536870912 bytes
exhausted (tried to allocate 140498868988960 bytes) in Unknown on line 0.
(The large number is probably a memory location).

This error only happens in the following situation:
* as a web page (CLI works OK)
* restart apache
* Load the page and the memory exhausted message is displayed.
* Reload the page and no memory exhausted message

Software/machine:
* 64Bit amd
* Kubuntu  8.10
* Apache 2.2.9
* PHP(5.3RC2) compiled with : 
'./configure' '--enable-zip' '--enable-soap' '--enable-sockets'
'--with-gd' '--with-pgsql' '--with-apxs2=/usr/bin/apxs2' '--with-gettext'
'--enable-cli' '--enable-mbstring'





Reproduce code:
---
?
function ex_handler($p_exception)
{
? Error:i?=$p_exception-getMessage()?/ibr/br/?
}

function
er_handler($p_errorno,$p_errstr,$p_errfile,$p_errline,$p_context)
{ 
   $l_exception=new Exception(Error $p_errorno at $p_errline in
'$p_errfile':$p_errstr); 
   throw $l_exception;
}

  set_Exception_Handler(ex_handler);
 
set_Error_Handler(er_handler,E_STRICT|E_WARNING|E_ALL|E_ERROR|E_NOTICE);
  class aa 
  {
function check($p_a,$p_b,$p_c)
{
  echo $p_a;
}

function dosome($p_b,$p_d,$p_e,$p_f,$p_g,$p_h)
{
   return 
$this-check(3,3,array(xx=$p_b,xzx=$p_d,xx=$p_e,yy=$p_c));
}
 }
  $l_aa=new aa();
 
$l_aa-dosome('2',3,4,5,'sddd','ddd');
?

Expected result:

* Undefined variable 


Actual result:
--
* Undefined variable 
* Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to
allocate 140498868988960 bytes) in Unknown on line 0. 

-- 
Edit bug report at http://bugs.php.net/?id=48228edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48228r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48228r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48228r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48228r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48228r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48228r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48228r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48228r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48228r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48228r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48228r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48228r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48228r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48228r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48228r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48228r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48228r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48228r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48228r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48228r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48228r=mysqlcfg



#42496 [NEW]: cursor is not closed when using 2 clobs in a select query

2007-08-31 Thread iddekingej at lycos dot com
From: iddekingej at lycos dot com
Operating system: win 2000
PHP version:  5.2.4
PHP Bug Type: OCI8 related
Bug description:  cursor is not closed when using 2 clobs in a select query

Description:

When a query contains 2 clob fields then the cursor is not closed after
oci_free_statement.

I run the attached script with the following table
tblDocuments
(id number
,v1 clob
,v2 clob
)

After a while the script gives a ora-01000 (maximum number of open
cursors).

When tblDocuments contains only one clob field, the script keeps running
fine.

I can monitor opencursors with the following script:

select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic#  and s.sid=a.sid
and b.name = 'opened cursors current

When I monitor the script and tblDocuments has 2 clobs, the opencursor   
increases until maximum number of cursors is reached and the script failes
with a ora -0100.
When I momitor the script and tblDocument has 1 clob, the number of script
stays about the same.


The versions are

Windows 2000 server
Oracle 10.2.0.2 on the same machine
PHP 5.2.4 (File downloaded from php site)
Apache 2.2
Maximum number of cursors is 500

Version 5.2.2 and 5.2.3 has the same problem.

When I enable debug I get the following information

OCI8 DEBUG: OCIHandleAlloc at (ext\oci8\oci8_statement.c:61) 
OCI8 DEBUG: OCIStmtPrepare2 at (ext\oci8\oci8_statement.c:77) 
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:135) 
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:144) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:418) 
OCI8 DEBUG: OCIStmtExecute at (ext\oci8\oci8_statement.c:442) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:471) 
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563) 
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571) 
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:694) 
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563) 
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571) 
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676) 
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719) 
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563) 
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571) 
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676) 
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719)

OCI8 DEBUG: OCIStmtFetch at (ext\oci8\oci8_statement.c:168) 
OCI8 DEBUG: OCIStmtRelease at (ext\oci8\oci8_statement.c:746) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8_statement.c:757) 
OCI8 DEBUG: OCISessionEnd at (ext\oci8\oci8.c:1523) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1527)

OCI8 DEBUG: OCIServerDetach at (ext\oci8\oci8.c:1531) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1535) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1539) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1543) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1547) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:461) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:466) 



Reproduce code:
---
$l_res=oci_new_connect(username,password,sid);
oci_execute($l_st);

while(1){
$l_cnt++;
$l_st=oci_parse($l_res,select * from tblDocuments  where
id=$l_cnt );

oci_execute($l_st); 
$l_row=oci_fetch_row($l_st);
oci_free_statement($l_st);
echo $l_cnt,':';print_r($l_row);
}



-- 
Edit bug report at http://bugs.php.net/?id=42496edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42496r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42496r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http

#42496 [Opn]: cursor is not closed when using 2 clobs in a select query

2007-08-31 Thread iddekingej at lycos dot com
 ID:   42496
 User updated by:  iddekingej at lycos dot com
 Reported By:  iddekingej at lycos dot com
 Status:   Open
 Bug Type: OCI8 related
 Operating System: win 2000
 PHP Version:  5.2.4
 New Comment:

Sorry $l_cnt=0 is missing from the code. It should read:

$l_res=oci_new_connect(username,password,sid);
oci_execute($l_st);
$l_cnt=0;
while(1){
$l_cnt++;
$l_st=oci_parse($l_res,select * from tblDocuments  where
id=$l_cnt );

oci_execute($l_st); 
$l_row=oci_fetch_row($l_st);
oci_free_statement($l_st);
echo $l_cnt,':';print_r($l_row);
}


Previous Comments:


[2007-08-31 15:46:25] iddekingej at lycos dot com

Description:

When a query contains 2 clob fields then the cursor is not closed after
oci_free_statement.

I run the attached script with the following table
tblDocuments
(id number
,v1 clob
,v2 clob
)

After a while the script gives a ora-01000 (maximum number of open
cursors).

When tblDocuments contains only one clob field, the script keeps
running fine.

I can monitor opencursors with the following script:

select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic#  and s.sid=a.sid
and b.name = 'opened cursors current

When I monitor the script and tblDocuments has 2 clobs, the opencursor 
  increases until maximum number of cursors is reached and the script
failes with a ora -0100.
When I momitor the script and tblDocument has 1 clob, the number of
script stays about the same.


The versions are

Windows 2000 server
Oracle 10.2.0.2 on the same machine
PHP 5.2.4 (File downloaded from php site)
Apache 2.2
Maximum number of cursors is 500

Version 5.2.2 and 5.2.3 has the same problem.

When I enable debug I get the following information

OCI8 DEBUG: OCIHandleAlloc at (ext\oci8\oci8_statement.c:61) 
OCI8 DEBUG: OCIStmtPrepare2 at (ext\oci8\oci8_statement.c:77) 
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:135) 
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:144) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:418) 
OCI8 DEBUG: OCIStmtExecute at (ext\oci8\oci8_statement.c:442) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:471) 
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563) 
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571) 
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:694) 
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563) 
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571) 
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676) 
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719) 
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553) 
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563) 
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571) 
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676) 
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719)

OCI8 DEBUG: OCIStmtFetch at (ext\oci8\oci8_statement.c:168) 
OCI8 DEBUG: OCIStmtRelease at (ext\oci8\oci8_statement.c:746) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8_statement.c:757) 
OCI8 DEBUG: OCISessionEnd at (ext\oci8\oci8.c:1523) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1527)

OCI8 DEBUG: OCIServerDetach at (ext\oci8\oci8.c:1531) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1535) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1539) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1543) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1547) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:461) 
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:466) 



Reproduce code:
---
$l_res=oci_new_connect