Bug #62672 [Com]: Error on serialize of ArrayObject

[j dot henge-ernst at interexa dot de]

Edit report at https://bugs.php.net/bug.php?id=62672edit=1

 ID: 62672
 Comment by: j dot henge-ernst at interexa dot de
 Reported by:t dot weber at interexa dot de
 Summary:Error on serialize of ArrayObject
 Status: Open
 Type:   Bug
 Package:SPL related
 Operating System:   Cent OS
 PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

The problem is that the unserialize of ArrayIterator (and also maybe 
ArrayObject or other SPL classes) can not dereference object references.

A simpler Testcase:
?php
$x = new ArrayObject();
$t = array($x, $x-getIterator());
$s = serialize($t);
$e = unserialize($s);

Fatal error: Uncaught exception 'UnexpectedValueException' with message 'Error 
at offset 13 of 26 bytes' in /tmp/test2.php:5
Stack trace:
#0 [internal function]: ArrayIterator-unserialize('x:i:16777216;r:...')
#1 /tmp/test2.php(5): unserialize('a:2:{i:0;C:11:...')
#2 {main}
  thrown in /tmp/test2.php on line 5

If the order in the array is reversed it works, as now the ArrayObject is only 
a reference in the array.

Same behaviour with PHP 5.4.5


Previous Comments:

[2012-07-27 11:04:48] t dot weber at interexa dot de

Description:

Serialize and direct unserialize of Objects does not work if return value of 
ArrayObject::getIterator is contained in parent class (see Test script)

Test script:
---
class ObjA
{
private $_varA;

public function __construct(Iterator $source)
{
$this-_varA = $source;
}
}

class ObjB extends ObjA
{
private $_varB;

public function __construct(ArrayObject $keys)
{
$this-_varB = $keys;
parent::__construct($keys-getIterator());
}
}

$obj = new ObjB(new ArrayObject());

unserialize(serialize($obj));







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

Bug #51826 [Com]: maybe a wrong oop logic.

[j dot henge-ernst at interexa dot de]

Edit report at https://bugs.php.net/bug.php?id=51826edit=1

 ID: 51826
 Comment by: j dot henge-ernst at interexa dot de
 Reported by:1000235409 at smail dot shnu dot edu dot cn
 Summary:maybe a wrong oop logic.
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   WINDOWS
 PHP Version:5.3SVN-2010-05-14 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Seems to be fix with PHP 5.3.9


Previous Comments:

[2010-05-22 16:21:23] 1000235409 at smail dot shnu dot edu dot cn

?php
abstract class TAbstractParam {
  protected $FValue = null;
  public abstract function getType(); //getType
  public function Dump() {
return TYPE= . $this-getType() .  VALUE= . $this-FValue;
  }
}

interface IParam {
  public function getType(); //getType again.
}

class TStringParam extends TAbstractParam implements IParam {
  public function getType() {return 'VARCHAR'; } //another getType, the fatal 
error goes here.
}


see this example, please...


[2010-05-18 01:35:34] 1000235409 at smail dot shnu dot edu dot cn

there are other non-abstract methods inside the abstract class to provide some 
base behaviors for its children claclasses, which i omitted in this example. 
and those non-abstract methods may call the abstract methods. and an abstract 
class should not be defdefined as an instance cclass for an interface cuz an 
non-abstract one should, so why ambiguity?


[2010-05-17 19:51:45] crrodriguez at opensuse dot org

Expected behaviour, your code causes ambiguity.


[2010-05-14 17:42:35] 1000235409 at smail dot shnu dot edu dot cn

I have adapted those code(see it below) into delphi(object pascal, on 
Delphi2010), however, nothing wrong at all. so i think it should be a wrong oop 
logic in php5(5.2 included also, since i've tested then...)

Type
  TAbstractParam = Class(TInterfacedObject)
Procedure getType(); Virtual; Abstract;
  End;

  IParam = Interface
Procedure getType();
  End;

  TPrimativeParam = Class(TAbstractParam, IParam)
Procedure getType();
  End;
//Other code omitted...


[2010-05-14 17:15:02] 1000235409 at smail dot shnu dot edu dot cn

Description:

A fatal error generates when a class extends from an abstract class and 
implements 
from an interface both with a same named abstract (all methods defined inside 
interfaces are abstract) method inside.

Test script:
---
?php
abstract class TAbstractParam {
  public abstract function getType(); //getType
}

interface IParam {
  public function getType(); //getType again.
}

class TPrimativeParam extends TAbstractParam implements IParam {
  public function getType() {return 'VARCHAR'; } //another getType, the fatal 
error goes here.
}

Expected result:

[just nothing...]


Actual result:
--
Fatal error: Can't inherit abstract function IParam::getType() (previously 
declared abstract in TAbstractParam) in E:\foo.php on line 10






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

[PHP-BUG] Bug #62464 [NEW]: implementing two interfaces with same signature no longer gives a fatal error

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.3Git-2012-07-02 (Git)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:implementing two interfaces with same signature no longer gives 
a fatal error

Description:

having two different interfaces with same method no longer causes a fatal
error like in php 5.3.8. With fix for bug #43200 (my guess) it is now
possible to inherit another interface which has the same method signature
as a previous interface.

implementing an interface with methods which collide with a method name
which is already implemented by another interface should cause an error.

From my point of OOP it does not make sense as the meaning of the colliding
interface method do not express the same, else both interfaces with the
same signature part should extend that base interface.

It's the opposite of bug #46705

Such a change of the language should not be done in a minor release.

Test script:
---
?php

interface AInterface {
public function getLogicalKey();
}
interface BInterface {
public function getLogicalKey();
}
class AClass implements AInterface {
public function getLogicalKey() { return 1; }
}
class BClass extends AClass implements BInterface { }


Expected result:

Fatal error: Can't inherit abstract function BInterface::getLogicalKey()
(previously declared abstract in AInterface) in x.php on line 12



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

Bug #62464 [Opn]: implementing two interfaces with same signature no longer gives a fatal error

[j dot henge-ernst at interexa dot de]

Edit report at https://bugs.php.net/bug.php?id=62464edit=1

 ID: 62464
 User updated by:j dot henge-ernst at interexa dot de
 Reported by:j dot henge-ernst at interexa dot de
 Summary:implementing two interfaces with same signature no
 longer gives a fatal error
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   linux
 PHP Version:5.3Git-2012-07-02 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Your example is ok and should work correctly as both interfaces extend the same 
base interface and add different methods. In my given example AInterface and 
BInterface do not extend from a common interface. So the class which implements 
RewindableIterator, ReversableIterator must implement

from Iterator:
function current();
function key();
function next();
function valid();

from RewindableIterator:
function rewind();

from ReversableIterator:
function prev();

So lets change my example to:
interface AInterface {
/** @return Aclass[] */
public function getObjects();
}
interface BInterface {
/** @return Bclass[] */
public function getObjects();
}

class CClass implements AInterface, BInterface
{
public function getObjects() {
   return ???;
}
}
class AClass {
public function foo() { echo foo;}
}
class BClass {
public function bar() { echo bar;}
}


Previous Comments:

[2012-07-02 17:50:10] ni...@php.net

I'm not sure I see the problem. If the class satisfies both interfaces, why 
should there be an error?

E.g., consider:

interface Iterator {
function current();
function key();
function next();
function valid();
}

interface RewindableIterator extends Iterator {
function rewind();
}

interface ReversableIterator extends Iterator {
function prev();
}

class Foo implements RewindableIterator, ReversableIterator {
// ...
}

Why shouldn't the class be able to implement both, as long as the method 
declarations don't disagree?


[2012-07-02 16:11:52] j dot henge-ernst at interexa dot de

Description:

having two different interfaces with same method no longer causes a fatal error 
like in php 5.3.8. With fix for bug #43200 (my guess) it is now possible to 
inherit another interface which has the same method signature as a previous 
interface.

implementing an interface with methods which collide with a method name which 
is already implemented by another interface should cause an error.

From my point of OOP it does not make sense as the meaning of the colliding 
interface method do not express the same, else both interfaces with the same 
signature part should extend that base interface.

It's the opposite of bug #46705

Such a change of the language should not be done in a minor release.

Test script:
---
?php

interface AInterface {
public function getLogicalKey();
}
interface BInterface {
public function getLogicalKey();
}
class AClass implements AInterface {
public function getLogicalKey() { return 1; }
}
class BClass extends AClass implements BInterface { }


Expected result:

Fatal error: Can't inherit abstract function BInterface::getLogicalKey() 
(previously declared abstract in AInterface) in x.php on line 12








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

Bug #53829 [Com]: Compiling PHP with large file support will replace function gzopen by gzopen64

[j dot henge-ernst at interexa dot de]

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

 ID: 53829
 Comment by: j dot henge-ernst at interexa dot de
 Reported by:rilatonal at hotmail dot de
 Summary:Compiling PHP with large file support will replace
 function gzopen by gzopen64
 Status: Open
 Type:   Bug
 Package:Zlib related
 Operating System:   Linux
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

I also encountered that problem compiling php on solaris x86_64 with
zlib 1.2.5. I used the following configure commmand:



#! /bin/sh

#

# Created by configure



CFLAGS='-xmodel=small -m64 -Kpic -O4' \

CXXFLAGS='-xmodel=small -m64 -Kpic -O4' \

LDFLAGS='-m64' \

CC='cc' \

'./configure' \

'--prefix=/opt/IXAGib64' \

'--with-config-file-path=/opt/IXAGib64/etc' \

'--with-config-file-scan-dir=/opt/IXAGib64/etc/php.ini.d' \

'--disable-debug' \

'--enable-inline-optimization' \

'--disable-all' \

'--enable-ctype' \

'--enable-dom' \

'--enable-libxml' \

'--with-libxml-dir=/opt/IXAGib64' \

'--with-openssl=/opt/IXAGib64' \

'--with-pcre-regex' \

'--enable-session' \

'--enable-simplexml' \

'--enable-wddx' \

'--enable-xml' \

'--enable-hash' \

'--enable-json' \

'--enable-filter' \

'--with-zlib=/opt/IXAGib64' \

'--with-apxs2=/opt/IXAGib64/bin/apxs' \

'--with-pear' \

'--with-layout=GNU' \

$@


Previous Comments:

[2011-01-24 14:40:13] rilatonal at hotmail dot de

Description:

I am in the need of supporting large files in PHP.

For the first time I tried to compile PHP on a machine with zlib 1.2.5
installed.





After that, gzopen (and the other gz.. functions) is gone and is being
replaced by gzopen64 (or the other gz...64-functions).



Thats a big problem, because many PEAR-scripts (and other scripts, too)
expect gzopen to be there!



ZLIB is there (see the test scripts), but gzopen not!



Test script:
---
CFLAGS=-g -O3 -m32 -D_FILE_OFFSET_BITS=64 ./configure
--prefix=/tmp/php --with-config-file-path=/tmp/php/etc --disable-all
-with-zlib

make

make install



/tmp/php/bin/php -r 'var_dump(function_exists(gzopen));'

/tmp/php/bin/php -r 'var_dump(function_exists(gzopen64));'



/tmp/php/bin/php -r '$fp = fopen(compress.zlib://hello-world.txt.gz,
wb); fwrite($fp, Hello World!\n); fclose($fp);'

zcat hello-world.txt.gz

Expected result:

I expect gzopen to be there!



Actual result:
--
gzopen is being replaced by gzopen64!








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

Req #53322 [Com]: zend_mm_heap corrupted

[j dot henge-ernst at interexa dot de]

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

 ID: 53322
 Comment by: j dot henge-ernst at interexa dot de
 Reported by:alex at bintime dot com
 Summary:zend_mm_heap corrupted
 Status: Bogus
 Type:   Feature/Change Request
 Package:Apache2 related
 Operating System:   gentoo (kernel 2.6.32-r2)
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

We also encountered that problem and it is fixed in at least php 5.3.5.

That happend if an exception was thrown while __destruct was executed.


Previous Comments:

[2010-11-16 17:31:31] der...@php.net

Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader.  These extensions often modify engine
behavior which is not related to PHP itself.

.


[2010-11-16 17:01:35] alex at bintime dot com

Description:

After updating php from 5.2.14 version to 5.3.3-r1 site didn't work in
different moments of time. Apache error log showed this: 

[Fri Nov 12 00:14:52 2010] [notice] child pid 1389 exit signal
Segmentation fault (11)

[Fri Nov 12 00:14:55 2010] [notice] child pid 1361 exit signal
Segmentation fault (11)

zend_mm_heap corrupted

zend_mm_heap corrupted



After downgrading php from 5.3.3-r1 version to 5.2.14 problem has gone
away.



php was compiled without problems(I didn't receive any error or warning
messages)

php was compiled with next USE flags:

apache2 bcmath berkdb bzip2 calendar cgi cli crypt ctype curl
curlwrappers exif fileinfo filter flatfile ftp gd gdbm hash iconv imap
ipv6 json mysql mysqli nls pcntl phar posix readline session simplexml
snmp soap sockets ssl sysvipc threads tokenizer truetype unicode wddx
xml xmlreader xmlrpc xmlwriter xsl zip zlib



All deprecated INI directives was changed in php.ini file and deprecated
functions were replaced in site code.



All dev-php5/* modules were recompiled.

Here they are:

dev-php5/pecl-http-1.6.6

dev-php5/pecl-memcache-3.0.5

dev-php5/xcache-1.3.0



Please, can you suggest what caused this problem?

If it is fixed in CVS, can you provide me with php version that hasn't
this problem? So I can wait for it in gentoo portage.









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

[PHP-BUG] Bug #54270 [NEW]: .user.ini not working on network shared DOCUMENT_ROOT

[j dot henge-ernst at interexa dot de]

From: 
Operating system: Windows
PHP version:  5.3.5
Package:  PHP options/info functions
Bug Type: Bug
Bug description:.user.ini not working on network shared DOCUMENT_ROOT

Description:

From phpinfo for the file:

_SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/

_SERVER[SCRIPT_FILENAME]  
//htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php



In processmonitor I only see one access try to

\\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini

and not to

\\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini

\\htdocserv\htdocsns\user\hernst\head\xml\.user.ini

...



I have one .user.ini file in

C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini

 Volume in drive \\htdocserv\htdocsns is htdocsns

 Volume Serial Number is AF3D-2838

 Directory of \\htdocserv\htdocsns\user\hernst\head\xml

16.03.2011  11:4019 .user.ini

   1 File(s) 19 bytes



Seems the alogrith does not work properly with the network shares on
windows and trying to macht the Document-Root to the current file


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

Bug #54270 [Fbk-Asn]: .user.ini not working on network shared DOCUMENT_ROOT

[j dot henge-ernst at interexa dot de]

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

 ID: 54270
 User updated by:j dot henge-ernst at interexa dot de
 Reported by:j dot henge-ernst at interexa dot de
 Summary:.user.ini not working on network shared
 DOCUMENT_ROOT
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Windows
 PHP Version:5.3.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Can't use it as drive because apache does not start then:

DocumentRoot z:/

DocumentRoot z:

DocumentRoot z:/

leads to a Syntax error on line 6 of C:/Program
Files/Zend/Apache2/conf/default-with-letter.conf



Using

DocumentRoot //htdocserv/htdocsns

works

This might happen for apache as Z: is not available in that context.
Running apache as Service with NT AUTHORITY\NetworkService Account.


Previous Comments:

[2011-03-16 13:39:05] paj...@php.net

Any reason why you don't mount it instead?



However it should work anyway, but can you try by mounting this path as
a folder 

or drive please?


[2011-03-16 13:20:03] j dot henge-ernst at interexa dot de

Description:

From phpinfo for the file:

_SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/

_SERVER[SCRIPT_FILENAME]  
//htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php



In processmonitor I only see one access try to

\\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini

and not to

\\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini

\\htdocserv\htdocsns\user\hernst\head\xml\.user.ini

...



I have one .user.ini file in

C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini

 Volume in drive \\htdocserv\htdocsns is htdocsns

 Volume Serial Number is AF3D-2838

 Directory of \\htdocserv\htdocsns\user\hernst\head\xml

16.03.2011  11:4019 .user.ini

   1 File(s) 19 bytes



Seems the alogrith does not work properly with the network shares on
windows and trying to macht the Document-Root to the current file







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

Bug #54270 [Asn]: .user.ini not working on network shared DOCUMENT_ROOT

[j dot henge-ernst at interexa dot de]

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

 ID: 54270
 User updated by:j dot henge-ernst at interexa dot de
 Reported by:j dot henge-ernst at interexa dot de
 Summary:.user.ini not working on network shared
 DOCUMENT_ROOT
 Status: Assigned
 Type:   Bug
 Package:PHP options/info functions
-Operating System:   Windows
+Operating System:   Windows Server 2003 R2 SP2
 PHP Version:5.3.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Sorry, can't get the network share to map to a sirectory. The typical
thing with junction and mklink commands does not seem to work on Windows
Server 2003 R2 SP2. Or is there any other command to map the share to a
directory in Windows Server 2003 R2?


Previous Comments:

[2011-03-16 14:22:40] paj...@php.net

That's rather weird, it works just fine here. But that's hardly a php
problem (the 

conf error).



What if you use a folder? Mounting the share as c:\apache\htdocs for
example?


[2011-03-16 14:00:34] j dot henge-ernst at interexa dot de

Can't use it as drive because apache does not start then:

DocumentRoot z:/

DocumentRoot z:

DocumentRoot z:/

leads to a Syntax error on line 6 of C:/Program
Files/Zend/Apache2/conf/default-with-letter.conf



Using

DocumentRoot //htdocserv/htdocsns

works

This might happen for apache as Z: is not available in that context.
Running apache as Service with NT AUTHORITY\NetworkService Account.


[2011-03-16 13:39:05] paj...@php.net

Any reason why you don't mount it instead?



However it should work anyway, but can you try by mounting this path as
a folder 

or drive please?


[2011-03-16 13:20:03] j dot henge-ernst at interexa dot de

Description:

From phpinfo for the file:

_SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/

_SERVER[SCRIPT_FILENAME]  
//htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php



In processmonitor I only see one access try to

\\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini

and not to

\\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini

\\htdocserv\htdocsns\user\hernst\head\xml\.user.ini

...



I have one .user.ini file in

C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini

 Volume in drive \\htdocserv\htdocsns is htdocsns

 Volume Serial Number is AF3D-2838

 Directory of \\htdocserv\htdocsns\user\hernst\head\xml

16.03.2011  11:4019 .user.ini

   1 File(s) 19 bytes



Seems the alogrith does not work properly with the network shares on
windows and trying to macht the Document-Root to the current file







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

[PHP-BUG] Bug #54011 [NEW]: array_merge_recursive does not use free numeric keys

[j dot henge-ernst at interexa dot de]

From: 
Operating system: linux
PHP version:  5.3.5
Package:  Arrays related
Bug Type: Bug
Bug description:array_merge_recursive does not use free numeric keys

Description:

If you use array_merge_recursive to join arrays which have different
numeric keys, free keys are nor used if the later array has a key which is
below the first/highest key.

Test script:
---
var_dump(array_merge_recursive(

array(a = array(5 = 7)),

array(a = array(3 = 8))

));'



Expected result:

array(1) {

  [a]=

  array(2) {

[3]=

string(1) 8

[5]=

string(1) 7

  }

}



Actual result:
--
array(1) {

  [a]=

  array(2) {

[5]=

string(1) 7

[6]=

string(1) 8

  }

}



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

Bug #52890 [Fbk-Opn]: Exception not caught sometimes

[j dot henge-ernst at interexa dot de]

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

 ID: 52890
 User updated by:j dot henge-ernst at interexa dot de
 Reported by:j dot henge-ernst at interexa dot de
 Summary:Exception not caught sometimes
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Happend with php 5.2.2 from Zend Server, happens with php 5.3.3 from
php.net and from Zend Server 5.0.3 and with snapshot 5.3-201009280630
from php.net



configure was:

'./configure' '--with-libdir=lib64'
'--prefix=/usr/local/php.net/5.3-201009280630' '--with-mysql'
'--enable-zip' '--enable-pcntl' '--with-gd' '--with-apxs2'
'--with-freetype-dir=yes' '--enable-gd-native-ttf' '--enable-mbstring'
'--enable-calendar' '--enable-pcntl'
'--with-oci8=instantclient,/interexa/lib64/oracle/instantclient_11_2'
'--with-config-file-path=/usr/local/zend/etc'


Previous Comments:

[2010-09-28 03:49:27] wakamonka747 at hotmail dot com

Forgot to mention that I checked this behaviour with xdebug. You
actually see how it just skips there.


[2010-09-28 03:47:22] wakamonka747 at hotmail dot com

I'm experiencing the same in PHP 5.3.3 under Windows XP SP3, running as
an apache 2.2.9 module.



An exception is thrown but is only caught by the outer most catch
block.



i.e:



try {

   try {

 throw new Exception('foo');

   }

   catch(Exception $e) {

//Execution should follow here

   }  

}

catch(Exception $e) {

//Execution follows here

}



Although in my case there's no __destruct method implied


[2010-09-27 16:09:16] f...@php.net

Please try to reproduce with PHP 5.3.3 from
http://www.php.net/downloads.php 

instead of Zend Server or file a bug report with Zend.


[2010-09-24 13:26:24] j dot henge-ernst at interexa dot de

We have tracked down the problem further using the Zend Code Tracer. It
shows that before the throw is executed several objects are freed and
there __destruct are called. After that the Execution stack seems to be
corrupt and the Exception is not caught on the expected place.

Improving the testscript and adopting these experience still don't yield
that problem. It seems that it only happens if the garbage collection?
is run at the same time. For one executing path the exception works, but
for another execution path it yields that error because additional
objects are created.



In the __destruct we free additional references to other object so we do
not have a memory problem in PHP 5.2.x



The __destruct now looks like and fixes the problem:



public function __destruct(){

if (version_compare(PHP_VERSION, '5.3.0', '=')) {

return;

}

$this-_invalidateFieldChanges();

$this-_objects = null;

$this-_data = null;

$this-_getfcache = null;

}



Url to the code traces:

http://entw.mainz.interexa.de/entw/hernst/phpbuild/phpbug52890-zend-code-trace-zsf.zip
(15MB)

File trace-0-15823-1-20100924.zsf has that error, file
trace-0-16180-1-20100924.zsf works as expected.

File trace-0-29017-1-20100924.zsf also does not catch an exception but
is simpler and has less references to other objects.



I will also provide the xml files of the trace if the export works in
the Zend Server.


[2010-09-20 07:28:47] j dot henge-ernst at interexa dot de

Description:

An Exception thrown is not caught by the corresponding catch block,
instead the global exception handler is invoked. That only happens on
one page during a long selenium test case. The bug is reproduceable with
the selenium test script, but stripping the code to a small example does
not result in an error. Will will add the stripped version of the code
which does not fail, but show the code.



The System is a 64bit Zend Server 5.3 CE on CentOS 5.5. The same code on
a Zend Server 5.2 CE does not have this problem. The problem also
occurred in PHP 5.3.2





In the example script $defer should be set to true but instead of
catching the excepetion in that block the global exception handler is
called.



A fix for this is currently to use bofre the throw:

if (version_compare(PHP_VERSION, '5.3.0', '=') 
version_compare(PHP_VERSION, '5.3.3', '=')) {

   set_exception_handler(create_function('$exception', 'return
$exception instanceof iwat_ui_controller_ObjectSaveDeferredException ?
true : userExceptionHandler($exception);'));

}

as the application behaves as expected, but that bug still exists.
Disabling all Zend modules has no effect

Test script

Bug #52890 [Opn-Csd]: Exception not caught sometimes

[j dot henge-ernst at interexa dot de]

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

 ID: 52890
 User updated by:j dot henge-ernst at interexa dot de
 Reported by:j dot henge-ernst at interexa dot de
 Summary:Exception not caught sometimes
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Sorry have to correct me, with snapshot 5.3-201009280630 the problem no
longer occurs. Might be fixed with bug #52361 which hadn't made it into
5.3.3


Previous Comments:

[2010-09-28 10:10:55] j dot henge-ernst at interexa dot de

Happend with php 5.2.2 from Zend Server, happens with php 5.3.3 from
php.net and from Zend Server 5.0.3 and with snapshot 5.3-201009280630
from php.net



configure was:

'./configure' '--with-libdir=lib64'
'--prefix=/usr/local/php.net/5.3-201009280630' '--with-mysql'
'--enable-zip' '--enable-pcntl' '--with-gd' '--with-apxs2'
'--with-freetype-dir=yes' '--enable-gd-native-ttf' '--enable-mbstring'
'--enable-calendar' '--enable-pcntl'
'--with-oci8=instantclient,/interexa/lib64/oracle/instantclient_11_2'
'--with-config-file-path=/usr/local/zend/etc'


[2010-09-28 03:49:27] wakamonka747 at hotmail dot com

Forgot to mention that I checked this behaviour with xdebug. You
actually see how it just skips there.


[2010-09-28 03:47:22] wakamonka747 at hotmail dot com

I'm experiencing the same in PHP 5.3.3 under Windows XP SP3, running as
an apache 2.2.9 module.



An exception is thrown but is only caught by the outer most catch
block.



i.e:



try {

   try {

 throw new Exception('foo');

   }

   catch(Exception $e) {

//Execution should follow here

   }  

}

catch(Exception $e) {

//Execution follows here

}



Although in my case there's no __destruct method implied


[2010-09-27 16:09:16] f...@php.net

Please try to reproduce with PHP 5.3.3 from
http://www.php.net/downloads.php 

instead of Zend Server or file a bug report with Zend.


[2010-09-24 13:26:24] j dot henge-ernst at interexa dot de

We have tracked down the problem further using the Zend Code Tracer. It
shows that before the throw is executed several objects are freed and
there __destruct are called. After that the Execution stack seems to be
corrupt and the Exception is not caught on the expected place.

Improving the testscript and adopting these experience still don't yield
that problem. It seems that it only happens if the garbage collection?
is run at the same time. For one executing path the exception works, but
for another execution path it yields that error because additional
objects are created.



In the __destruct we free additional references to other object so we do
not have a memory problem in PHP 5.2.x



The __destruct now looks like and fixes the problem:



public function __destruct(){

if (version_compare(PHP_VERSION, '5.3.0', '=')) {

return;

}

$this-_invalidateFieldChanges();

$this-_objects = null;

$this-_data = null;

$this-_getfcache = null;

}



Url to the code traces:

http://entw.mainz.interexa.de/entw/hernst/phpbuild/phpbug52890-zend-code-trace-zsf.zip
(15MB)

File trace-0-15823-1-20100924.zsf has that error, file
trace-0-16180-1-20100924.zsf works as expected.

File trace-0-29017-1-20100924.zsf also does not catch an exception but
is simpler and has less references to other objects.



I will also provide the xml files of the trace if the export works in
the Zend Server.




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/bug.php?id=52890


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

Bug #52890 [Opn]: Exception not caught sometimes

[j dot henge-ernst at interexa dot de]

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

 ID: 52890
 User updated by:j dot henge-ernst at interexa dot de
 Reported by:j dot henge-ernst at interexa dot de
 Summary:Exception not caught sometimes
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

We have tracked down the problem further using the Zend Code Tracer. It
shows that before the throw is executed several objects are freed and
there __destruct are called. After that the Execution stack seems to be
corrupt and the Exception is not caught on the expected place.

Improving the testscript and adopting these experience still don't yield
that problem. It seems that it only happens if the garbage collection?
is run at the same time. For one executing path the exception works, but
for another execution path it yields that error because additional
objects are created.



In the __destruct we free additional references to other object so we do
not have a memory problem in PHP 5.2.x



The __destruct now looks like and fixes the problem:



public function __destruct(){

if (version_compare(PHP_VERSION, '5.3.0', '=')) {

return;

}

$this-_invalidateFieldChanges();

$this-_objects = null;

$this-_data = null;

$this-_getfcache = null;

}



Url to the code traces:

http://entw.mainz.interexa.de/entw/hernst/phpbuild/phpbug52890-zend-code-trace-zsf.zip
(15MB)

File trace-0-15823-1-20100924.zsf has that error, file
trace-0-16180-1-20100924.zsf works as expected.

File trace-0-29017-1-20100924.zsf also does not catch an exception but
is simpler and has less references to other objects.



I will also provide the xml files of the trace if the export works in
the Zend Server.


Previous Comments:

[2010-09-20 07:28:47] j dot henge-ernst at interexa dot de

Description:

An Exception thrown is not caught by the corresponding catch block,
instead the global exception handler is invoked. That only happens on
one page during a long selenium test case. The bug is reproduceable with
the selenium test script, but stripping the code to a small example does
not result in an error. Will will add the stripped version of the code
which does not fail, but show the code.



The System is a 64bit Zend Server 5.3 CE on CentOS 5.5. The same code on
a Zend Server 5.2 CE does not have this problem. The problem also
occurred in PHP 5.3.2





In the example script $defer should be set to true but instead of
catching the excepetion in that block the global exception handler is
called.



A fix for this is currently to use bofre the throw:

if (version_compare(PHP_VERSION, '5.3.0', '=') 
version_compare(PHP_VERSION, '5.3.3', '=')) {

   set_exception_handler(create_function('$exception', 'return
$exception instanceof iwat_ui_controller_ObjectSaveDeferredException ?
true : userExceptionHandler($exception);'));

}

as the application behaves as expected, but that bug still exists.
Disabling all Zend modules has no effect

Test script:
---
try {

doSave();

} catch (iwat_ui_controller_ObjectSaveDeferredException $e) {

$defer = true;

} catch (IWATException $e) {

}



function doSave() {

throw new iwat_ui_controller_ObjectSaveDeferredException();

}







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

[PHP-BUG] Bug #52890 [NEW]: Exception not caught sometimes

[j dot henge-ernst at interexa dot de]

From: 
Operating system: Linux
PHP version:  5.3.3
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Exception not caught sometimes

Description:

An Exception thrown is not caught by the corresponding catch block, instead
the global exception handler is invoked. That only happens on one page
during a long selenium test case. The bug is reproduceable with the
selenium test script, but stripping the code to a small example does not
result in an error. Will will add the stripped version of the code which
does not fail, but show the code.



The System is a 64bit Zend Server 5.3 CE on CentOS 5.5. The same code on a
Zend Server 5.2 CE does not have this problem. The problem also occurred in
PHP 5.3.2





In the example script $defer should be set to true but instead of catching
the excepetion in that block the global exception handler is called.



A fix for this is currently to use bofre the throw:

if (version_compare(PHP_VERSION, '5.3.0', '=') 
version_compare(PHP_VERSION, '5.3.3', '=')) {

   set_exception_handler(create_function('$exception', 'return $exception
instanceof iwat_ui_controller_ObjectSaveDeferredException ? true :
userExceptionHandler($exception);'));

}

as the application behaves as expected, but that bug still exists.
Disabling all Zend modules has no effect

Test script:
---
try {

doSave();

} catch (iwat_ui_controller_ObjectSaveDeferredException $e) {

$defer = true;

} catch (IWATException $e) {

}



function doSave() {

throw new iwat_ui_controller_ObjectSaveDeferredException();

}


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

#49797 [NEW]: strnatcmp and strings ending with 0

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.3.0
PHP Bug Type: Strings related
Bug description:  strnatcmp and strings ending with 0

Description:

strnatcmp returns wrong results when one string is ending with a zero. At
leat in php 5.2.9 the expected result is returned. In php 5.3.0 and 5.2.10
it is broken.

Reproduce code:
---
?php
echo strnatcmp('b0',  'b0$')  . \n;
echo strnatcmp('b1',  'b1$')  . \n;
echo strnatcmp('b0x', 'b0x$') . \n;

echo strnatcasecmp('b0',  'B0$')  . \n;
echo strnatcasecmp('b1',  'B1$')  . \n;
echo strnatcasecmp('b0x', 'B0x$') . \n;


Expected result:

-1
-1
-1
-1
-1
-1

Actual result:
--
1
-1
-1
1
-1
-1

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

#49797 [Fbk-Csd]: strnatcmp and strings ending with 0

[j dot henge-ernst at interexa dot de]

 ID:   49797
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   Feedback
+Status:   Closed
 Bug Type: Strings related
 Operating System: linux
 PHP Version:  5.3.0
 New Comment:

Snapshot php53-200910070830 and php52-200910070830 work as expected


Previous Comments:


[2009-10-07 08:13:11] paj...@php.net

Pls see #44929 and try a snapshot as well.



[2009-10-06 21:55:55] j dot henge-ernst at interexa dot de

Description:

strnatcmp returns wrong results when one string is ending with a zero.
At leat in php 5.2.9 the expected result is returned. In php 5.3.0 and
5.2.10 it is broken.

Reproduce code:
---
?php
echo strnatcmp('b0',  'b0$')  . \n;
echo strnatcmp('b1',  'b1$')  . \n;
echo strnatcmp('b0x', 'b0x$') . \n;

echo strnatcasecmp('b0',  'B0$')  . \n;
echo strnatcasecmp('b1',  'B1$')  . \n;
echo strnatcasecmp('b0x', 'B0x$') . \n;


Expected result:

-1
-1
-1
-1
-1
-1

Actual result:
--
1
-1
-1
1
-1
-1





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

#49560 [NEW]: OCI_RETURN_LOBS causes php_shutdown to take very long

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.2.10
PHP Bug Type: OCI8 related
Bug description:  OCI_RETURN_LOBS causes php_shutdown to take very long

Description:

If you read a lot of clobs/blob via oci_fetch_array($stmt,
OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS) it causes php_shutdown to take
a very long time.

Depending on the rows you read via oci_fetch_array the php_shutdown takes
longer and longer. Examples:

10.000  rows read with one lob column  0.1 seconds
20.000  rows read with one lob column2 seconds
30.000  rows read with one lob column8 seconds
40.000  rows read with one lob column   28 seconds
50.000  rows read with one lob column   60 seconds
100.000 rows read with one lob column 1800 seconds

This also happens if you skip the OCI_RETURN_LOBS and you don't use -free
on the returned lob-object.

Tested with oci8 extension form php 5.2.10 and php 5.3.0

Reproduce code:
---
$conn   = oci_connect($user, $user, $db);
$tcst = oci_parse($conn, 'CREATE TABLE TESTTABLE ( PK NUMBER NOT NULL, TB
BLOB , CONSTRAINT TABLE1_PK PRIMARY KEY ( PK) ENABLE)');
oci_execute($tcst);
oci_free_statement($tcst);
for ($i = 1; $i = 1; ++$i) {
 $stmt = oci_parse($conn, insert into testtable (PK, TB) values(:PK,
:TB));
 oci_bind_by_name($stmt, ':PK', $i, -1);
 $lob  = oci_new_descriptor($conn, OCI_DTYPE_LOB);
 oci_bind_by_name($stmt, ':TB', $lob, -1, OCI_B_BLOB);
 $lob-writeTemporary('', OCI_TEMP_BLOB);
 oci_execute($stmt, OCI_DEFAULT);
 $lob-close();
 $lob-free();
 oci_free_statement($stmt);
}
oci_commit($conn);
for ($i = 0; $i = 10; ++$i) {
$stmt = oci_parse($conn, 'Select PK, TB FROM TESTTABLE');
oci_execute($stmt, OCI_DEFAULT);
OCISetPrefetch($stmt, 100);
while (($row = oci_fetch_array($stmt,
OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS )) !== false);
oci_free_statement($stmt);
}



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

#49560 [Fbk-Opn]: OCI_RETURN_LOBS causes php_shutdown to take very long

[j dot henge-ernst at interexa dot de]

 ID:   49560
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  5.2.10
 Assigned To:  sixd
 New Comment:

Using oracle 11 instant client with Oracle 11.0.7 database

yes end of the php process. After the php script on the command line
has finished the gdb shows something like the following in the
backtrace:
0x7f5e231da5b0 in php_oci_descriptor_delete_from_hash
(data=0x7f35610, id=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1497
1497if (descriptor  desc_id  descriptor-id ==
*desc_id) {
(gdb) where
#0  0x7f5e231da5b0 in php_oci_descriptor_delete_from_hash
(data=0x7f35610, id=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1497
#1  0x007503c5 in zend_hash_apply_with_argument (ht=0xf3e670,
apply_func=0x7f5e231da57d php_oci_descriptor_delete_from_hash,
argument=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:697
#2  0x7f5e231e5c9c in php_oci_lob_free (descriptor=0xbb8ebe8) at
/home/hernst/src/php-5.3.0/ext/oci8/oci8_lob.c:672
#3  0x7f5e231da3c4 in php_oci_descriptor_list_dtor
(entry=0xbb8e5d8) at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1386
#4  0x0075276a in list_entry_destructor (ptr=0xbb8e5d8) at
/home/hernst/src/php-5.3.0/Zend/zend_list.c:184
#5  0x00750163 in zend_hash_apply_deleter (ht=0xd680f0,
p=0xbb8ec30) at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:611
#6  0x00750255 in zend_hash_graceful_reverse_destroy
(ht=0xd680f0) at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:646
#7  0x007528ba in zend_destroy_rsrc_list (ht=0xd680f0) at
/home/hernst/src/php-5.3.0/Zend/zend_list.c:240
#8  0x00740e21 in zend_deactivate () at
/home/hernst/src/php-5.3.0/Zend/zend.c:896
#9  0x006d812d in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-5.3.0/main/main.c:1576
#10 0x0081e11e in main (argc=3, argv=0x7fff9852fb98) at
/home/hernst/src/php-5.3.0/sapi/cli/php_cli.c:1369

(gdb) up
#1  0x007503c5 in zend_hash_apply_with_argument (ht=0xf3e670,
apply_func=0x7f5e231da57d php_oci_descriptor_delete_from_hash,
argument=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:697
(gdb) print ht-nTableSize
$1 = 262144


I run the script from commandline with
time php script.php 10
When the php script has outputed the last thing the php process takes
very long till it finaly returns to the command line.
Guess it's more like a oci_free_lob-count issue you mentoined. Is there
a newer version to try?


Previous Comments:


[2009-09-15 15:17:04] s...@php.net

What version Oracle client and database?

By shutdown do you mean end-of-web-request, or shutdown of the PHP
process?

It might be a symptom of a LOB ref count issue we've recently
uncovered, or it might just be Oracle having to clean up.





[2009-09-15 12:20:06] j dot henge-ernst at interexa dot de

Description:

If you read a lot of clobs/blob via oci_fetch_array($stmt,
OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS) it causes php_shutdown to
take a very long time.

Depending on the rows you read via oci_fetch_array the php_shutdown
takes longer and longer. Examples:

10.000  rows read with one lob column  0.1 seconds
20.000  rows read with one lob column2 seconds
30.000  rows read with one lob column8 seconds
40.000  rows read with one lob column   28 seconds
50.000  rows read with one lob column   60 seconds
100.000 rows read with one lob column 1800 seconds

This also happens if you skip the OCI_RETURN_LOBS and you don't use
-free on the returned lob-object.

Tested with oci8 extension form php 5.2.10 and php 5.3.0

Reproduce code:
---
$conn   = oci_connect($user, $user, $db);
$tcst = oci_parse($conn, 'CREATE TABLE TESTTABLE ( PK NUMBER NOT NULL,
TB BLOB , CONSTRAINT TABLE1_PK PRIMARY KEY ( PK) ENABLE)');
oci_execute($tcst);
oci_free_statement($tcst);
for ($i = 1; $i = 1; ++$i) {
 $stmt = oci_parse($conn, insert into testtable (PK, TB)
values(:PK, :TB));
 oci_bind_by_name($stmt, ':PK', $i, -1);
 $lob  = oci_new_descriptor($conn, OCI_DTYPE_LOB);
 oci_bind_by_name($stmt, ':TB', $lob, -1, OCI_B_BLOB);
 $lob-writeTemporary('', OCI_TEMP_BLOB);
 oci_execute($stmt, OCI_DEFAULT);
 $lob-close();
 $lob-free();
 oci_free_statement($stmt);
}
oci_commit($conn);
for ($i = 0; $i = 10; ++$i) {
$stmt = oci_parse($conn, 'Select PK, TB FROM TESTTABLE');
oci_execute($stmt, OCI_DEFAULT);
OCISetPrefetch($stmt, 100);
while (($row = oci_fetch_array($stmt,
OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS )) !== false);
oci_free_statement($stmt

#40783 [NEW]: odbc_close always returns null

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.2.1
PHP Bug Type: ODBC related
Bug description:  odbc_close always returns null

Description:

the odbc_close function always returns null instead of a boolean value as
stated in the documentation for odbc_close. In the souce of php_odbc.c
there is no RETURN_TRUE or RETURN_FALSE. So is either the docmentation
outdated or is in the sourcecode something missing?

Reproduce code:
---
$con = odbc_connect(autot32, db2inst1, interexa);
$ret = odbc_close($con);
var_dump($ret);


Expected result:

bool(true)

Actual result:
--
NULL

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

#40783 [Opn-Bgs]: odbc_close always returns null

[j dot henge-ernst at interexa dot de]

 ID:   40783
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   Open
+Status:   Bogus
 Bug Type: ODBC related
 Operating System: linux
 PHP Version:  5.2.1
 New Comment:

seems the documentation has changed, odbc_close allways returns null in
newer version


Previous Comments:


[2007-03-12 12:23:09] j dot henge-ernst at interexa dot de

Description:

the odbc_close function always returns null instead of a boolean value
as stated in the documentation for odbc_close. In the souce of
php_odbc.c there is no RETURN_TRUE or RETURN_FALSE. So is either the
docmentation outdated or is in the sourcecode something missing?

Reproduce code:
---
$con = odbc_connect(autot32, db2inst1, interexa);
$ret = odbc_close($con);
var_dump($ret);


Expected result:

bool(true)

Actual result:
--
NULL





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

#38788 [NEW]: cloning and and references inside the objects

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.1.6
PHP Bug Type: Scripting Engine problem
Bug description:  cloning and  and references inside the objects

Description:

I encountered a problem similar to the bug #27268
http://bugs.php.net/bug.php?id=27268

The attribut b of the cloned object is still pointing to the attribut of
its original object. So changing the attribut in the cloned object also
changes the attribute in the original object.

Reproduce code:
---
?php

class a {
protected $a = array();
protected $b = '';
public function __construct($b) { $this-b = $b; $this-a['f'] =
$this-b; }
public function setB($b) { $this-b = $b; }
public function printB() { echo __CLASS__ . $this-b . '/' .
$this-a['f'] .\n; }
public function __clone() { unset($this-a['f']); $this-a['f'] =
$this-b; }
}

$x1 = new a(5);
$x2 = clone $x1;
$x2-setB(7);
$x1-printB();
$x2-printB();



Expected result:

a5/5
a7/7

Actual result:
--
a7/7
a7/7

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

#38533 [NEW]: problems connection to database with NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5CVS-2006-08-21 (snap)
PHP Bug Type: OCI8 related
Bug description:  problems connection to database with 
NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15

Description:

php is unable to connect to the database if
NLS_LANG=GERMAN_GERMANY.charset is set to something other than
AMERICAN_AMERICA.charset

[EMAIL PROTECTED]:/tmp/phptest/install export
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
[EMAIL PROTECTED]:/tmp/phptest/install bin/php test.php
X-Powered-By: PHP/5.2.0RC3-dev
Content-type: text/html

resource(1) of type (oci8 connection)
[EMAIL PROTECTED]:/tmp/phptest/install export
NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15
[EMAIL PROTECTED]:/tmp/phptest/install bin/php test.php
X-Powered-By: PHP/5.2.0RC3-dev
Content-type: text/html

br /
bWarning/b:  oci_connect() [a
href='function.oci-connect'function.oci-connect/a]: ORA-00604: error
occurred at recursive SQL level 1
ORA-00922: missing or invalid option in
b/tmp/phptest/install/test.php/b on line b3/bbr /
bool(false)

Additional this php crashes if the third parameter (dbname) of oci_connect
is ommited

Using oracle 10g with oci8:
Version   1.2.1
Revision  $Revision: 1.269.2.16.2.18 $

connect with sqlplus works for both NLS_LANG settings

Reproduce code:
---
var_dump(oci_connect('scott', 'tiger', '(DESCRIPTION =(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = example.com)(PORT = 1521)))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = example)))'));


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

#37886 [Fbk-Opn]: oci_connect crashes php when charset-parameter is given

[j dot henge-ernst at interexa dot de]

 ID:   37886
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  5.1.4
 New Comment:

Still the same with the lastest snapshot

Starting program: /root/src/php5.2-200606230630/sapi/cli/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 182929799936 (LWP 13713)]
*** glibc detected *** realloc(): invalid pointer: 0x007b4378
***

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182929799936 (LWP 13713)]
0x002a97006af5 in memcpy () from /lib64/tls/libc.so.6
(gdb) where
#0  0x002a97006af5 in memcpy () from /lib64/tls/libc.so.6
#1  0x0031 in ?? ()
#2  0x00440fdd in php_oci_do_connect_ex (username=0x7cc238
, username_len=8, password=0x7cc268 ,
password_len=8, new_password=0x0, new_password_len=0,
dbname=0x7cc2b8 XXX.XXX.XXX.XX, dbname_len=30,
charset=0x7b42f8 AMERICAN_AMERICA.WE8ISO8859P15, session_mode=0,
persistent=0, exclusive=1)
at /root/src/php5.2-200606230630/ext/oci8/oci8.c:995
#3  0x0044235c in php_oci_do_connect (ht=value optimized out,
return_value=0x7b4338, return_value_ptr=value optimized out,
this_ptr=value optimized out,
return_value_used=value optimized out, persistent=0,
exclusive=1380273473) at
/root/src/php5.2-200606230630/ext/oci8/oci8.c:947
#4  0x0044aa23 in zif_oci_new_connect (ht=value optimized
out, return_value=value optimized out, return_value_ptr=value
optimized out, this_ptr=value optimized out,
return_value_used=value optimized out) at
/root/src/php5.2-200606230630/ext/oci8/oci8_interface.c:1520
#5  0x00519c73 in zend_do_fcall_common_helper_SPEC
(execute_data=dwarf2_read_address: Corrupted DWARF expression.
) at zend_vm_execute.h:200
#6  0x005683bc in execute (op_array=0x7cc128) at
zend_vm_execute.h:92
#7  0x004fac91 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/src/php5.2-200606230630/Zend/zend.c:1110
#8  0x004bfed5 in php_execute_script
(primary_file=0x7fb1c0) at
/root/src/php5.2-200606230630/main/main.c:1748
#9  0x005698d4 in main (argc=2, argv=0x7fb338) at
/root/src/php5.2-200606230630/sapi/cli/php_cli.c:1097


Previous Comments:


[2006-06-22 18:53:31] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-06-22 11:59:38] j dot henge-ernst at interexa dot de

Description:

php crashes if the fourth/charset parameter is given to oc_connect or
oci_new_connect. Problem seems to be line 990 in oci8.c
Problem occurs also if ZendDebugger is not activated. Error occurs also
in older versions 5.0.5

Reproduce code:
---
?php
  $c=oci_new_connect(, ,
XXX.XXX.XXX.XX, 'AMERICAN_AMERICA.WE8ISO8859P15');


Actual result:
--
#0  0x002a95ea4ef2 in __pause_nocancel () from
/lib64/tls/libpthread.so.0
#1  0x002a9a426c0c in zend_oe () from
/usr/local/Zend/Core/lib/zend/optimizer/php-5.1.x/ZendOptimizer.so
#2  signal handler called
#3  0x002a96121af5 in memcpy () from /lib64/tls/libc.so.6
#4  0x0031 in ?? ()
#5  0x002a985c5e83 in php_oci_do_connect_ex (username=0x986418
, username_len=8, password=0x986978 ,
password_len=8, new_password=0x0, new_password_len=0, dbname=0x986088
OPRISKT.XX, dbname_len=30, charset=0x9bacc8
AMERICAN_AMERICA.WE8ISO8859P15, session_mode=0, persistent=0,
exclusive=0) at /root/oci8/oci8.c:990
#6  0x002a985c71de in php_oci_do_connect (ht=value optimized out,
return_value=0x9b4078, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=value optimized
out, persistent=0, exclusive=1380273473) at /root/oci8/oci8.c:942
#7  0x002a985cfc33 in zif_oci_connect (ht=value optimized out,
return_value=value optimized out, return_value_ptr=value optimized
out, this_ptr=value optimized out, return_value_used=value
optimized out) at /root/oci8/oci8_interface.c:1528

line 990 in oci8.c is:
if (charset  *charset) {
smart_str_appends_ex(hashed_details, charset,
1);
}
which then  uses the macro from ./ext/standard/php_smart_str.h where
the memcopy is called






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

#37886 [Fbk-Opn]: oci_connect crashes php when charset-parameter is given

[j dot henge-ernst at interexa dot de]

 ID:   37886
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  5.1.4
 New Comment:

changing line 995 as given solves the problem and gives the correct
output

Warning: oci_new_connect(): ORA-12154: TNS:could not resolve the
connect identifier specified in /root/src/php5.2-200606230630/test.php
on line 3

The System is a SuSE Linux EenterpriseServer 9 64bit with Oracle 10g

The zendextensions have not been used when testing the latest snapshot


Previous Comments:


[2006-06-23 08:10:10] [EMAIL PROTECTED]

And don't forget to disable ALL zend_extension's.



[2006-06-23 08:09:39] [EMAIL PROTECTED]

Works just fine here.
What if you change line 995 to this:
smart_str_appends_ex(hashed_details, charset, 0);

?



[2006-06-23 07:49:49] j dot henge-ernst at interexa dot de

Still the same with the lastest snapshot

Starting program: /root/src/php5.2-200606230630/sapi/cli/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 182929799936 (LWP 13713)]
*** glibc detected *** realloc(): invalid pointer: 0x007b4378
***

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182929799936 (LWP 13713)]
0x002a97006af5 in memcpy () from /lib64/tls/libc.so.6
(gdb) where
#0  0x002a97006af5 in memcpy () from /lib64/tls/libc.so.6
#1  0x0031 in ?? ()
#2  0x00440fdd in php_oci_do_connect_ex (username=0x7cc238
, username_len=8, password=0x7cc268 ,
password_len=8, new_password=0x0, new_password_len=0,
dbname=0x7cc2b8 XXX.XXX.XXX.XX, dbname_len=30,
charset=0x7b42f8 AMERICAN_AMERICA.WE8ISO8859P15, session_mode=0,
persistent=0, exclusive=1)
at /root/src/php5.2-200606230630/ext/oci8/oci8.c:995
#3  0x0044235c in php_oci_do_connect (ht=value optimized out,
return_value=0x7b4338, return_value_ptr=value optimized out,
this_ptr=value optimized out,
return_value_used=value optimized out, persistent=0,
exclusive=1380273473) at
/root/src/php5.2-200606230630/ext/oci8/oci8.c:947
#4  0x0044aa23 in zif_oci_new_connect (ht=value optimized
out, return_value=value optimized out, return_value_ptr=value
optimized out, this_ptr=value optimized out,
return_value_used=value optimized out) at
/root/src/php5.2-200606230630/ext/oci8/oci8_interface.c:1520
#5  0x00519c73 in zend_do_fcall_common_helper_SPEC
(execute_data=dwarf2_read_address: Corrupted DWARF expression.
) at zend_vm_execute.h:200
#6  0x005683bc in execute (op_array=0x7cc128) at
zend_vm_execute.h:92
#7  0x004fac91 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/src/php5.2-200606230630/Zend/zend.c:1110
#8  0x004bfed5 in php_execute_script
(primary_file=0x7fb1c0) at
/root/src/php5.2-200606230630/main/main.c:1748
#9  0x005698d4 in main (argc=2, argv=0x7fb338) at
/root/src/php5.2-200606230630/sapi/cli/php_cli.c:1097



[2006-06-22 18:53:31] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-06-22 11:59:38] j dot henge-ernst at interexa dot de

Description:

php crashes if the fourth/charset parameter is given to oc_connect or
oci_new_connect. Problem seems to be line 990 in oci8.c
Problem occurs also if ZendDebugger is not activated. Error occurs also
in older versions 5.0.5

Reproduce code:
---
?php
  $c=oci_new_connect(, ,
XXX.XXX.XXX.XX, 'AMERICAN_AMERICA.WE8ISO8859P15');


Actual result:
--
#0  0x002a95ea4ef2 in __pause_nocancel () from
/lib64/tls/libpthread.so.0
#1  0x002a9a426c0c in zend_oe () from
/usr/local/Zend/Core/lib/zend/optimizer/php-5.1.x/ZendOptimizer.so
#2  signal handler called
#3  0x002a96121af5 in memcpy () from /lib64/tls/libc.so.6
#4  0x0031 in ?? ()
#5  0x002a985c5e83 in php_oci_do_connect_ex (username=0x986418
, username_len=8, password=0x986978 ,
password_len=8, new_password=0x0, new_password_len=0, dbname=0x986088
OPRISKT.XX, dbname_len=30, charset=0x9bacc8
AMERICAN_AMERICA.WE8ISO8859P15, session_mode=0, persistent=0,
exclusive=0) at /root/oci8/oci8.c:990
#6  0x002a985c71de in php_oci_do_connect (ht=value optimized out,
return_value=0x9b4078, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=value optimized
out, persistent

#37886 [NEW]: oci_connect crashes php when charset-parameter is given

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.1.4
PHP Bug Type: OCI8 related
Bug description:  oci_connect crashes php when charset-parameter is given

Description:

php crashes if the fourth/charset parameter is given to oc_connect or
oci_new_connect. Problem seems to be line 990 in oci8.c
Problem occurs also if ZendDebugger is not activated. Error occurs also in
older versions 5.0.5

Reproduce code:
---
?php
  $c=oci_new_connect(, ,
XXX.XXX.XXX.XX, 'AMERICAN_AMERICA.WE8ISO8859P15');


Actual result:
--
#0  0x002a95ea4ef2 in __pause_nocancel () from
/lib64/tls/libpthread.so.0
#1  0x002a9a426c0c in zend_oe () from
/usr/local/Zend/Core/lib/zend/optimizer/php-5.1.x/ZendOptimizer.so
#2  signal handler called
#3  0x002a96121af5 in memcpy () from /lib64/tls/libc.so.6
#4  0x0031 in ?? ()
#5  0x002a985c5e83 in php_oci_do_connect_ex (username=0x986418
, username_len=8, password=0x986978 , password_len=8,
new_password=0x0, new_password_len=0, dbname=0x986088
OPRISKT.XX, dbname_len=30, charset=0x9bacc8
AMERICAN_AMERICA.WE8ISO8859P15, session_mode=0, persistent=0,
exclusive=0) at /root/oci8/oci8.c:990
#6  0x002a985c71de in php_oci_do_connect (ht=value optimized out,
return_value=0x9b4078, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=value optimized out,
persistent=0, exclusive=1380273473) at /root/oci8/oci8.c:942
#7  0x002a985cfc33 in zif_oci_connect (ht=value optimized out,
return_value=value optimized out, return_value_ptr=value optimized
out, this_ptr=value optimized out, return_value_used=value optimized
out) at /root/oci8/oci8_interface.c:1528

line 990 in oci8.c is:
if (charset  *charset) {
smart_str_appends_ex(hashed_details, charset,
1);
}
which then  uses the macro from ./ext/standard/php_smart_str.h where the
memcopy is called


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

#29183 [Com]: Undefined symbol zend_check_private in file Zend/zend_object_handlers.lo

[j dot henge-ernst at interexa dot de]

 ID:   29183
 Comment by:   j dot henge-ernst at interexa dot de
 Reported By:  tomppa at iki dot fi
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Solaris 9/SPARC
 PHP Version:  5.0.0
 New Comment:

The same problem occurs on Solaris 10/AMD64. I guess it something to do
with the Sun C Compiler
cc: Sun C 5.7 Build23_1 2004/12/13

Tried with current CVS php5-STABLE-200501071330


Previous Comments:


[2004-12-29 13:07:13] tomppa at iki dot fi

Trying to compile latest php5-STABLE-200412290730 but it's still
failing same way

Undefined   first referenced
 symbol in file
zend_check_private  Zend/zend_object_handlers.lo
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php
*** Error code 1
make: Fatal error: Command failed for target `sapi/cli/php'



[2004-12-29 01:00:10] 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.



[2004-12-21 07:46:09] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip





[2004-07-15 14:07:46] tomppa at iki dot fi

If I remove inline from Zend/zend_object_handlers.c line 598 compiling
succeeded

inline  zend_function *zend_check_private(zend_function *fbc,
zend_class_entry *ce, int fn_flags, char function_name_strval, int
function_name_strlen TSRMLS_DC)



[2004-07-15 14:02:07] tomppa at iki dot fi

Description:

Can't link PHP 5.0.0 with latest Sun C compiler

Undefined   first referenced
 symbol in file
zend_check_privateZend/zend_object_handlers.lo
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php







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

#30196 [Opn]: SEGFAULT with apache2 on shutdown-child

[j dot henge-ernst at interexa dot de]

 ID:   30196
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
 Status:   Open
 Bug Type: OCI8 related
 Operating System: linux
-PHP Version:  5.0.1
+PHP Version:  5.0 cvs from 20041012
 New Comment:

At the moment I got  reproducable crash. After restarting the webserver
the problem vanished. Hope it helps to track down that nasy error.

Here is the backtrace:
#0  0x430dcc10 in kpufhndl0 () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#1  0x430dcbc8 in kpufhndl () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#2  0x4314cf9b in OCIHandleFree () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#3  0x42f0c396 in _oci_close_session (session=Variable session is not
available.
) at /home/hernst/src/php-src/ext/oci8/oci8.c:3015
#4  0x4061387e in list_entry_destructor (ptr=Variable ptr is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:173
#5  0x40611d58 in zend_hash_del_key_or_index (ht=0x40693f54, arKey=0x0,
nKeyLength=0, h=418, flag=1) at
/home/hernst/src/php-src/Zend/zend_hash.c:490
#6  0x40613a23 in _zend_list_delete (id=Variable id is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:58
#7  0x42f0c763 in _oci_conn_list_dtor (connection=Variable connection
is not available.
) at /home/hernst/src/php-src/ext/oci8/oci8.c:1021
#8  0x4061387e in list_entry_destructor (ptr=Variable ptr is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:173
#9  0x40611d58 in zend_hash_del_key_or_index (ht=0x40693f54, arKey=0x0,
nKeyLength=0, h=419, flag=1) at
/home/hernst/src/php-src/Zend/zend_hash.c:490
#10 0x40613a23 in _zend_list_delete (id=Variable id is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:58
#11 0x40609d10 in _zval_dtor (zvalue=Variable zvalue is not
available.
) at /home/hernst/src/php-src/Zend/zend_variables.c:69
#12 0x406313ed in zend_assign_to_variable (result=Variable result is
not available.
) at /home/hernst/src/php-src/Zend/zend_execute.c:640
#13 0x40635b55 in zend_assign_dim_handler (execute_data=0xbfff0410,
opline=0x84d21e8, op_array=0x84cf470) at
/home/hernst/src/php-src/Zend/zend_execute.c:2233
#14 0x4063d7fc in execute (op_array=0x84cf470) at
/home/hernst/src/php-src/Zend/zend_execute.c:1400
#15 0x4288bdb9 in db_ () from
/interexa/php/5.0.1/usr/share/extensions/no-debug-non-zts-20040412/ZendDebugger.so
#16 0x40633940 in zend_do_fcall_common_helper (execute_data=0xbfff1440,
opline=0x8343c5c, op_array=0x8346ed8) at
/home/hernst/src/php-src/Zend/zend_execute.c:2740
#17 0x40634279 in zend_do_fcall_by_name_handler (execute_data=0x0,
opline=0x8343c5c, op_array=0x8346ed8) at
/home/hernst/src/php-src/Zend/zend_execute.c:2825
#18 0x4063d7fc in execute (op_array=0x8346ed8) at
/home/hernst/src/php-src/Zend/zend_execute.c:1400
#19 0x4288bdb9 in db_ () from
/interexa/php/5.0.1/usr/share/extensions/no-debug-non-zts-20040412/ZendDebugger.so
#20 0x40633940 in zend_do_fcall_common_helper (execute_data=0xbfff27b0,
opline=0x834b06c, op_array=0x8348060) at
/home/hernst/src/php-src/Zend/zend_execute.c:2740
#21 0x4063406e in zend_do_fcall_handler (execute_data=Variable
execute_data is not available.
) at /home/hernst/src/php-src/Zend/zend_execute.c:2843
#22 0x4063d7fc in execute (op_array=0x8348060) at
/home/hernst/src/php-src/Zend/zend_execute.c:1400
#23 0x4288bdb9 in db_ () from
/interexa/php/5.0.1/usr/share/extensions/no-debug-non-zts-20040412/ZendDebugger.so
#24 0x40633940 in zend_do_fcall_common_helper (execute_data=0xbfffc560,
opline=0x43f5f88c, op_array=0x82d975c) at
/home/hernst/src/php-src/Zend/zend_execute.c:2740
#25 0x40634279 in zend_do_fcall_by_name_handler (execute_data=0x0,
opline=0x43f5f88c, op_array=0x82d975c) at
/home/hernst/src/php-src/Zend/zend_execute.c:2825
#26 0x4063d7fc in execute (op_array=0x82d975c) at
/home/hernst/src/php-src/Zend/zend_execute.c:1400
#27 0x4288bdb9 in db_ () from
/interexa/php/5.0.1/usr/share/extensions/no-debug-non-zts-20040412/ZendDebugger.so
#28 0x40609fd9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/hernst/src/php-src/Zend/zend.c:1060
#29 0x405d2891 in php_execute_script (primary_file=0xbfffe870) at
/home/hernst/src/php-src/main/main.c:1629
#30 0x4063df4a in php_handler (r=0x82ca370) at
/home/hernst/src/php-src/sapi/apache2handler/sapi_apache2.c:535
#31 0x08069258 in ap_run_handler ()
#32 0x003b in ?? ()
#33 0x in ?? ()
#34 0x0809a36c in __JCR_LIST__ ()
#35 0x082ca370 in ?? ()
#36 0x082ca370 in ?? ()
#37 0xbfffe9c8 in ?? ()
#38 0x0806c877 in ap_invoke_handler ()
Previous frame inner to this frame (corrupt stack?)


Previous Comments:


[2004-10-21 11:24:04] j dot henge-ernst at interexa dot de

The segfault still occures, but not so reproduceable. When I have more
time I will try to get a new backtrace and post that information

#30196 [Fbk-Opn]: SEGFAULT with apache2 on shutdown-child

[j dot henge-ernst at interexa dot de]

 ID:   30196
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: linux
-PHP Version:  5.0 cvs from 20041012
+PHP Version:  5.0 cvs from 20041027
 New Comment:

ok, updated, rebuild oci8.so and is still segfaulting. Here is the
backtracke. Looks similar to my last post.

#0  0x4311dc10 in kpufhndl0 () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#1  0x4311dbc8 in kpufhndl () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#2  0x4318df9b in OCIHandleFree () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#3  0x42f4d359 in _oci_close_session (session=Variable session is not
available.
) at /home/hernst/src/php-src/ext/oci8/oci8.c:2997
#4  0x4061387e in list_entry_destructor (ptr=Variable ptr is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:173
#5  0x406117b9 in zend_hash_apply_deleter (ht=Variable ht is not
available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:574
#6  0x40611927 in zend_hash_graceful_reverse_destroy (ht=Variable ht
is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:640
#7  0x4061371c in zend_destroy_rsrc_list (ht=0x40693f54) at
/home/hernst/src/php-src/Zend/zend_list.c:234
#8  0x4060249e in shutdown_executor () at
/home/hernst/src/php-src/Zend/zend_execute_API.c:285
#9  0x4060aa06 in zend_deactivate () at
/home/hernst/src/php-src/Zend/zend.c:818
#10 0x405d3399 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-src/main/main.c:1212
#11 0x4063debe in php_handler (r=0x828ea60) at
/home/hernst/src/php-src/sapi/apache2handler/sapi_apache2.c:435
#12 0x08069258 in ap_run_handler ()
#13 0x003b in ?? ()
#14 0x in ?? ()
#15 0x0809a36c in __JCR_LIST__ ()
#16 0x0828ea60 in ?? ()
#17 0x0828ea60 in ?? ()
#18 0xbfffe418 in ?? ()
#19 0x0806c877 in ap_invoke_handler ()
Previous frame inner to this frame (corrupt stack?)


Previous Comments:


[2004-10-27 11:09:31] [EMAIL PROTECTED]

Please, try _latest_ CVS snapshot. There were some changes after
2004-10-12.



[2004-10-27 11:03:18] j dot henge-ernst at interexa dot de

At the moment I got  reproducable crash. After restarting the webserver
the problem vanished. Hope it helps to track down that nasy error.

Here is the backtrace:
#0  0x430dcc10 in kpufhndl0 () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#1  0x430dcbc8 in kpufhndl () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#2  0x4314cf9b in OCIHandleFree () from
/opt/oracle/product/10.1.0/db_1/lib/libclntsh.so.10.1
#3  0x42f0c396 in _oci_close_session (session=Variable session is not
available.
) at /home/hernst/src/php-src/ext/oci8/oci8.c:3015
#4  0x4061387e in list_entry_destructor (ptr=Variable ptr is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:173
#5  0x40611d58 in zend_hash_del_key_or_index (ht=0x40693f54, arKey=0x0,
nKeyLength=0, h=418, flag=1) at
/home/hernst/src/php-src/Zend/zend_hash.c:490
#6  0x40613a23 in _zend_list_delete (id=Variable id is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:58
#7  0x42f0c763 in _oci_conn_list_dtor (connection=Variable connection
is not available.
) at /home/hernst/src/php-src/ext/oci8/oci8.c:1021
#8  0x4061387e in list_entry_destructor (ptr=Variable ptr is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:173
#9  0x40611d58 in zend_hash_del_key_or_index (ht=0x40693f54, arKey=0x0,
nKeyLength=0, h=419, flag=1) at
/home/hernst/src/php-src/Zend/zend_hash.c:490
#10 0x40613a23 in _zend_list_delete (id=Variable id is not
available.
) at /home/hernst/src/php-src/Zend/zend_list.c:58
#11 0x40609d10 in _zval_dtor (zvalue=Variable zvalue is not
available.
) at /home/hernst/src/php-src/Zend/zend_variables.c:69
#12 0x406313ed in zend_assign_to_variable (result=Variable result is
not available.
) at /home/hernst/src/php-src/Zend/zend_execute.c:640
#13 0x40635b55 in zend_assign_dim_handler (execute_data=0xbfff0410,
opline=0x84d21e8, op_array=0x84cf470) at
/home/hernst/src/php-src/Zend/zend_execute.c:2233
#14 0x4063d7fc in execute (op_array=0x84cf470) at
/home/hernst/src/php-src/Zend/zend_execute.c:1400
#15 0x4288bdb9 in db_ () from
/interexa/php/5.0.1/usr/share/extensions/no-debug-non-zts-20040412/ZendDebugger.so
#16 0x40633940 in zend_do_fcall_common_helper (execute_data=0xbfff1440,
opline=0x8343c5c, op_array=0x8346ed8) at
/home/hernst/src/php-src/Zend/zend_execute.c:2740
#17 0x40634279 in zend_do_fcall_by_name_handler (execute_data=0x0,
opline=0x8343c5c, op_array=0x8346ed8) at
/home/hernst/src/php-src/Zend/zend_execute.c:2825
#18 0x4063d7fc in execute (op_array=0x8346ed8) at
/home/hernst/src/php-src/Zend/zend_execute.c:1400
#19 0x4288bdb9 in db_ () from
/interexa/php/5.0.1/usr/share/extensions

#30196 [NoF-Opn]: SEGFAULT with apache2 on shutdown-child

[j dot henge-ernst at interexa dot de]

 ID:   30196
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
-Status:   No Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  5.0.1
 New Comment:

The segfault still occures, but not so reproduceable. When I have more
time I will try to get a new backtrace and post that information.


Previous Comments:


[2004-10-20 01:00:06] 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.



[2004-10-12 16:57:25] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip





[2004-09-22 19:27:40] j dot henge-ernst at interexa dot de

Tracked down the error a little bit more. Seems to happen only  when
using the oci8 module.

Using oracle 10g and oci8 as loadable module. Could also be the same as
http://bugs.php.net/bug.php?id=26393



[2004-09-22 18:27:32] j dot henge-ernst at interexa dot de

Description:

PHP 5.0.1 is segfaulting after every request has been processed with
our application. Disabling all register_shutdown_functions or
custom-error handlers didn't help. Simple pages as phpinfo just work
fine.

The commandline is not seg-faulting

Using SuSE 9.1 with apache2handler and PHP 5.0.1 self-compiled. Also
tried the current CVS, but that also fails on the same point

If you need additional information to track that down, ask

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076980544 (LWP 31715)]
0x4061043f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-5.0.1/Zend/zend_hash.c:664
664 if (apply_func(p-pData TSRMLS_CC)) {
(gdb) where
#0  0x4061043f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-5.0.1/Zend/zend_hash.c:664
#1  0x40601a80 in shutdown_executor () at
/home/hernst/src/php-5.0.1/Zend/zend_execute_API.c:248
#2  0x40609a96 in zend_deactivate () at
/home/hernst/src/php-5.0.1/Zend/zend.c:819
#3  0x405d2679 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-5.0.1/main/main.c:1212
#4  0x4063c82e in php_handler (r=0x826b1f0) at
/home/hernst/src/php-5.0.1/sapi/apache2handler/sapi_apache2.c:435
#5  0x08069288 in ap_run_handler ()
#6  0x003b in ?? ()
#7  0x in ?? ()
#8  0x0809a36c in __JCR_LIST__ ()
#9  0x0826b1f0 in ?? ()
#10 0x0826b1f0 in ?? ()
#11 0xbfffd518 in ?? ()
#12 0x0806c8a7 in ap_invoke_handler ()

Using the CVS-version of 5.0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076980544 (LWP 29322)]
0x4061176f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:664
664 if (apply_func(p-pData TSRMLS_CC)) {
(gdb) where
#0  0x4061176f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:664
#1  0x406024e0 in shutdown_executor () at
/home/hernst/src/php-src/Zend/zend_execute_API.c:251
#2  0x4060a8c6 in zend_deactivate () at
/home/hernst/src/php-src/Zend/zend.c:818
#3  0x405d3159 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-src/main/main.c:1212
#4  0x4063dd7e in php_handler (r=0x8265e10) at
/home/hernst/src/php-src/sapi/apache2handler/sapi_apache2.c:435
#5  0x08069288 in ap_run_handler ()
#6  0x003b in ?? ()
#7  0x in ?? ()
#8  0x0809a36c in __JCR_LIST__ ()
#9  0x08265e10 in ?? ()
#10 0x08265e10 in ?? ()
#11 0xbfffd508 in ?? ()
#12 0x0806c8a7 in ap_invoke_handler ()
Previous frame inner to this frame (corrupt stack?)






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

#30196 [NEW]: SEGFAULT with apache2 on shutdown-child

[j dot henge-ernst at interexa dot de]

From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version:  5.0.1
PHP Bug Type: Zend Engine 2 problem
Bug description:  SEGFAULT with apache2 on shutdown-child

Description:

PHP 5.0.1 is segfaulting after every request has been processed with our
application. Disabling all register_shutdown_functions or custom-error
handlers didn't help. Simple pages as phpinfo just work fine.

The commandline is not seg-faulting

Using SuSE 9.1 with apache2handler and PHP 5.0.1 self-compiled. Also tried
the current CVS, but that also fails on the same point

If you need additional information to track that down, ask

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076980544 (LWP 31715)]
0x4061043f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-5.0.1/Zend/zend_hash.c:664
664 if (apply_func(p-pData TSRMLS_CC)) {
(gdb) where
#0  0x4061043f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-5.0.1/Zend/zend_hash.c:664
#1  0x40601a80 in shutdown_executor () at
/home/hernst/src/php-5.0.1/Zend/zend_execute_API.c:248
#2  0x40609a96 in zend_deactivate () at
/home/hernst/src/php-5.0.1/Zend/zend.c:819
#3  0x405d2679 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-5.0.1/main/main.c:1212
#4  0x4063c82e in php_handler (r=0x826b1f0) at
/home/hernst/src/php-5.0.1/sapi/apache2handler/sapi_apache2.c:435
#5  0x08069288 in ap_run_handler ()
#6  0x003b in ?? ()
#7  0x in ?? ()
#8  0x0809a36c in __JCR_LIST__ ()
#9  0x0826b1f0 in ?? ()
#10 0x0826b1f0 in ?? ()
#11 0xbfffd518 in ?? ()
#12 0x0806c8a7 in ap_invoke_handler ()

Using the CVS-version of 5.0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076980544 (LWP 29322)]
0x4061176f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:664
664 if (apply_func(p-pData TSRMLS_CC)) {
(gdb) where
#0  0x4061176f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:664
#1  0x406024e0 in shutdown_executor () at
/home/hernst/src/php-src/Zend/zend_execute_API.c:251
#2  0x4060a8c6 in zend_deactivate () at
/home/hernst/src/php-src/Zend/zend.c:818
#3  0x405d3159 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-src/main/main.c:1212
#4  0x4063dd7e in php_handler (r=0x8265e10) at
/home/hernst/src/php-src/sapi/apache2handler/sapi_apache2.c:435
#5  0x08069288 in ap_run_handler ()
#6  0x003b in ?? ()
#7  0x in ?? ()
#8  0x0809a36c in __JCR_LIST__ ()
#9  0x08265e10 in ?? ()
#10 0x08265e10 in ?? ()
#11 0xbfffd508 in ?? ()
#12 0x0806c8a7 in ap_invoke_handler ()
Previous frame inner to this frame (corrupt stack?)


-- 
Edit bug report at http://bugs.php.net/?id=30196edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30196r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30196r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30196r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30196r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30196r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30196r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30196r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30196r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30196r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30196r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30196r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30196r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30196r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30196r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30196r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30196r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30196r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30196r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=30196r=mysqlcfg

#30196 [Opn]: SEGFAULT with apache2 on shutdown-child

[j dot henge-ernst at interexa dot de]

 ID:   30196
 User updated by:  j dot henge-ernst at interexa dot de
 Reported By:  j dot henge-ernst at interexa dot de
 Status:   Open
-Bug Type: Zend Engine 2 problem
+Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  5.0.1
 New Comment:

Tracked down the error a little bit more. Seems to happen only  when
using the oci8 module.

Using oracle 10g and oci8 as loadable module. Could also be the same as
http://bugs.php.net/bug.php?id=26393


Previous Comments:


[2004-09-22 18:27:32] j dot henge-ernst at interexa dot de

Description:

PHP 5.0.1 is segfaulting after every request has been processed with
our application. Disabling all register_shutdown_functions or
custom-error handlers didn't help. Simple pages as phpinfo just work
fine.

The commandline is not seg-faulting

Using SuSE 9.1 with apache2handler and PHP 5.0.1 self-compiled. Also
tried the current CVS, but that also fails on the same point

If you need additional information to track that down, ask

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076980544 (LWP 31715)]
0x4061043f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-5.0.1/Zend/zend_hash.c:664
664 if (apply_func(p-pData TSRMLS_CC)) {
(gdb) where
#0  0x4061043f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-5.0.1/Zend/zend_hash.c:664
#1  0x40601a80 in shutdown_executor () at
/home/hernst/src/php-5.0.1/Zend/zend_execute_API.c:248
#2  0x40609a96 in zend_deactivate () at
/home/hernst/src/php-5.0.1/Zend/zend.c:819
#3  0x405d2679 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-5.0.1/main/main.c:1212
#4  0x4063c82e in php_handler (r=0x826b1f0) at
/home/hernst/src/php-5.0.1/sapi/apache2handler/sapi_apache2.c:435
#5  0x08069288 in ap_run_handler ()
#6  0x003b in ?? ()
#7  0x in ?? ()
#8  0x0809a36c in __JCR_LIST__ ()
#9  0x0826b1f0 in ?? ()
#10 0x0826b1f0 in ?? ()
#11 0xbfffd518 in ?? ()
#12 0x0806c8a7 in ap_invoke_handler ()

Using the CVS-version of 5.0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076980544 (LWP 29322)]
0x4061176f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:664
664 if (apply_func(p-pData TSRMLS_CC)) {
(gdb) where
#0  0x4061176f in zend_hash_apply (ht=Variable ht is not available.
) at /home/hernst/src/php-src/Zend/zend_hash.c:664
#1  0x406024e0 in shutdown_executor () at
/home/hernst/src/php-src/Zend/zend_execute_API.c:251
#2  0x4060a8c6 in zend_deactivate () at
/home/hernst/src/php-src/Zend/zend.c:818
#3  0x405d3159 in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-src/main/main.c:1212
#4  0x4063dd7e in php_handler (r=0x8265e10) at
/home/hernst/src/php-src/sapi/apache2handler/sapi_apache2.c:435
#5  0x08069288 in ap_run_handler ()
#6  0x003b in ?? ()
#7  0x in ?? ()
#8  0x0809a36c in __JCR_LIST__ ()
#9  0x08265e10 in ?? ()
#10 0x08265e10 in ?? ()
#11 0xbfffd508 in ?? ()
#12 0x0806c8a7 in ap_invoke_handler ()
Previous frame inner to this frame (corrupt stack?)






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

#24003 [Com]: after several connections to Oracle 9i, program dies

[j dot henge-ernst at interexa dot de]

 ID:   24003
 Comment by:   j dot henge-ernst at interexa dot de
 Reported By:  dkruger at stevens-tech dot edu
 Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Redhat 8.0
 PHP Version:  4.3.2
 New Comment:

We encountered the same problem, but it seem to be a oracle9 (9ir2)
issue. After switching back to oracle 8 everything works as expected.

With PHP 4.2.3 and oracle 9 it works, but with 4.3.2 not. 
Today I tried a latest snap-shot ( php4-STABLE-200306131730 ) and it
seems to work again as expected.

No segfault or stange SQL-errors.


Previous Comments:


[2003-06-04 08:45:54] e_zagrai at yahoo dot com

The variables $ORACLE_HOME and others were set before apache started -
it didn't help...



[2003-06-04 08:43:07] e_zagrai at yahoo dot com

I tryed to backtrace the error and that's what I've got:


[EMAIL PROTECTED] bin]# gdb /usr/local/apache/bin/httpd
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for
details.
This GDB was configured as i386-redhat-linux...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 8192 (LWP 3518)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 3518)]
0x405fddfa in kpuhhaloc () from /oracle/lib/libclntsh.so.9.0
(gdb) bt
#0  0x405fddfa in kpuhhaloc () from /oracle/lib/libclntsh.so.9.0
#1  0x4060e15f in kpughndl0 () from /oracle/lib/libclntsh.so.9.0
#2  0x40614543 in kpughndl () from /oracle/lib/libclntsh.so.9.0
#3  0x40668dd6 in OCIHandleAlloc () from /oracle/lib/libclntsh.so.9.0
#4  0x402ebb93 in _oci_open_session (server=0x81d3d60,
username=0x81ed764 xxx, password=xxx, persistent=0,
exclusive=0, charset=0x403eb827 ) at
/arc/php-4.3.2/ext/oci8/oci8.c:2253
#5  0x402ed1e4 in oci_do_connect (ht=3, return_value=0x81ed84c,
this_ptr=0x0, return_value_used=1, persistent=0, exclusive=0)
at /arc/php-4.3.2/ext/oci8/oci8.c:2685
#6  0x402f19d4 in zif_ocilogon (ht=3, return_value=0x81ed84c,
this_ptr=0x0, return_value_used=1) at
/arc/php-4.3.2/ext/oci8/oci8.c:4307
#7  0x403dd592 in execute (op_array=0x81d20c4) at
/arc/php-4.3.2/Zend/zend_execute.c:1606
#8  0x403cc1bd in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /arc/php-4.3.2/Zend/zend.c:869
#9  0x40396464 in php_execute_script (primary_file=0xb600) at
/arc/php-4.3.2/main/main.c:1671
#10 0x403e32a5 in php_handler (r=0x81dc998) at
/arc/php-4.3.2/sapi/apache2handler/sapi_apache2.c:525
#11 0x080903e6 in ap_run_handler (r=0x81dc998) at config.c:195
#12 0x080908fe in ap_invoke_handler (r=0x81dc998) at config.c:401
#13 0x08080813 in ap_process_request (r=0x81dc998) at
http_request.c:288
#14 0x0807ca51 in ap_process_http_connection (c=0x81c8920) at
http_core.c:293
#15 0x080993d6 in ap_run_process_connection (c=0x81c8920) at
connection.c:85
#16 0x0808ef9c in child_main (child_num_arg=0) at prefork.c:696
#17 0x0808f146 in make_child (s=0x80f0c08, slot=0) at prefork.c:736
#18 0x0808f19f in startup_children (number_to_start=5) at
prefork.c:808
#19 0x0808f891 in ap_mpm_run (_pconf=0x808e878, plog=0x8125e70,
s=0x80f0c08) at prefork.c:1024
#20 0x080945aa in main (argc=2, argv=0xb8d4) at main.c:660
#21 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Hopefully it can help somehow...



[2003-06-04 08:26:44] [EMAIL PROTECTED]

As our documentation describes, you need to set the environment vars
BEFORE you start apache. Setting it in a script won't work:
putenv(ORACLE_SID=coastal);
putenv(ORACLE_HOME=/oracle);
putenv(TNS_ADMIN=/oracle/network/admin/tnsnames.ora);




[2003-06-04 08:24:44] e_zagrai at yahoo dot com

I've got exectly the same problem and I tryed to use the CVS snapshot
you proposed, but the result is the same as it was before: I execute my
programm with Oracle interaction for 2-3 times and then I get the error
Document contains no data every time I try to connect to Oracle in my
programm. If I execute any other php without Oracle interaction - it
works. 
Apache's error log contains the line:  
[Wed Jun 04 09:16:40 2003] [notice] child pid 3340 exit signal
Segmentation fault (11)

Thanks,

Elena



[2003-06-03 22:14:59] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip