#40472 [Opn->Bgs]: Semi random characters posted along with page content

2007-02-13 Thread mike
 ID:   40472
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fuitad at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: FreeBSD
 PHP Version:  5.2.1
 New Comment:

You're seeing HTTP/1,1 chunked transfer encoding. If your proxy cannot
understand HTTP/1.1 then it should send HTTP/1.0 requests.

I can't see anything unusual here.


Previous Comments:


[2007-02-14 02:59:31] fuitad at gmail dot com

Description:

Since we have upgraded our servers to PHP 5.2.1, some of our websites
(Across 5 servers, using either Apache or Lighttpd) shows semi random
characters at the top of each page and sometimes, also in other
locations in the page content.

Just to make this even harder to debug, it only happens for people who
are connecting to our servers thru a proxy.

For example, if you open www.fuitad.com via http://www.rexswain.com
(Rex Swain's HTTP Viewer), you will see:

43a2(CR)(LF)
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>(LF)

Now, obvioustly, this is not normal.

The same error happens if you look at the following websites via the
Rex Swain HTTP Viewer (or behind your favorite proxy):

www.zestuff.com
www.vgcats.com
www.nuklearpower.com
www.cad-comic.com

Again, this does not happen to everybody. We think it only occurs for
people behind a proxy.

I tried recompiling PHP numerous times 






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


#40473 [NEW]: Crash with SQL database

2007-02-13 Thread william91 at hgcbroadband dot com
From: william91 at hgcbroadband dot com
Operating system: Windows 98 SE
PHP version:  4.4.4
PHP Bug Type: MySQL related
Bug description:  Crash with SQL database

Description:

When I try to use a program OpenBiblio  on my
computer, an error message came out. However, If I access that page by
another computer, no errors is displayed.

Actual result:
--
APACHE caused an invalid page fault in
module  at :ee0527af.
Registers:
EAX= CS=0167 EIP=ee0527af EFLGS=00010246
EBX= SS=016f ESP=01b3ec3d EBP=cc0527af
ECX= DS=016f ESI=0003 FS=3cbf
EDX=c1625d20 ES=016f EDI=052edc08 GS=
Bytes at CS:EIP:

Stack dump:
67bff713 6801 28bff801 0801b3ec 8800 bc01b3ff c87800e9 ff780313
90ff 9101b3ec 09780114 0004 9802 0101b3ec 8c00 0301b3ec 

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


#40471 [Opn]: PHP 5.2.1 failed to be compiled with MySQl 5.0.33, MySQL 5.0.27, MySQL 5.1.15

2007-02-13 Thread pcdinh at gmail dot com
 ID:   40471
 User updated by:  pcdinh at gmail dot com
 Reported By:  pcdinh at gmail dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: CentOS 4.4
 PHP Version:  5.2.1
 New Comment:

Hi,

I just found out why PHP 5.2.1 final refused to build 

+ PHP 5.2.1 Rc4 does not require me to specify --with-pdo-mysql with
MySQL path
+ But PHP 5.2.1 final requires it

So I need to add --with-pdo-mysql=/usr/local/mysql


Previous Comments:


[2007-02-14 02:49:29] pcdinh at gmail dot com

Description:

I can not configure to build PHP 5.2.1 with MySQL 5 on CentOS 4.4. PHP
can not find mysql_config that really exists.

User account used to build: root

Reproduce code:
---
MySQL (5.0.27/5.0.33/5.1.15) builds: 

./configure --prefix=/usr/local/mysql \
--localstatedir=/usr/local/mysql/data \
--libexecdir=/usr/local/mysql/bin \
--libdir=/usr/local/mysql/lib \
--with-server-suffix=-max \
--enable-thread-safe-client \
--enable-local-infile \
--enable-shared \
--enable-assembler \
--with-vio \
--with-libwrap \
--with-zlib-dir=bundled \
--with-big-tables \
--with-readline \
--with-archive-storage-engine \
--with-innodb \
--with-blackhole-storage-engine \
--with-csv-storage-engine \
--with-federated-storage-engine \
--without-embedded-server \
--without-berkeley-db \
--with-ndbcluster \
--with-ndb-docs \
--with-partition \
--without-docs \
--without-bench \
--with-charset=utf8 \
--with-collation=utf8_general_ci \
--with-extra-charsets=all \
--with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock \
--with-client-ldflags=-all-static \
--with-mysqld-ldflags=-all-static \
--with-mysqld-user=mysql

Built successfully and MySQL running


PHP built:

./configure --prefix=/usr/local/php \
--disable-cgi \
--with-mysql=/usr/local/mysql \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--with-libxml-dir=/usr/local/lib \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-curl \
--with-curlwrappers \
--with-pdo-mysql \
--with-pdo-oci=instantclient,/usr/local/instantclient_10_2,10.2.0.3 \
--with-pdo-sqlite \
--with-oci8=instantclient,/usr/local/instantclient_10_2 \
--with-iconv \
--with-gd \
--with-png-dir=/usr/lib \
--with-jpeg-dir=/usr/lib \
--with-ttf \
--with-freetype-dir=/usr/include/freetype2 \
--with-dom=shared \
--with-dom-xslt=shared \
--with-dom-exslt=shared \
--with-xpm-dir \
--with-openssl \
--with-xml \
--with-zlib \
--with-bz2 \
--with-xmlrpc \
--with-mcrypt \
--with-tidy \
--with-mime-magic \
--without-pear \
--enable-dom \
--enable-png \
--enable-jpeg \
--enable-track-vars  \
--enable-memory-limit \
--enable-memcache \
--enable-calendar \
--enable-sysvsem \
--enable-sysvshm \
--enable-bcmath \
--enable-ctype \
--enable-exif \
--enable-ftp \
--enable-sockets \
--enable-shmop \
--enable-wddx \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-path-info \
--enable-inline-optimization \
--enable-debug=no \
--enable-mbregex \
--disable-magic-quotes \
--enable-zip \
--enable-spl \
--enable-libxml \
--enable-simplexml \
--enable-soap \
--enable-sigchild \
--disable-static 

Error:

checking for MySQL support for PDO... yes
checking for mysql_config... not found
configure: error: Cannot find MySQL header files under

Screenshot:

http://www.flickr.com/photos/pcdinh/389717146/

Config log:
http://download.yousendit.com/63F59D0C1AA53E21

Expected result:

Be configured successfully.

mysql_config really exists. I have configured MySQL build with
--libexecdir=/usr/local/mysql/bin and have set /usr/local/mysql/bin
into the PATH variable



Actual result:
--
Failed to build





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


#40472 [NEW]: Semi random characters posted along with page content

2007-02-13 Thread fuitad at gmail dot com
From: fuitad at gmail dot com
Operating system: FreeBSD
PHP version:  5.2.1
PHP Bug Type: Output Control
Bug description:  Semi random characters posted along with page content

Description:

Since we have upgraded our servers to PHP 5.2.1, some of our websites
(Across 5 servers, using either Apache or Lighttpd) shows semi random
characters at the top of each page and sometimes, also in other locations
in the page content.

Just to make this even harder to debug, it only happens for people who are
connecting to our servers thru a proxy.

For example, if you open www.fuitad.com via http://www.rexswain.com (Rex
Swain's HTTP Viewer), you will see:

43a2(CR)(LF)
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>(LF)

Now, obvioustly, this is not normal.

The same error happens if you look at the following websites via the Rex
Swain HTTP Viewer (or behind your favorite proxy):

www.zestuff.com
www.vgcats.com
www.nuklearpower.com
www.cad-comic.com

Again, this does not happen to everybody. We think it only occurs for
people behind a proxy.

I tried recompiling PHP numerous times 


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


#40471 [NEW]: PHP 5.2.1 failed to be compiled with MySQl 5.0.33, MySQL 5.0.27, MySQL 5.1.15

2007-02-13 Thread pcdinh at gmail dot com
From: pcdinh at gmail dot com
Operating system: CentOS 4.4
PHP version:  5.2.1
PHP Bug Type: Compile Failure
Bug description:  PHP 5.2.1 failed to be compiled with MySQl 5.0.33, MySQL 
5.0.27, MySQL 5.1.15

Description:

I can not configure to build PHP 5.2.1 with MySQL 5 on CentOS 4.4. PHP can
not find mysql_config that really exists.

User account used to build: root

Reproduce code:
---
MySQL (5.0.27/5.0.33/5.1.15) builds: 

./configure --prefix=/usr/local/mysql \
--localstatedir=/usr/local/mysql/data \
--libexecdir=/usr/local/mysql/bin \
--libdir=/usr/local/mysql/lib \
--with-server-suffix=-max \
--enable-thread-safe-client \
--enable-local-infile \
--enable-shared \
--enable-assembler \
--with-vio \
--with-libwrap \
--with-zlib-dir=bundled \
--with-big-tables \
--with-readline \
--with-archive-storage-engine \
--with-innodb \
--with-blackhole-storage-engine \
--with-csv-storage-engine \
--with-federated-storage-engine \
--without-embedded-server \
--without-berkeley-db \
--with-ndbcluster \
--with-ndb-docs \
--with-partition \
--without-docs \
--without-bench \
--with-charset=utf8 \
--with-collation=utf8_general_ci \
--with-extra-charsets=all \
--with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock \
--with-client-ldflags=-all-static \
--with-mysqld-ldflags=-all-static \
--with-mysqld-user=mysql

Built successfully and MySQL running


PHP built:

./configure --prefix=/usr/local/php \
--disable-cgi \
--with-mysql=/usr/local/mysql \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--with-libxml-dir=/usr/local/lib \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-curl \
--with-curlwrappers \
--with-pdo-mysql \
--with-pdo-oci=instantclient,/usr/local/instantclient_10_2,10.2.0.3 \
--with-pdo-sqlite \
--with-oci8=instantclient,/usr/local/instantclient_10_2 \
--with-iconv \
--with-gd \
--with-png-dir=/usr/lib \
--with-jpeg-dir=/usr/lib \
--with-ttf \
--with-freetype-dir=/usr/include/freetype2 \
--with-dom=shared \
--with-dom-xslt=shared \
--with-dom-exslt=shared \
--with-xpm-dir \
--with-openssl \
--with-xml \
--with-zlib \
--with-bz2 \
--with-xmlrpc \
--with-mcrypt \
--with-tidy \
--with-mime-magic \
--without-pear \
--enable-dom \
--enable-png \
--enable-jpeg \
--enable-track-vars  \
--enable-memory-limit \
--enable-memcache \
--enable-calendar \
--enable-sysvsem \
--enable-sysvshm \
--enable-bcmath \
--enable-ctype \
--enable-exif \
--enable-ftp \
--enable-sockets \
--enable-shmop \
--enable-wddx \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-path-info \
--enable-inline-optimization \
--enable-debug=no \
--enable-mbregex \
--disable-magic-quotes \
--enable-zip \
--enable-spl \
--enable-libxml \
--enable-simplexml \
--enable-soap \
--enable-sigchild \
--disable-static 

Error:

checking for MySQL support for PDO... yes
checking for mysql_config... not found
configure: error: Cannot find MySQL header files under

Screenshot:

http://www.flickr.com/photos/pcdinh/389717146/

Config log:
http://download.yousendit.com/63F59D0C1AA53E21

Expected result:

Be configured successfully.

mysql_config really exists. I have configured MySQL build with
--libexecdir=/usr/local/mysql/bin and have set /usr/local/mysql/bin into
the PATH variable



Actual result:
--
Failed to build

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


#40470 [NEW]: Invalid session id should specify actual ID

2007-02-13 Thread ceo at l-i-e dot com
From: ceo at l-i-e dot com
Operating system: all
PHP version:  5.2.1
PHP Bug Type: Feature/Change Request
Bug description:  Invalid session id should specify actual ID

Description:

A message such as this:
[04-Dec-2006 18:21:56] PHP Warning:  Unknown: The session id contains
illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in
Unknown
on line 0
should be improved to specify the actual invalid ID.

A busy site with many sessions will need that info to trace down the bug
quickly.


Expected result:

Something like this:

[04-Dec-2006 18:21:56] PHP Warning:  Unknown: The session id '$#!^'
contains
illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in
Unknown
on line 0



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


#40467 [Opn->Asn]: Partial SOAP request sent when XSD sequence or choice include minOccurs=0

2007-02-13 Thread tony2001
 ID:   40467
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pgiralt at mac dot com
-Status:   Open
+Status:   Assigned
 Bug Type: SOAP related
 Operating System: Ubuntu Linux 6.10
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2007-02-13 21:41:40] pgiralt at mac dot com

Description:

When a XSD includes  or , if the choice or sequence is ommitted from a SOAP
request, any elements appearing in the complexType after the choice or
sequence are not sent. 


Reproduce code:
---
Associated XML schema available here: 

http://www.employees.org/~pgiralt/phpbug/phpbugxml.txt

$mySoapClient = new SoapClient($wsdlLocation, $clientParams);

$newDnData->pattern = '15704';
$newDnData->routePartitionName = '1stLine';
$newDnData->usage = 'Device';
$newDnData->callForwardAll->forwardToVoiceMail = false;
$newDnData->callForwardAll->pattern = '';
$newDnData->callForwardAll->callingSearchSpaceName = 'Local';
$newDnData->callForwardBusy->forwardToVoiceMail = true;
$newDnData->callForwardBusyInt->forwardToVoiceMail = true;
$newDnData->callForwardNoAnswer->forwardToVoiceMail = true;
$newDnData->callForwardNoAnswerInt->forwardToVoiceMail = true;
$newDnData->description = 'Test User3;
$newDnData->alertingName = 'Test User3;
$newDnData->asciiAlertingName = 'Test User3;

$result = $ccmSoapProxyClass->AddLine($newDnData);


Expected result:

Tue Feb 13 10:38:19.972 EST 2007: 
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.cisco.com/AXL/API/1.0";>



15604
Test User3
Device
1stLine
Test


false

Local



true



true



true



true

Test User3
Test 
User3





Actual result:
--
Tue Feb 13 10:56:43.476 EST 2007: 
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.cisco.com/AXL/API/1.0";>



15604
Test User4
Device
1stLine









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


#40465 [Bgs->Opn]: var_dump() printing details of private and protected object properties

2007-02-13 Thread derick
 ID:   40465
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wharmby at uk dot ibm dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Variables related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-02-13 (CVS)
 New Comment:

Ilia, learn to read ;-)


Previous Comments:


[2007-02-13 19:53:14] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.



[2007-02-13 19:08:18] wharmby at uk dot ibm dot com

btw.. Given that the code behaves in the intended manner removing the
spurious code in the HEAD (PHP 6) stream only would probably suffice
here.



[2007-02-13 19:05:41] wharmby at uk dot ibm dot com

Thanks Derick. I had assumed as much from comments in previous defects
on var_dump(). var_dump() is a debug aid 
rather than something a PHP application should be using 
and if it did NOT print out details regarding private and protected
fields that would be a pain. 

Which means that the 2nd patch attached is the one which is needed here
to remove the spurious and bogus code.



[2007-02-13 18:44:09] [EMAIL PROTECTED]

Just FYI: var_dump should show the private and protected properties.



[2007-02-13 16:21:53] wharmby at uk dot ibm dot com

Description:

I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise
but the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
/* XXX: perhaps when we are inside the class we
 * should permit access to private & protected 
 * values
 */
return 0;
}
php_printf("%*c[\"", level + 1, ' ');
PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds
the patch to correct the var_dump_code 
is as follows:

http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields
should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be
cleaned up as in the following patch: 

http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---



Expected result:

object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}






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


#40467 [NEW]: Partial SOAP request sent when XSD sequence or choice include minOccurs=0

2007-02-13 Thread pgiralt at mac dot com
From: pgiralt at mac dot com
Operating system: Ubuntu Linux 6.10
PHP version:  5.2.1
PHP Bug Type: SOAP related
Bug description:  Partial SOAP request sent when XSD sequence or choice include 
minOccurs=0

Description:

When a XSD includes  or , if the choice or sequence is ommitted from a SOAP request,
any elements appearing in the complexType after the choice or sequence are
not sent. 


Reproduce code:
---
Associated XML schema available here: 

http://www.employees.org/~pgiralt/phpbug/phpbugxml.txt

$mySoapClient = new SoapClient($wsdlLocation, $clientParams);

$newDnData->pattern = '15704';
$newDnData->routePartitionName = '1stLine';
$newDnData->usage = 'Device';
$newDnData->callForwardAll->forwardToVoiceMail = false;
$newDnData->callForwardAll->pattern = '';
$newDnData->callForwardAll->callingSearchSpaceName = 'Local';
$newDnData->callForwardBusy->forwardToVoiceMail = true;
$newDnData->callForwardBusyInt->forwardToVoiceMail = true;
$newDnData->callForwardNoAnswer->forwardToVoiceMail = true;
$newDnData->callForwardNoAnswerInt->forwardToVoiceMail = true;
$newDnData->description = 'Test User3;
$newDnData->alertingName = 'Test User3;
$newDnData->asciiAlertingName = 'Test User3;

$result = $ccmSoapProxyClass->AddLine($newDnData);


Expected result:

Tue Feb 13 10:38:19.972 EST 2007: 
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.cisco.com/AXL/API/1.0";>



15604
Test User3
Device
1stLine
Test


false

Local



true



true



true



true

Test User3
Test 
User3





Actual result:
--
Tue Feb 13 10:56:43.476 EST 2007: 
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.cisco.com/AXL/API/1.0";>



15604
Test User4
Device
1stLine





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


#30301 [Com]: connection_status and connection_aborted not working.

2007-02-13 Thread akravtsov at rogers dot com
 ID:   30301
 Comment by:   akravtsov at rogers dot com
 Reported By:  phpbug at zone-mr dot ath dot cx
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows 2003 Server
 PHP Version:  5.0.2
 New Comment:

I am having the same problem! I have tried everything. This has not
been fixed since Oct 2004??

This is my code:





Previous Comments:


[2006-02-08 14:30:09] phpbug at paragontech dot com

Try to do a ob_end_flush(); at the top of your script.



[2005-10-18 22:16:29] ecarpenter at itex dot co dot za

I am having the same problem on SuSE Linux 9.3 running Linux
2.6.11.4-21.9-default, Apache 2.0.53 and PHP 4.3.10 (cli) (built: Aug
31 2005 16:14:46)

The script below can be used to recreate the problem. After I have
press the Stop button (Firefox 1.0.7) the script continues to execute
until it is killed 15 minutes later without the shutdown function being
executed.

> /tmp/test");
}
register_shutdown_function('foo');

exec("echo '".date("Y/m/d H:i:s")." Starting' > /tmp/test");
$count=0;
while (true) {
$count++;
exec("echo '".date("Y/m/d H:i:s")." Running ".$count."
Status:".connection_status()."' >> /tmp/test");
}
?>



[2005-10-11 10:51:26] klimov at mmk dot ru

I have tried PHP 4.4.0 and 5.0.5 and latest cvs. My server is running
on Windows 2003 with IIS 6. The functions connection_aborted and
connection_status doesn't work properly too.



[2005-03-15 01:00:14] 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".



[2005-03-07 22:06:04] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





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/30301

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


#34794 [Asn->Csd]: proc_close() hangs when used with two processes

2007-02-13 Thread nlopess
 ID:   34794
 Updated by:   [EMAIL PROTECTED]
 Reported By:  e-t172 at e-t172 dot net
-Status:   Assigned
+Status:   Closed
 Bug Type: Program Execution
 Operating System: Linux
 PHP Version:  5CVS-2005-10-09 (snap)
 Assigned To:  wez
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2006-05-28 19:20:44] jdolecek at NetBSD dot org

Actually yes, there is a severe pipe setup problem.

The problem is that the second spawned process inherits the descriptor
of parent end of pipe to the first spawned process, created when
setting up the process1 pipes. Since PHP doesn't set the close-on-exec
flag, the descriptor stays open in process2.

So, when the parent-end of pipes1[0] is closed in master script, the
descriptor is still open by process2, thus the pipe write end is not
closed yet and thus cat in process1 doesn't end.

Note this is also potential security problem, since the second process
is able to send data to the first.

Fix:

--- ext/standard/proc_open.c.orig   2006-05-28 19:10:35.0
+0200
+++ ext/standard/proc_open.c
@@ -929,6 +929,16 @@ PHP_FUNCTION(proc_open)
descriptors[i].mode_flags), mode_string,
NULL);
 #else
stream =
php_stream_fopen_from_fd(descriptors[i].parentend, mode_string, NULL);
+
+#if defined(F_SETFD) && defined(FD_CLOEXEC)
+   /*
+* Mark the descriptor close-on-exec, so that it
+* it won't be inherited by potential other children.
+* This avoids first child deadlock on proc_close().
+*/
+   fcntl(descriptors[i].parentend, F_SETFD, FD_CLOEXEC);
+#endif
+
 #endif
if (stream) {
zval *retfp;



[2006-05-28 17:32:37] jdolecek at NetBSD dot org

This is actually not a bug, or just documentation bug.

proc_close() blocks if the child has not terminated yet. 

You must use proc_terminate() instead of proc_close() if you can't
guarantee the child has already exited, or use proc_get_status() to
check if the child has already exited if you want to avoid blocking.



[2006-04-29 02:42:16] Dallas at ekkySoftware dot com

I have a similar problem, it seems at I can't concurrently call the
same page with proc_open until the first proc_open returns. It looks
like proc_open is running through a critical section even though it is
opening separate processes.

>From experience it is like php is using the same pipes for each
proc_open and can't continue to the next proc_open until the original
as ended. I would normally use temporary files instead of pipes – but
this makes life difficult.

Dallas

http://www.ekkySoftware.com/



[2006-04-26 14:50:23] radu dot rendec at ines dot ro

Same problem with 5.1.3RC4-dev (latest CVS snapshot at the moment) on
Linux/i386.

I independently reproduced the bug with the following piece of code:

error_reporting(E_ALL);
$spec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("pipe", "w")
);
$p1 = proc_open("/bin/cat", $spec, $fd1);
$p2 = proc_open("/bin/cat", $spec, $fd2);

fclose($fd1[0]);
fclose($fd1[1]);
fclose($fd1[2]);
echo "closing p1... "; flush();
proc_close($p1);
echo "success\n"; flush();

This code hangs in proc_close(). This doesn't happen if the second
proc_open() is commented.

Although the parent process seems to correctly close all pipes, the
child process still remains blocked in read(0,...).



[2005-11-01 11:54:27] [EMAIL PROTECTED]

Assigned to the author of this stuff.



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/34794

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


#40465 [Opn->Bgs]: var_dump() printing details of private and protected object properties

2007-02-13 Thread iliaa
 ID:   40465
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wharmby at uk dot ibm dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Variables related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-02-13 (CVS)
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.


Previous Comments:


[2007-02-13 19:08:18] wharmby at uk dot ibm dot com

btw.. Given that the code behaves in the intended manner removing the
spurious code in the HEAD (PHP 6) stream only would probably suffice
here.



[2007-02-13 19:05:41] wharmby at uk dot ibm dot com

Thanks Derick. I had assumed as much from comments in previous defects
on var_dump(). var_dump() is a debug aid 
rather than something a PHP application should be using 
and if it did NOT print out details regarding private and protected
fields that would be a pain. 

Which means that the 2nd patch attached is the one which is needed here
to remove the spurious and bogus code.



[2007-02-13 18:44:09] [EMAIL PROTECTED]

Just FYI: var_dump should show the private and protected properties.



[2007-02-13 16:21:53] wharmby at uk dot ibm dot com

Description:

I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise
but the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
/* XXX: perhaps when we are inside the class we
 * should permit access to private & protected 
 * values
 */
return 0;
}
php_printf("%*c[\"", level + 1, ' ');
PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds
the patch to correct the var_dump_code 
is as follows:

http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields
should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be
cleaned up as in the following patch: 

http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---



Expected result:

object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}






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


#40465 [Opn]: var_dump() printing details of private and protected object properties

2007-02-13 Thread wharmby at uk dot ibm dot com
 ID:   40465
 User updated by:  wharmby at uk dot ibm dot com
 Reported By:  wharmby at uk dot ibm dot com
 Status:   Open
 Bug Type: Variables related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-02-13 (CVS)
 New Comment:

btw.. Given that the code behaves in the intended manner removing the
spurious code in the HEAD (PHP 6) stream only would probably suffice
here.


Previous Comments:


[2007-02-13 19:05:41] wharmby at uk dot ibm dot com

Thanks Derick. I had assumed as much from comments in previous defects
on var_dump(). var_dump() is a debug aid 
rather than something a PHP application should be using 
and if it did NOT print out details regarding private and protected
fields that would be a pain. 

Which means that the 2nd patch attached is the one which is needed here
to remove the spurious and bogus code.



[2007-02-13 18:44:09] [EMAIL PROTECTED]

Just FYI: var_dump should show the private and protected properties.



[2007-02-13 16:21:53] wharmby at uk dot ibm dot com

Description:

I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise
but the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
/* XXX: perhaps when we are inside the class we
 * should permit access to private & protected 
 * values
 */
return 0;
}
php_printf("%*c[\"", level + 1, ' ');
PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds
the patch to correct the var_dump_code 
is as follows:

http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields
should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be
cleaned up as in the following patch: 

http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---



Expected result:

object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}






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


#40465 [Opn]: var_dump() printing details of private and protected object properties

2007-02-13 Thread wharmby at uk dot ibm dot com
 ID:   40465
 User updated by:  wharmby at uk dot ibm dot com
 Reported By:  wharmby at uk dot ibm dot com
 Status:   Open
 Bug Type: Variables related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-02-13 (CVS)
 New Comment:

Thanks Derick. I had assumed as much from comments in previous defects
on var_dump(). var_dump() is a debug aid 
rather than something a PHP application should be using 
and if it did NOT print out details regarding private and protected
fields that would be a pain. 

Which means that the 2nd patch attached is the one which is needed here
to remove the spurious and bogus code.


Previous Comments:


[2007-02-13 18:44:09] [EMAIL PROTECTED]

Just FYI: var_dump should show the private and protected properties.



[2007-02-13 16:21:53] wharmby at uk dot ibm dot com

Description:

I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise
but the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
/* XXX: perhaps when we are inside the class we
 * should permit access to private & protected 
 * values
 */
return 0;
}
php_printf("%*c[\"", level + 1, ' ');
PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds
the patch to correct the var_dump_code 
is as follows:

http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields
should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be
cleaned up as in the following patch: 

http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---



Expected result:

object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}






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


#40465 [Opn]: var_dump() printing details of private and protected object properties

2007-02-13 Thread derick
 ID:   40465
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wharmby at uk dot ibm dot com
 Status:   Open
 Bug Type: Variables related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-02-13 (CVS)
 New Comment:

Just FYI: var_dump should show the private and protected properties.


Previous Comments:


[2007-02-13 16:21:53] wharmby at uk dot ibm dot com

Description:

I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise
but the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
/* XXX: perhaps when we are inside the class we
 * should permit access to private & protected 
 * values
 */
return 0;
}
php_printf("%*c[\"", level + 1, ' ');
PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds
the patch to correct the var_dump_code 
is as follows:

http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields
should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be
cleaned up as in the following patch: 

http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---



Expected result:

object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}






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


#37799 [Opn->Csd]: ftp_ssl_connect falls back to ftp_connect silently

2007-02-13 Thread nlopess
 ID:   37799
 Updated by:   [EMAIL PROTECTED]
 Reported By:  antispam at brokenhill dot net
-Status:   Open
+Status:   Closed
-Bug Type: Documentation problem
+Bug Type: FTP related
 Operating System: Mac OS X
-PHP Version:  Irrelevant
+PHP Version:  5,HEAD
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.

I'll also add a note to the manual in a minute.


Previous Comments:


[2006-06-14 03:00:34] antispam at brokenhill dot net

Description:

One thing that seems clear from my experience, but which is not
documented, is that ftp_ssl_connect silently falls back to ftp_connect
if ftps is not available. 

Test case: make a ftps connection to a server which does not support
ftps. You will still get a connection and be able to use all ftp_
functions. The connection will simply fall back to ftp_connect. 

This should be documented as it could lead to a false sense of
security.

Reproduce code:
---
public function connect($host, $user, $pass, $type=self::FTP) {
$this->_host = $host;
$this->_user = $user;
$this->_pw = $pass;
$this->_type = $type;   
if ($this->_type==self::FTPS) $this->_conn =
ftp_ssl_connect($this->_host);
else $this->_conn = ftp_connect($this->_host);
$loginResult = ftp_login($this->_conn, $this->_user, 
$this->_pw);
if (!$this->_conn) {
cx_log("Could not connect to FTP server", __FUNCTION__, 
__FILE__,
CX_ERR_CRITICAL);
return FALSE;
} else if (!$loginResult) {
cx_log("Could not login to FTP server", __FUNCTION__, 
__FILE__,
CX_ERR_CRITICAL);
return FALSE;
} else {
return TRUE;
}
}


Expected result:

I would expect to have a ftps connection made, or an error stating that
ftps is not available. 



Actual result:
--
Instead it silently gives me an ftp_connect (non SSL) connection, which
leads to a false sense of security.

Found this out by running tcpdump and seeing that nothing was
encrypted.





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


#40466 [Fbk]: zend_mm_heap corruption

2007-02-13 Thread tony2001
 ID:   40466
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stojmir at on dot net dot mk
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux 2.6.9
 PHP Version:  5.2.1
 New Comment:

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

.. And try the snapshot.


Previous Comments:


[2007-02-13 18:18:48] [EMAIL PROTECTED]

You can start with disabling eaccelerator and any other 
zend extensions you may have loaded.



[2007-02-13 18:07:17] stojmir at on dot net dot mk

I really have no idea on how to narrow down the code that could
reproduce the crash. It could be anything from the thousands of lines
of code in Drupal.

Any hints? What else can i do in order to help you guys identify and
resolve this?



[2007-02-13 17:33:37] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 16:49:39] stojmir at on dot net dot mk

Description:

My apache crashes on random intervals (usually 10 hours):
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Tue Feb 13 17:28:01 2007] [notice] child pid 14881 exit signal
Segmentation fault (11), possible coredump in /var/apache-dump

Im guessing its related with the zend memory menager, but who nows, im
not really into it so i cant be sure.

PHP version 5.2.1, Apache 2.0.55, RedHat Enterprise Linux with
2.6.9-42.0.8.ELsmp on a x86_64 machine with dual core Xeon.

The site is hosting a Drupal installation with about 3000 users at a
time.



Reproduce code:
---
Im not sure what code produces the crash.

Actual result:
--
PHP is configured with:

'./configure' '--build=x86_64-redhat-linux'
'--host=x86_64-redhat-linux' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/usr/com'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--cache-file=../config.cache' '--with-libdir=lib64'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--with-imap-ssl' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr'
'--with-gmp' '--with-mysql=shared,/usr/lib64' '--with-xml'
'--enable-trans-sid' '--enable-shmop' '--enable-sockets'
'--with-regex=php' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-memory-limit' '--with-tsrm-pthreads'
'--enable-shared' '--disable-debug' '--with-zlib' '--with-gettext'
'--with-xsl' '--with-iconv' '--enable-inline-optimization'
'--disable-static' '--with-curl' '--enable-exif'
'--enable-magic-quotes' '--with-inifile' '--with-flatfile'
'--enable-dio' '--with-mbstring'
'--with-mime-magic=/etc/httpd/mime.magic' '--enable-soap'
'--enable-wddx' '--with-pear' '--enable-pic' '--disable-rpath'
'--enable-track-vars' '--enable-mcal' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--enable-memory-limit'
'--enable-zend-multibyte' '--with-mysqli=shared'
'--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pcntl'
'--enable-sigchild' '--with-apxs2=/usr/sbin/apxs' '--with-bz2'
'--with-sqllite=shared' '--enable-sqlite-utf8'



Here is a gdb backtrace of the thrown core dump from apache:

GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 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 "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/sbin/httpd
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.s

#40466 [Opn->Fbk]: zend_mm_heap corruption

2007-02-13 Thread bjori
 ID:   40466
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stojmir at on dot net dot mk
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux 2.6.9
 PHP Version:  5.2.1
 New Comment:

You can start with disabling eaccelerator and any other 
zend extensions you may have loaded.


Previous Comments:


[2007-02-13 18:07:17] stojmir at on dot net dot mk

I really have no idea on how to narrow down the code that could
reproduce the crash. It could be anything from the thousands of lines
of code in Drupal.

Any hints? What else can i do in order to help you guys identify and
resolve this?



[2007-02-13 17:33:37] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 16:49:39] stojmir at on dot net dot mk

Description:

My apache crashes on random intervals (usually 10 hours):
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Tue Feb 13 17:28:01 2007] [notice] child pid 14881 exit signal
Segmentation fault (11), possible coredump in /var/apache-dump

Im guessing its related with the zend memory menager, but who nows, im
not really into it so i cant be sure.

PHP version 5.2.1, Apache 2.0.55, RedHat Enterprise Linux with
2.6.9-42.0.8.ELsmp on a x86_64 machine with dual core Xeon.

The site is hosting a Drupal installation with about 3000 users at a
time.



Reproduce code:
---
Im not sure what code produces the crash.

Actual result:
--
PHP is configured with:

'./configure' '--build=x86_64-redhat-linux'
'--host=x86_64-redhat-linux' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/usr/com'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--cache-file=../config.cache' '--with-libdir=lib64'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--with-imap-ssl' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr'
'--with-gmp' '--with-mysql=shared,/usr/lib64' '--with-xml'
'--enable-trans-sid' '--enable-shmop' '--enable-sockets'
'--with-regex=php' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-memory-limit' '--with-tsrm-pthreads'
'--enable-shared' '--disable-debug' '--with-zlib' '--with-gettext'
'--with-xsl' '--with-iconv' '--enable-inline-optimization'
'--disable-static' '--with-curl' '--enable-exif'
'--enable-magic-quotes' '--with-inifile' '--with-flatfile'
'--enable-dio' '--with-mbstring'
'--with-mime-magic=/etc/httpd/mime.magic' '--enable-soap'
'--enable-wddx' '--with-pear' '--enable-pic' '--disable-rpath'
'--enable-track-vars' '--enable-mcal' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--enable-memory-limit'
'--enable-zend-multibyte' '--with-mysqli=shared'
'--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pcntl'
'--enable-sigchild' '--with-apxs2=/usr/sbin/apxs' '--with-bz2'
'--with-sqllite=shared' '--enable-sqlite-utf8'



Here is a gdb backtrace of the thrown core dump from apache:

GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 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 "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/sbin/httpd
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /usr/lib64/libpcreposix.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/libpcreposix.so.0
Reading symbols from /usr/lib64/libaprutil-0.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/libapruti

#40466 [Fbk->Opn]: zend_mm_heap corruption

2007-02-13 Thread stojmir at on dot net dot mk
 ID:   40466
 User updated by:  stojmir at on dot net dot mk
 Reported By:  stojmir at on dot net dot mk
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux 2.6.9
 PHP Version:  5.2.1
 New Comment:

I really have no idea on how to narrow down the code that could
reproduce the crash. It could be anything from the thousands of lines
of code in Drupal.

Any hints? What else can i do in order to help you guys identify and
resolve this?


Previous Comments:


[2007-02-13 17:33:37] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 16:49:39] stojmir at on dot net dot mk

Description:

My apache crashes on random intervals (usually 10 hours):
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Tue Feb 13 17:28:01 2007] [notice] child pid 14881 exit signal
Segmentation fault (11), possible coredump in /var/apache-dump

Im guessing its related with the zend memory menager, but who nows, im
not really into it so i cant be sure.

PHP version 5.2.1, Apache 2.0.55, RedHat Enterprise Linux with
2.6.9-42.0.8.ELsmp on a x86_64 machine with dual core Xeon.

The site is hosting a Drupal installation with about 3000 users at a
time.



Reproduce code:
---
Im not sure what code produces the crash.

Actual result:
--
PHP is configured with:

'./configure' '--build=x86_64-redhat-linux'
'--host=x86_64-redhat-linux' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/usr/com'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--cache-file=../config.cache' '--with-libdir=lib64'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--with-imap-ssl' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr'
'--with-gmp' '--with-mysql=shared,/usr/lib64' '--with-xml'
'--enable-trans-sid' '--enable-shmop' '--enable-sockets'
'--with-regex=php' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-memory-limit' '--with-tsrm-pthreads'
'--enable-shared' '--disable-debug' '--with-zlib' '--with-gettext'
'--with-xsl' '--with-iconv' '--enable-inline-optimization'
'--disable-static' '--with-curl' '--enable-exif'
'--enable-magic-quotes' '--with-inifile' '--with-flatfile'
'--enable-dio' '--with-mbstring'
'--with-mime-magic=/etc/httpd/mime.magic' '--enable-soap'
'--enable-wddx' '--with-pear' '--enable-pic' '--disable-rpath'
'--enable-track-vars' '--enable-mcal' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--enable-memory-limit'
'--enable-zend-multibyte' '--with-mysqli=shared'
'--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pcntl'
'--enable-sigchild' '--with-apxs2=/usr/sbin/apxs' '--with-bz2'
'--with-sqllite=shared' '--enable-sqlite-utf8'



Here is a gdb backtrace of the thrown core dump from apache:

GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 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 "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/sbin/httpd
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /usr/lib64/libpcreposix.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/libpcreposix.so.0
Reading symbols from /usr/lib64/libaprutil-0.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/libaprutil-0.so.0
Reading symbols from /usr/lib64/libldap-2.2.so.7...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libldap-2.2.so.7
Reading symbols from /usr/lib64/liblber-2.2.so.7...(no debugging

#40466 [Opn->Fbk]: zend_mm_heap corruption

2007-02-13 Thread tony2001
 ID:   40466
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stojmir at on dot net dot mk
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux 2.6.9
 PHP Version:  5.2.1
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.




Previous Comments:


[2007-02-13 16:49:39] stojmir at on dot net dot mk

Description:

My apache crashes on random intervals (usually 10 hours):
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Tue Feb 13 17:28:01 2007] [notice] child pid 14881 exit signal
Segmentation fault (11), possible coredump in /var/apache-dump

Im guessing its related with the zend memory menager, but who nows, im
not really into it so i cant be sure.

PHP version 5.2.1, Apache 2.0.55, RedHat Enterprise Linux with
2.6.9-42.0.8.ELsmp on a x86_64 machine with dual core Xeon.

The site is hosting a Drupal installation with about 3000 users at a
time.



Reproduce code:
---
Im not sure what code produces the crash.

Actual result:
--
PHP is configured with:

'./configure' '--build=x86_64-redhat-linux'
'--host=x86_64-redhat-linux' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/usr/com'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--cache-file=../config.cache' '--with-libdir=lib64'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--with-imap-ssl' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr'
'--with-gmp' '--with-mysql=shared,/usr/lib64' '--with-xml'
'--enable-trans-sid' '--enable-shmop' '--enable-sockets'
'--with-regex=php' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-memory-limit' '--with-tsrm-pthreads'
'--enable-shared' '--disable-debug' '--with-zlib' '--with-gettext'
'--with-xsl' '--with-iconv' '--enable-inline-optimization'
'--disable-static' '--with-curl' '--enable-exif'
'--enable-magic-quotes' '--with-inifile' '--with-flatfile'
'--enable-dio' '--with-mbstring'
'--with-mime-magic=/etc/httpd/mime.magic' '--enable-soap'
'--enable-wddx' '--with-pear' '--enable-pic' '--disable-rpath'
'--enable-track-vars' '--enable-mcal' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--enable-memory-limit'
'--enable-zend-multibyte' '--with-mysqli=shared'
'--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pcntl'
'--enable-sigchild' '--with-apxs2=/usr/sbin/apxs' '--with-bz2'
'--with-sqllite=shared' '--enable-sqlite-utf8'



Here is a gdb backtrace of the thrown core dump from apache:

GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 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 "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/sbin/httpd
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /usr/lib64/libpcreposix.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/libpcreposix.so.0
Reading symbols from /usr/lib64/libaprutil-0.so.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/libaprutil-0.so.0
Reading symbols from /usr/lib64/libldap-2.2.so.7...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libldap-2.2.so.7
Reading symbols from /usr/lib64/liblber-2.2.so.7...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib64/liblber-2.2.so.7
Reading symbols from /lib64/tls/libdb-4.2.so...(no debugging symbols
found)...done.
Loaded symbols for /lib64/tls/libdb-4.2.so
Reading symbols from /usr/lib64/libexpat.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libexpat.so.0
Reading symbols from /usr/lib64/libap

#40071 [Com]: SoapServer returns 'Object hasn't xxx property' fault

2007-02-13 Thread davidfelton at codemasters dot com
 ID:   40071
 Comment by:   davidfelton at codemasters dot com
 Reported By:  ville at pmd dot fi
 Status:   No Feedback
 Bug Type: SOAP related
 Operating System: Debian Linux
 PHP Version:  5.2.0
 Assigned To:  dmitry
 New Comment:

dmitry you're saying the server code is wrong, what's wrong with it?

Is the code you posted a correction or taken from the file linked in
the original post - the code is identical now but I can't tell if the
file has been changed since the original posting to be what you posted
as a correction, or if you are pointing out incorrect code.


Previous Comments:


[2007-02-07 01:00:00] 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".



[2007-01-30 08:57:20] [EMAIL PROTECTED]

You probably did somthing wrong. I verified this code before sending it
to you.



[2007-01-26 17:52:34] ville at pmd dot fi

Even fixed as asked, the server still returns the same error.



[2007-01-26 17:30:43] [EMAIL PROTECTED]

Fix your server code:

class testService {
  public function authUser($authToken) {
return array(
  'firstName' => strtolower($authToken),
  'lastName' => strtoupper($authToken)
);
  }
}

class testService2 {
  public function authUser($authToken) {
$r = new objUserDetails();
$r->firstName = strtolower($authToken);
$r->lastName = strtoupper($authToken);
return $r;
  }
}




[2007-01-23 20:48:08] ville at pmd dot fi

The latest snapshot doesn't fix the problem, the returned error message
is still the same.



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/40071

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


#40466 [NEW]: zend_mm_heap corruption

2007-02-13 Thread stojmir at on dot net dot mk
From: stojmir at on dot net dot mk
Operating system: Linux 2.6.9
PHP version:  5.2.1
PHP Bug Type: Reproducible crash
Bug description:  zend_mm_heap corruption

Description:

My apache crashes on random intervals (usually 10 hours):
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Tue Feb 13 17:28:01 2007] [notice] child pid 14881 exit signal
Segmentation fault (11), possible coredump in /var/apache-dump

Im guessing its related with the zend memory menager, but who nows, im not
really into it so i cant be sure.

PHP version 5.2.1, Apache 2.0.55, RedHat Enterprise Linux with
2.6.9-42.0.8.ELsmp on a x86_64 machine with dual core Xeon.

The site is hosting a Drupal installation with about 3000 users at a
time.



Reproduce code:
---
Im not sure what code produces the crash.

Actual result:
--
PHP is configured with:

'./configure' '--build=x86_64-redhat-linux' '--host=x86_64-redhat-linux'
'--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-libdir=lib64' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--with-imap-ssl' '--enable-ftp'
'--with-gd' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-gmp'
'--with-mysql=shared,/usr/lib64' '--with-xml' '--enable-trans-sid'
'--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem'
'--enable-sysvshm' '--enable-sysvmsg' '--enable-memory-limit'
'--with-tsrm-pthreads' '--enable-shared' '--disable-debug' '--with-zlib'
'--with-gettext' '--with-xsl' '--with-iconv'
'--enable-inline-optimization' '--disable-static' '--with-curl'
'--enable-exif' '--enable-magic-quotes' '--with-inifile' '--with-flatfile'
'--enable-dio' '--with-mbstring' '--with-mime-magic=/etc/httpd/mime.magic'
'--enable-soap' '--enable-wddx' '--with-pear' '--enable-pic'
'--disable-rpath' '--enable-track-vars' '--enable-mcal'
'--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex'
'--enable-memory-limit' '--enable-zend-multibyte' '--with-mysqli=shared'
'--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pcntl'
'--enable-sigchild' '--with-apxs2=/usr/sbin/apxs' '--with-bz2'
'--with-sqllite=shared' '--enable-sqlite-utf8'



Here is a gdb backtrace of the thrown core dump from apache:

GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 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 "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/sbin/httpd
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /usr/lib64/libpcreposix.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libpcreposix.so.0
Reading symbols from /usr/lib64/libaprutil-0.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libaprutil-0.so.0
Reading symbols from /usr/lib64/libldap-2.2.so.7...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libldap-2.2.so.7
Reading symbols from /usr/lib64/liblber-2.2.so.7...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/liblber-2.2.so.7
Reading symbols from /lib64/tls/libdb-4.2.so...(no debugging symbols
found)...done.
Loaded symbols for /lib64/tls/libdb-4.2.so
Reading symbols from /usr/lib64/libexpat.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libexpat.so.0
Reading symbols from /usr/lib64/libapr-0.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libapr-0.so.0
Reading symbols from /lib64/tls/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/tls/librt.so.1
Reading symbols from /lib64/tls/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/tls/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/tls/libpthread.so.0
Reading symbols from /lib64/libdl.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symb

#39542 [Com]: Search order for include_once/require_once wrong in get_include_path

2007-02-13 Thread jsnell at e-normous dot com
 ID:   39542
 Comment by:   jsnell at e-normous dot com
 Reported By:  snowy at corporatezoo dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5.2.0
 New Comment:

still fails for me in the latest snapshot:

One other thing to note, it functions differently depending on where
you call the script from:
e-normous:/Users/jsnell/delete/php5/testcase/lib$
../../../php5.2-200702131330/sapi/cli/php ../test.php
/Users/jsnell/delete/php5/testcase/lib/
Included Test from lib/

vs.

e-normous:/Users/jsnell/delete/php5/testcase$
../../php5.2-200702131330/sapi/cli/php ./test.php
/Users/jsnell/delete/php5/testcase/lib/

and

e-normous:/Users/jsnell/delete/php5/testcase$
../../php5.2-200702131330/sapi/cli/php test.php
/Users/jsnell/delete/php5/testcase/lib/


Previous Comments:


[2007-02-09 05:11:00] snowy at corporatezoo dot com

hi tried the windows snap, also just tried 5.2.1 and same problem.

I'll just confirm with jsnell's observation that it is indeed
require_once that is throwing that exception.

require seems to work fine.

ie

function __autoload($class)
{
require_once($class . '.php');
}

breaks

whilst

function __autoload($class)
{
require($class . '.php');
} 

works



[2007-02-05 14:01:19] [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





[2007-02-02 22:22:26] snowy at corporatezoo dot com

oh so maybe the search order is different between require and
require_once?

hmmm makes senses since it looks like a namespace caching issue.



[2007-02-02 22:02:34] jsnell at e-normous dot com

Test case:
Create a file called test.php with the following:

and create a subdirectory called lib, containing a file called test.php
with the following contents:
Included Test from lib/

Results with php 4 (PHP 4.4.4 (cli) (built: Nov  1 2006 18:10:56) --
osx 10.4.x:
/Users/jsnell/delete/php5/testcase/lib/
Included Test from lib/

Results with PHP 5.1.4 (PHP 5.1.4 (cli) (built: Jan 25 2007 11:50:25)
):
php5 test.php
/Users/jsnell/delete/php5/testcase/lib/
Included Test from lib/

Results with PHP CVS (anon checked out on February 2nd):
../sapi/cli/php test.php
/Users/jsnell/delete/php5/testcase/

--
I believe the original submission is wrong, by changing require_once()
to require(), the file from lib/ is being loaded.



[2007-02-02 16:48:00] jsnell at e-normous dot com

Also seeing this in: PHP 5.2.0-8 (cli) (built: Dec 17 2006 20:03:51)
using Linux relay 2.4.29 #2 SMP Sat Mar 12 13:17:01 CST 2005 i686
GNU/Linux



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/39542

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


#40465 [NEW]: var_dump() printing details of private and protected object properties

2007-02-13 Thread wharmby at uk dot ibm dot com
From: wharmby at uk dot ibm dot com
Operating system: Windows XP
PHP version:  5CVS-2007-02-13 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description:  var_dump() printing details of private and protected object 
properties

Description:

I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise but
the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
/* XXX: perhaps when we are inside the class we
 * should permit access to private & protected 
 * values
 */
return 0;
}
php_printf("%*c[\"", level + 1, ' ');
PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds the
patch to correct the var_dump_code 
is as follows:

http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields
should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be cleaned
up as in the following patch: 

http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---



Expected result:

object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}


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


#40464 [Opn->Asn]: Session.save_path wont use default-value

2007-02-13 Thread iliaa
 ID:   40464
 Updated by:   [EMAIL PROTECTED]
 Reported By:  benni at gniza dot org
-Status:   Open
+Status:   Assigned
 Bug Type: *Configuration Issues
 Operating System: SuSE 9.3
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  iliaa


Previous Comments:


[2007-02-13 15:39:01] benni at gniza dot org

Description:

I can approve the behavior of BUG-ID 40434

Sessions won't work without setting a session.save_path explicitly! If
you just comment the session.save_path-line you get the error:


SAFE MODE Restriction in effect. The script whose uid is XZY is not
allowed to access owned by uid 0 in [Scriptname:Line of
session_start()]


This behavior is either a bug or the manual is wrong.

Quote from the manual:
==
session.save_path defines [...]. Defaults to /tmp. 
==

If I explicitly set the save_path (to /tmp or somewhere else) all is
okay!

Greetings Benjamin






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



#40455 [Opn->Csd]: safe_mode_exec_dir gets executed

2007-02-13 Thread tony2001
 ID:   40455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Open
+Status:   Closed
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2007-02-13 15:25:31] richton at nbcs dot rutgers dot edu

That patch makes my test case better, thanks.



[2007-02-13 14:29:10] [EMAIL PROTECTED]

Please try this patch:
http://tony2001.phpclub.net/dev/tmp/bug40455.diff



[2007-02-13 13:51:01] richton at nbcs dot rutgers dot edu

OK, gotcha. The expected result of
$process = proc_open("/bin/bash", $descriptorspec, $pipes);

is that PHP will attempt to execute "/bin/bash". This is the actual
result with Safe Mode off. The actual result of that code with safe
mode on is that it ignores "/bin/bash" and attempts to execute the
safe_mode_exec_dir (absurd, really; you can't run a directory),
*silently throwing away* my "/bin/bash" parameter.

This would be like going to a command prompt, and (let's just assume
that the safe_mode_exec_dir is /bin) typing "/bin/bash", and getting
the message "/bin: is a directory." While that may be a true output,
it's not what you typed -- if you type "/bin/bash", you expect
"/bin/bash" to be attempted, and you certainly don't expect your input
to be thrown away silently.



[2007-02-13 13:08:08] [EMAIL PROTECTED]

>Assuming you're on a system with /bin/bash existing, it's
>all you need to go.
Sorry, I've failed to guess what should be the expected result of this
code and what is the actual result you get.
(Please no truss output. Thank you.)



[2007-02-13 13:02:20] richton at nbcs dot rutgers dot edu

> To properly diagnose the problem, we
> need a short but complete example script to be able 
> to reproduce this bug ourselves.

And the script filed under "Reproduce code" doesn't meet 
this description how? I even show command lines with which 
to run it. Just in case it's not obvious: What was filed 
under "Reproduce code" in the original report is what I 
placed in "execdir.php" for the Result sections. Assuming 
you're on a system with /bin/bash existing, it's all you 
need to go.



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/40455

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


#40464 [NEW]: Session.save_path wont use default-value

2007-02-13 Thread benni at gniza dot org
From: benni at gniza dot org
Operating system: SuSE 9.3
PHP version:  5.2.1
PHP Bug Type: *Configuration Issues
Bug description:  Session.save_path wont use default-value

Description:

I can approve the behavior of BUG-ID 40434

Sessions won't work without setting a session.save_path explicitly! If you
just comment the session.save_path-line you get the error:


SAFE MODE Restriction in effect. The script whose uid is XZY is not
allowed to access owned by uid 0 in [Scriptname:Line of session_start()]


This behavior is either a bug or the manual is wrong.

Quote from the manual:
==
session.save_path defines [...]. Defaults to /tmp. 
==

If I explicitly set the save_path (to /tmp or somewhere else) all is
okay!

Greetings Benjamin


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


#40455 [Fbk->Opn]: safe_mode_exec_dir gets executed

2007-02-13 Thread richton at nbcs dot rutgers dot edu
 ID:   40455
 User updated by:  richton at nbcs dot rutgers dot edu
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

That patch makes my test case better, thanks.


Previous Comments:


[2007-02-13 14:29:10] [EMAIL PROTECTED]

Please try this patch:
http://tony2001.phpclub.net/dev/tmp/bug40455.diff



[2007-02-13 13:51:01] richton at nbcs dot rutgers dot edu

OK, gotcha. The expected result of
$process = proc_open("/bin/bash", $descriptorspec, $pipes);

is that PHP will attempt to execute "/bin/bash". This is the actual
result with Safe Mode off. The actual result of that code with safe
mode on is that it ignores "/bin/bash" and attempts to execute the
safe_mode_exec_dir (absurd, really; you can't run a directory),
*silently throwing away* my "/bin/bash" parameter.

This would be like going to a command prompt, and (let's just assume
that the safe_mode_exec_dir is /bin) typing "/bin/bash", and getting
the message "/bin: is a directory." While that may be a true output,
it's not what you typed -- if you type "/bin/bash", you expect
"/bin/bash" to be attempted, and you certainly don't expect your input
to be thrown away silently.



[2007-02-13 13:08:08] [EMAIL PROTECTED]

>Assuming you're on a system with /bin/bash existing, it's
>all you need to go.
Sorry, I've failed to guess what should be the expected result of this
code and what is the actual result you get.
(Please no truss output. Thank you.)



[2007-02-13 13:02:20] richton at nbcs dot rutgers dot edu

> To properly diagnose the problem, we
> need a short but complete example script to be able 
> to reproduce this bug ourselves.

And the script filed under "Reproduce code" doesn't meet 
this description how? I even show command lines with which 
to run it. Just in case it's not obvious: What was filed 
under "Reproduce code" in the original report is what I 
placed in "execdir.php" for the Result sections. Assuming 
you're on a system with /bin/bash existing, it's all you 
need to go.



[2007-02-13 09:07:20] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





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/40455

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


#40463 [Opn->Bgs]: PHP 5.2.1 does not work!

2007-02-13 Thread tony2001
 ID:   40463
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mark at kreine dot ru
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2007-02-13 15:12:29] mark at kreine dot ru

Description:

PHP 5.2.1 does not work! When I try to launch web server it outputs
many php errors and exits. I can't even view html files. Actually I
have reported a bug concerning this issue which was treated as a
"bogus" :( so I would like you this time to listen to me, as this
really is a bug which needs to be fixed.

I'm currently using (trying to do so) Apache 2.2.4 (isn't it a new
version?) and PHP5.2.1.

Reproduce code:
---
 //does not work

Expected result:

I expect to see the string "php"

Actual result:
--
Instead I see nothing but a huge amount of php-related errors.





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


#40463 [NEW]: PHP 5.2.1 does not work!

2007-02-13 Thread mark at kreine dot ru
From: mark at kreine dot ru
Operating system: Windows XP
PHP version:  5.2.1
PHP Bug Type: Apache2 related
Bug description:  PHP 5.2.1 does not work!

Description:

PHP 5.2.1 does not work! When I try to launch web server it outputs many
php errors and exits. I can't even view html files. Actually I have
reported a bug concerning this issue which was treated as a "bogus" :( so
I would like you this time to listen to me, as this really is a bug which
needs to be fixed.

I'm currently using (trying to do so) Apache 2.2.4 (isn't it a new
version?) and PHP5.2.1.

Reproduce code:
---
 //does not work

Expected result:

I expect to see the string "php"

Actual result:
--
Instead I see nothing but a huge amount of php-related errors.

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


#40462 [NEW]: Add a mode to lowercase header names in iconv_mime_decode_headers()

2007-02-13 Thread php-bug-0702 at nico dot edtinger dot at
From: php-bug-0702 at nico dot edtinger dot at
Operating system: -
PHP version:  5.2.1
PHP Bug Type: Feature/Change Request
Bug description:  Add a mode to lowercase header names in 
iconv_mime_decode_headers()

Description:

In RFC 822 all header names are defined as case independent. Therefore it
would be useful if a mode exists that lowercases all header names and also
merge multiple headers with the lowercased name in
iconv_mime_decode_header().

It is possible to do that after iconv_mime_decode_header(), but merging
multiple headers needs a fair amount of code, which is also already in
iconv_mime_decode_header().

Reproduce code:
---
$message = <<
  array(4) {
[0]=>
string(6) "line 1"
[1]=>
string(6) "line 2"
[2]=>
string(6) "line 3"
[3]=>
string(6) "line 4"
  }
  ["subject"]=>
  string(4) "test"
}

Actual result:
--
// currently not possible - with the default mode:
array(4) {
  ["received"]=>
  string(6) "line 1"
  ["RECEIVED"]=>
  string(6) "line 2"
  ["Received"]=>
  array(2) {
[0]=>
string(6) "line 3"
[1]=>
string(6) "line 4"
  }
  ["Subject"]=>
  string(4) "test"
}


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


#40455 [Opn->Fbk]: safe_mode_exec_dir gets executed

2007-02-13 Thread tony2001
 ID:   40455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

Please try this patch:
http://tony2001.phpclub.net/dev/tmp/bug40455.diff


Previous Comments:


[2007-02-13 13:51:01] richton at nbcs dot rutgers dot edu

OK, gotcha. The expected result of
$process = proc_open("/bin/bash", $descriptorspec, $pipes);

is that PHP will attempt to execute "/bin/bash". This is the actual
result with Safe Mode off. The actual result of that code with safe
mode on is that it ignores "/bin/bash" and attempts to execute the
safe_mode_exec_dir (absurd, really; you can't run a directory),
*silently throwing away* my "/bin/bash" parameter.

This would be like going to a command prompt, and (let's just assume
that the safe_mode_exec_dir is /bin) typing "/bin/bash", and getting
the message "/bin: is a directory." While that may be a true output,
it's not what you typed -- if you type "/bin/bash", you expect
"/bin/bash" to be attempted, and you certainly don't expect your input
to be thrown away silently.



[2007-02-13 13:08:08] [EMAIL PROTECTED]

>Assuming you're on a system with /bin/bash existing, it's
>all you need to go.
Sorry, I've failed to guess what should be the expected result of this
code and what is the actual result you get.
(Please no truss output. Thank you.)



[2007-02-13 13:02:20] richton at nbcs dot rutgers dot edu

> To properly diagnose the problem, we
> need a short but complete example script to be able 
> to reproduce this bug ourselves.

And the script filed under "Reproduce code" doesn't meet 
this description how? I even show command lines with which 
to run it. Just in case it's not obvious: What was filed 
under "Reproduce code" in the original report is what I 
placed in "execdir.php" for the Result sections. Assuming 
you're on a system with /bin/bash existing, it's all you 
need to go.



[2007-02-13 09:07:20] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 02:00:04] richton at nbcs dot rutgers dot edu

Description:

In PHP 5.2.1 and in snap 5.2 200702122330 the 
safe_mode_exec_dir gets executed. This did not occur in PHP 
5.2.0. I am using proc_open() here.

Reproduce code:
---
 array("pipe", "r"),  1 => array("pipe",
"w"), 2 => array("pipe", "w"));
$process = proc_open("/bin/bash", $descriptorspec, $pipes);
?>


Expected result:

With safe mode off, expected result of /bin/bash getting 
executed from PHP. (Note truss is like strace if you're used 
to Linux.)

$ truss -f ./php -n  ./execdir.php 2>&1 | grep execve
17635:  execve("php", 0xFFBFFBE4, 0xFFBFFBF4)  argc = 3
17636:  execve("/bin/sh", 0xFFBFEFB8, 0xFFBFFBF4)  argc = 3
17638:  execve("/bin/bash", 0x0003A414, 0x0003A41C)  argc = 1

Expected: That this result should be possible with an 
appropriate safe_mode_exec_dir.

Actual result:
--
With safe mode on

$ truss -f ./php -n -d safe_mode=On -d safe_mode_exec_dir=/
bin ./execdir.php 2>&1 | grep execve
17642:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17643:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17645:  execve("/bin/", 0x0003A408, 0x0003A410) 
Err#13 EACCES

safe_mode_exec_dir "/bin" gets executed, despite code for "/
bin/bash." Note that this is not related to the incoming PHP 
code at all:

$ truss -f ./php -n -d safe_mode=On -d 
safe_mode_exec_dir=FOOBAR ./execdir.php 2>&1 | grep execve
17649:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17650:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17652:  execve("FOOBAR/", 0x0003A408, 0x0003A410)   
Err#2 ENOENT






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


#36226 [Csd->Opn]: Inconsistent handling when passing potential arrays.

2007-02-13 Thread lsmith
 ID:   36226
 Updated by:   [EMAIL PROTECTED]
 Reported By:  say_ten at multiplay dot co dot uk
-Status:   Closed
+Status:   Open
 Bug Type: SOAP related
 Operating System: FreeBSD 6.0-p4
 PHP Version:  5.1.2
 Assigned To:  dmitry


Previous Comments:


[2007-02-08 15:32:19] [EMAIL PROTECTED]

Enabling this feature seems to result in giving me an array(null) if I
have a nill'ed sequence. Not sure if this is why you originally
introduced the feature of not returning single element sequences as
array's, but I was hoping to get an empty array in the above case.



[2006-02-02 12:42:40] [EMAIL PROTECTED]

This is not a bug but feature.
I stayed the default behavior unchanged, but added ability to create
arrays even if only one element exists.
To create arrays with single element, you should use special option in
SoapServer/SoapClient constructor.

$x = new SoapClient($wsdl, array('features' =>
SOAP_SINGLE_ELEMENT_ARRAYS));

Fixed in CVS HEAD and PHP_5_1.



[2006-01-31 15:45:34] [EMAIL PROTECTED]

Assigned to the maintainer.



[2006-01-31 13:24:23] say_ten at multiplay dot co dot uk

Description:

When using the following WSDL reponse the server is allowed to return 0
to many recipes.







The code returned from the function would be of the type:

array( array( "id" => 3, "recipe" => cake, "description" => "desc" )
);

If their is only 1 recipe the client returns a standard object of the
recipe.  If there's more than one, the client returns an array of
recipes.  This inconsitency results in code to detect and wrap the std
class into an array for compatibility with the following code,
foreach() for example.  This is also true when passing arrays of arrays
to the SOAP server.

Expected result:

I would expect the single element arrays passed in to remain single
element arrays at the other end.






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


#40455 [Fbk->Opn]: safe_mode_exec_dir gets executed

2007-02-13 Thread richton at nbcs dot rutgers dot edu
 ID:   40455
 User updated by:  richton at nbcs dot rutgers dot edu
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

OK, gotcha. The expected result of
$process = proc_open("/bin/bash", $descriptorspec, $pipes);

is that PHP will attempt to execute "/bin/bash". This is the actual
result with Safe Mode off. The actual result of that code with safe
mode on is that it ignores "/bin/bash" and attempts to execute the
safe_mode_exec_dir (absurd, really; you can't run a directory),
*silently throwing away* my "/bin/bash" parameter.

This would be like going to a command prompt, and (let's just assume
that the safe_mode_exec_dir is /bin) typing "/bin/bash", and getting
the message "/bin: is a directory." While that may be a true output,
it's not what you typed -- if you type "/bin/bash", you expect
"/bin/bash" to be attempted, and you certainly don't expect your input
to be thrown away silently.


Previous Comments:


[2007-02-13 13:08:08] [EMAIL PROTECTED]

>Assuming you're on a system with /bin/bash existing, it's
>all you need to go.
Sorry, I've failed to guess what should be the expected result of this
code and what is the actual result you get.
(Please no truss output. Thank you.)



[2007-02-13 13:02:20] richton at nbcs dot rutgers dot edu

> To properly diagnose the problem, we
> need a short but complete example script to be able 
> to reproduce this bug ourselves.

And the script filed under "Reproduce code" doesn't meet 
this description how? I even show command lines with which 
to run it. Just in case it's not obvious: What was filed 
under "Reproduce code" in the original report is what I 
placed in "execdir.php" for the Result sections. Assuming 
you're on a system with /bin/bash existing, it's all you 
need to go.



[2007-02-13 09:07:20] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 02:00:04] richton at nbcs dot rutgers dot edu

Description:

In PHP 5.2.1 and in snap 5.2 200702122330 the 
safe_mode_exec_dir gets executed. This did not occur in PHP 
5.2.0. I am using proc_open() here.

Reproduce code:
---
 array("pipe", "r"),  1 => array("pipe",
"w"), 2 => array("pipe", "w"));
$process = proc_open("/bin/bash", $descriptorspec, $pipes);
?>


Expected result:

With safe mode off, expected result of /bin/bash getting 
executed from PHP. (Note truss is like strace if you're used 
to Linux.)

$ truss -f ./php -n  ./execdir.php 2>&1 | grep execve
17635:  execve("php", 0xFFBFFBE4, 0xFFBFFBF4)  argc = 3
17636:  execve("/bin/sh", 0xFFBFEFB8, 0xFFBFFBF4)  argc = 3
17638:  execve("/bin/bash", 0x0003A414, 0x0003A41C)  argc = 1

Expected: That this result should be possible with an 
appropriate safe_mode_exec_dir.

Actual result:
--
With safe mode on

$ truss -f ./php -n -d safe_mode=On -d safe_mode_exec_dir=/
bin ./execdir.php 2>&1 | grep execve
17642:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17643:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17645:  execve("/bin/", 0x0003A408, 0x0003A410) 
Err#13 EACCES

safe_mode_exec_dir "/bin" gets executed, despite code for "/
bin/bash." Note that this is not related to the incoming PHP 
code at all:

$ truss -f ./php -n -d safe_mode=On -d 
safe_mode_exec_dir=FOOBAR ./execdir.php 2>&1 | grep execve
17649:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17650:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17652:  execve("FOOBAR/", 0x0003A408, 0x0003A410)   
Err#2 ENOENT






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


#40455 [Opn->Fbk]: safe_mode_exec_dir gets executed

2007-02-13 Thread tony2001
 ID:   40455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

>Assuming you're on a system with /bin/bash existing, it's
>all you need to go.
Sorry, I've failed to guess what should be the expected result of this
code and what is the actual result you get.
(Please no truss output. Thank you.)


Previous Comments:


[2007-02-13 13:02:20] richton at nbcs dot rutgers dot edu

> To properly diagnose the problem, we
> need a short but complete example script to be able 
> to reproduce this bug ourselves.

And the script filed under "Reproduce code" doesn't meet 
this description how? I even show command lines with which 
to run it. Just in case it's not obvious: What was filed 
under "Reproduce code" in the original report is what I 
placed in "execdir.php" for the Result sections. Assuming 
you're on a system with /bin/bash existing, it's all you 
need to go.



[2007-02-13 09:07:20] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 02:00:04] richton at nbcs dot rutgers dot edu

Description:

In PHP 5.2.1 and in snap 5.2 200702122330 the 
safe_mode_exec_dir gets executed. This did not occur in PHP 
5.2.0. I am using proc_open() here.

Reproduce code:
---
 array("pipe", "r"),  1 => array("pipe",
"w"), 2 => array("pipe", "w"));
$process = proc_open("/bin/bash", $descriptorspec, $pipes);
?>


Expected result:

With safe mode off, expected result of /bin/bash getting 
executed from PHP. (Note truss is like strace if you're used 
to Linux.)

$ truss -f ./php -n  ./execdir.php 2>&1 | grep execve
17635:  execve("php", 0xFFBFFBE4, 0xFFBFFBF4)  argc = 3
17636:  execve("/bin/sh", 0xFFBFEFB8, 0xFFBFFBF4)  argc = 3
17638:  execve("/bin/bash", 0x0003A414, 0x0003A41C)  argc = 1

Expected: That this result should be possible with an 
appropriate safe_mode_exec_dir.

Actual result:
--
With safe mode on

$ truss -f ./php -n -d safe_mode=On -d safe_mode_exec_dir=/
bin ./execdir.php 2>&1 | grep execve
17642:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17643:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17645:  execve("/bin/", 0x0003A408, 0x0003A410) 
Err#13 EACCES

safe_mode_exec_dir "/bin" gets executed, despite code for "/
bin/bash." Note that this is not related to the incoming PHP 
code at all:

$ truss -f ./php -n -d safe_mode=On -d 
safe_mode_exec_dir=FOOBAR ./execdir.php 2>&1 | grep execve
17649:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17650:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17652:  execve("FOOBAR/", 0x0003A408, 0x0003A410)   
Err#2 ENOENT






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


#40455 [Fbk->Opn]: safe_mode_exec_dir gets executed

2007-02-13 Thread richton at nbcs dot rutgers dot edu
 ID:   40455
 User updated by:  richton at nbcs dot rutgers dot edu
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

> To properly diagnose the problem, we
> need a short but complete example script to be able 
> to reproduce this bug ourselves.

And the script filed under "Reproduce code" doesn't meet 
this description how? I even show command lines with which 
to run it. Just in case it's not obvious: What was filed 
under "Reproduce code" in the original report is what I 
placed in "execdir.php" for the Result sections. Assuming 
you're on a system with /bin/bash existing, it's all you 
need to go.


Previous Comments:


[2007-02-13 09:07:20] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.





[2007-02-13 02:00:04] richton at nbcs dot rutgers dot edu

Description:

In PHP 5.2.1 and in snap 5.2 200702122330 the 
safe_mode_exec_dir gets executed. This did not occur in PHP 
5.2.0. I am using proc_open() here.

Reproduce code:
---
 array("pipe", "r"),  1 => array("pipe",
"w"), 2 => array("pipe", "w"));
$process = proc_open("/bin/bash", $descriptorspec, $pipes);
?>


Expected result:

With safe mode off, expected result of /bin/bash getting 
executed from PHP. (Note truss is like strace if you're used 
to Linux.)

$ truss -f ./php -n  ./execdir.php 2>&1 | grep execve
17635:  execve("php", 0xFFBFFBE4, 0xFFBFFBF4)  argc = 3
17636:  execve("/bin/sh", 0xFFBFEFB8, 0xFFBFFBF4)  argc = 3
17638:  execve("/bin/bash", 0x0003A414, 0x0003A41C)  argc = 1

Expected: That this result should be possible with an 
appropriate safe_mode_exec_dir.

Actual result:
--
With safe mode on

$ truss -f ./php -n -d safe_mode=On -d safe_mode_exec_dir=/
bin ./execdir.php 2>&1 | grep execve
17642:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17643:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17645:  execve("/bin/", 0x0003A408, 0x0003A410) 
Err#13 EACCES

safe_mode_exec_dir "/bin" gets executed, despite code for "/
bin/bash." Note that this is not related to the incoming PHP 
code at all:

$ truss -f ./php -n -d safe_mode=On -d 
safe_mode_exec_dir=FOOBAR ./execdir.php 2>&1 | grep execve
17649:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17650:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17652:  execve("FOOBAR/", 0x0003A408, 0x0003A410)   
Err#2 ENOENT






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


#40449 [Csd->Bgs]: libTidy Rel. 2007-01-23 produces "zend_mm_heap corrupted"

2007-02-13 Thread tony2001
 ID:   40449
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dg at artegic dot de
-Status:   Closed
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: SunsOS 5.9
 PHP Version:  5.2.1


Previous Comments:


[2007-02-13 12:57:29] dg at artegic dot de

The error is libtidy related. Thanks for your help!



[2007-02-13 09:49:04] [EMAIL PROTECTED]

Also cannot reproduce on Solaris 8 (using libtidy from CVS).



[2007-02-12 23:10:54] [EMAIL PROTECTED]

can you please try with libtidy from cvs
(http://sf.net/cvs/?group_id=27659) please? libtidy uses php emalloc
calls, so it is probable that the error is in tidy itself.
(I couldn't try myself yet, because my other pc is not on-line..)



[2007-02-12 19:34:03] [EMAIL PROTECTED]

Works perfectly fine on Linux.



[2007-02-12 19:17:33] dg at artegic dot de

Tried the CVS snapshot PHP 5.2.2-dev 200702121730 - same 
result...



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/40449

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


#40449 [Fbk->Csd]: libTidy Rel. 2007-01-23 produces "zend_mm_heap corrupted"

2007-02-13 Thread dg at artegic dot de
 ID:   40449
 User updated by:  dg at artegic dot de
 Reported By:  dg at artegic dot de
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: SunsOS 5.9
 PHP Version:  5.2.1
 New Comment:

The error is libtidy related. Thanks for your help!


Previous Comments:


[2007-02-13 09:49:04] [EMAIL PROTECTED]

Also cannot reproduce on Solaris 8 (using libtidy from CVS).



[2007-02-12 23:10:54] [EMAIL PROTECTED]

can you please try with libtidy from cvs
(http://sf.net/cvs/?group_id=27659) please? libtidy uses php emalloc
calls, so it is probable that the error is in tidy itself.
(I couldn't try myself yet, because my other pc is not on-line..)



[2007-02-12 19:34:03] [EMAIL PROTECTED]

Works perfectly fine on Linux.



[2007-02-12 19:17:33] dg at artegic dot de

Tried the CVS snapshot PHP 5.2.2-dev 200702121730 - same 
result...



[2007-02-12 18:15:14] [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





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/40449

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


#40419 [Com]: Trailing Slash in CGI request don't work

2007-02-13 Thread hacker at ee dot ethz dot ch
 ID:   40419
 Comment by:   hacker at ee dot ethz dot ch
 Reported By:  samuele dot diella at gmail dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: Slackware 10.2
 PHP Version:  5.2.1
 New Comment:

i can confirm this issue on sarge/amd64 (gcc),
whereas it works just fine on solaris8/sparc (gcc) with the same
extensions enabled and the same php.ini settings.
i am running fastcgi with apache2.0.59.


Previous Comments:


[2007-02-09 17:37:50] samuele dot diella at gmail dot com

Description:

In php-5.2.1 compiled as CGI under Apache 1.3.37, when i enter an url
with a trailing slash, with no params after, i get a "No input file
specified.".
If i don't write the slash, or if i write a single character after the
slash, the request is handled correctly.

es.:

http://www.myserver.com/phpinfo.php5 ---> works
http://www.myserver.com/phpinfo.php5/ ---> No input file specified.
http://www.myserver.com/phpinfo.php5/test ---> works

In php-5.2.0, compiled with the same config, the request is handled
correctly.

This is my config line:

./configure --prefix=/usr --with-xsl --sysconfdir=/etc
--enable-discard-path --with-config-file-path=/etc/apache/php5
--enable-safe-mode --with-openssl --with-mhash --enable-bcmath
--with-bz2 --with-pic --enable-calendar --enable-ctype --with-gdbm
--with-db3 --with-imap-ssl=/usr/local/lib/c-client
--with-imap=/usr/local/lib/c-client --enable-dbase --enable-ftp
--with-iconv --with-dom --with-exif --enable-exif --with-gd
--enable-gd-native-ttf --with-freetype-dir=/usr --with-t1lib=/usr
--with-jpeg-dir=/usr --with-png --with-gmp --enable-mbstring
--with-curl=/usr --with-pcre-regex=/usr --with-mysql
--with-mysql-sock=/var/run/mysql --with-mysqli
--with-gettext=shared,/usr --with-expat-dir=/usr --with-xml
--with-tsrm-pthreads --with-mm=/usr --enable-trans-sid --enable-shmop
--enable-sockets --with-regex=php --with-mime-magic --enable-sysvsem
--enable-sysvshm --enable-yp --enable-memory-limit --enable-shared
--disable-debug --with-zlib=/usr --with-mcrypt --with-ttf
--enable-force-cgi-redirect

This is my Apache configuration:

AddType application/x-httpd-php5 .php5
Action application/x-httpd-php5 "/cgi-bin/php5"
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

I tryed many configuration options in php.ini and in configure command,
but i was not able to get it works as before.






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


#40461 [NEW]: Test for #39602 fails bogusly

2007-02-13 Thread ben at qolc dot net
From: ben at qolc dot net
Operating system: Linux RedHat AS 4
PHP version:  5.2.1
PHP Bug Type: *Compile Issues
Bug description:  Test for #39602 fails bogusly

Description:

I had a number of 'make test' failures from 5.2.1, but the one for bug
#39602 concerned me so I checked it out. Running 
sapi/cli/php Zend/tests/bug39602.php
prints "ok", which seems to suggest that the test does NOT fail, so why is
it being reported as a failure? 

I don't know how the test framework works or how to increase the
verbosity; if you need any more info just let me know how to get it...



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


#34636 [Com]: cannot find -lgcrypt

2007-02-13 Thread ben at qolc dot net
 ID:   34636
 Comment by:   ben at qolc dot net
 Reported By:  webmaster at sunshinearcade dot com
 Status:   No Feedback
 Bug Type: Compile Failure
 Operating System: Fedora Core 3
 PHP Version:  5.0.5
 New Comment:

I hit this bug too, building 5.2.1 on RHEL 4. I think the configure
script should test for that library if --with-xsl is specified; many
distributions have separate packages for the runtime and compiletime
parts of libraries.


Previous Comments:


[2005-10-12 17:03:08] phpbugrep-20050921 at pgregg dot com

This is due to an unresolved dependency in RHEL 4 and FC.

resolve with:
root/pts/3-/mnt/RedHat/RPMS-178#->rpm -i
libgpg-error-devel-1.0-1.i386.rpm libgcrypt-devel-1.2.0-3.i386.rpm

Or whatever versions came with your RedHat CDs

PHP will then make cleanly.

Paul Gregg



[2005-10-04 01:00:03] 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".



[2005-09-26 08:49:45] [EMAIL PROTECTED]

Something you're building against needs libgcrypt (no idea why, but
this
seems to be a rather common FC problem). Try running this:

up2date libgcrypt-devel

(if this doesn't work, you may need to fetch an RPM of libgcrypt from
www.rpmfind.net).

And then compile again.



[2005-09-26 01:26:45] webmaster at sunshinearcade dot com

Description:

make and make install produce error stating ld could not find lgcrypt

PHP 5.0.5
Fedora Core 3
Apache 2.0.54
MySQL 4.1.14

Reproduce code:
---
 ./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mysqli=/usr/local/mysql/bin --with-xsl=/usr/lib


Actual result:
--
Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo
main/internal_functions_cli.lo -lcrypt -lexslt -lcrypt -lresolv -lm
-ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lmysqlclient -lz -lcrypt
-lnsl -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxslt -lxml2 -lz -lm
-lcrypt  -o sapi/cli/php
/usr/bin/ld: cannot find -lgcrypt
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1






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


#38577 [Bgs]: ini settings leak between virtual hosts with Apache 1.3

2007-02-13 Thread php at diptyque dot net
 ID:   38577
 User updated by:  php at diptyque dot net
 Reported By:  php at diptyque dot net
 Status:   Bogus
 Bug Type: Apache related
 Operating System: FreeBSD 4.4
 PHP Version:  4.4.4
 New Comment:

IMHO, the latest mbstring-related bug fix in PHP 5.2.1 has much more in
common with the problem I reported than those bug report numbers you
previously pointed to (!?)

see http://bugs.php.net/bug.php?id=39361
; mbstring function overloading - done although not activated


Previous Comments:


[2006-10-18 21:09:18] [EMAIL PROTECTED]

See bug #38670 and bug #38566.
Please use bug #38760 for further comments.



[2006-09-08 09:02:47] php at diptyque dot net

I'm not trying anything. You told me to download and install 
the latest CVS snapshot. That's what I did but the erratic 
function overloading behavior is still there. Considering no 
drastic changes have been made since v4.4.4 either at the 
Apache SAPI level (mod_php4.c) or in Mbstring (mbstring.c) 
source code, this isn't very surprising.

Regarding Xdebug, this particular extension also overrides 
two core functions -- namely var_dump() and set_time_limit
(). Don't you think it would be interesting to know if the 
function overloading that Xdebug performs is sticky or not 
when running under the Apache 1.3 SAPI?

I have the strong feeling that the original PHP function 
table state is not restored properly by Mbstring but I don't 
have the time nor the resources needed to nail down further 
the origin of the leak -- i.e. the overridden functions 
stickiness or whatever you may call it.



[2006-09-07 16:48:46] [EMAIL PROTECTED]

I'm not sure I understand what you're trying to do and to say.



[2006-09-07 16:39:49] php at diptyque dot net

FYI, I do *NOT* have any Zend or Xdebug extension 
installed... I have downloaded Xdebug only to compare its 
overriding technique with the one used in Mbstring 
extension.

=begin
[diptyque] % php -m
[PHP Modules]
bz2
ctype
curl
gd
imap
mbstring
mysql
openssl
overload
pcre
posix
readline
session
sqlite
standard
tokenizer
xml
zlib

[Zend Modules]
=end

BTW, I compared source files for apache SAPI 
(./sapi/apache/mod_php4.c) and mbstring extension 
(./ext/mbstring/mbstring.c) between version 4.4.4 and 
latest stable version and did not find anything different 
(!?)



[2006-09-07 15:25:39] [EMAIL PROTECTED]

Please remove all zend_extensions, including XDebug and try again.



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/38577

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


#40460 [Opn->Csd]: Segfault when calling reflection methods of a dynamic property

2007-02-13 Thread tony2001
 ID:   40460
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alexiev at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.2.0
 New Comment:

This bug has been fixed in CVS.

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

Duplicate of bug #40431.


Previous Comments:


[2007-02-13 10:32:14] alexiev at gmail dot com

Here are the test results:

Windows XP PHP 5.2.0
-
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
notpublic

Windows XP PHP 5.2.2-dev (cli) (built: Feb 13 2007 08:23:31)
-
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public

Linux PHP 5.2.2-dev (cli) (built: Feb 13 2007 12:14:28)
-
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public

With Win and PHP 5.2.0 there is no segfault, but the isPublic returned
FALSE!

If you try the getProperty method on the 'dynamic_member', an exception
is still thrown in the snapshot!

Fatal error: Uncaught exception 'ReflectionException' with message
'Property dynamic_member does not exist' in /tmp/test.php:5
Stack trace:
#0 /tmp/test.php(5): ReflectionClass->getProperty('dynamic_member')
#1 {main}
  thrown in /tmp/test.php on line 5



[2007-02-13 09:58:41] [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





[2007-02-13 09:54:34] alexiev at gmail dot com

Description:

The dynamic properties are introduced in php 5.2 The problem I found
was when you try to call most of the methods of the ReflectionProperty
instance for a dynamic object property, returned with
ReflectionObject::getProperties.

Additionally when you use ReflectionObject:;getProperty($property_name)
for a dynamic property, an exception is thrown! The metter is duscussed
in #37682

Look at the code for more info.

I was able to test only on php 5.2.0! I don't know if the problem still
exists in php 5.2.1!

Reproduce code:
---
dynamic_member = 'value';
$r = new ReflectionObject($i);
// $r->getProperty('dynamic_member'); throws an exception - there is no
'dynamic_member' property?
$properties = $r->getProperties();
var_dump($properties[0]); // Looks OK
var_dump($properties[0]->getName()); // Also OK
echo $properties[0]->isPublic() ? 'public' : 'notpublic'; // Causes
Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
$properties[0]->isProtected(); // Causes Segmentation fault
$properties[0]->isStatic(); // Causes Segmentation fault
$properties[0]->isDefault(); // Causes Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
?>

Expected result:

object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public


Actual result:
--
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
Segmentation fault






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


#40460 [Fbk->Opn]: Segfault when calling reflection methods of a dynamic property

2007-02-13 Thread alexiev at gmail dot com
 ID:   40460
 User updated by:  alexiev at gmail dot com
 Reported By:  alexiev at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Class/Object related
 Operating System: Linux
-PHP Version:  5.2.1
+PHP Version:  5.2.0
 New Comment:

Here are the test results:

Windows XP PHP 5.2.0
-
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
notpublic

Windows XP PHP 5.2.2-dev (cli) (built: Feb 13 2007 08:23:31)
-
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public

Linux PHP 5.2.2-dev (cli) (built: Feb 13 2007 12:14:28)
-
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public

With Win and PHP 5.2.0 there is no segfault, but the isPublic returned
FALSE!

If you try the getProperty method on the 'dynamic_member', an exception
is still thrown in the snapshot!

Fatal error: Uncaught exception 'ReflectionException' with message
'Property dynamic_member does not exist' in /tmp/test.php:5
Stack trace:
#0 /tmp/test.php(5): ReflectionClass->getProperty('dynamic_member')
#1 {main}
  thrown in /tmp/test.php on line 5


Previous Comments:


[2007-02-13 09:58:41] [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





[2007-02-13 09:54:34] alexiev at gmail dot com

Description:

The dynamic properties are introduced in php 5.2 The problem I found
was when you try to call most of the methods of the ReflectionProperty
instance for a dynamic object property, returned with
ReflectionObject::getProperties.

Additionally when you use ReflectionObject:;getProperty($property_name)
for a dynamic property, an exception is thrown! The metter is duscussed
in #37682

Look at the code for more info.

I was able to test only on php 5.2.0! I don't know if the problem still
exists in php 5.2.1!

Reproduce code:
---
dynamic_member = 'value';
$r = new ReflectionObject($i);
// $r->getProperty('dynamic_member'); throws an exception - there is no
'dynamic_member' property?
$properties = $r->getProperties();
var_dump($properties[0]); // Looks OK
var_dump($properties[0]->getName()); // Also OK
echo $properties[0]->isPublic() ? 'public' : 'notpublic'; // Causes
Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
$properties[0]->isProtected(); // Causes Segmentation fault
$properties[0]->isStatic(); // Causes Segmentation fault
$properties[0]->isDefault(); // Causes Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
?>

Expected result:

object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public


Actual result:
--
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
Segmentation fault






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


#40460 [Opn->Fbk]: Segfault when calling reflection methods of a dynamic property

2007-02-13 Thread tony2001
 ID:   40460
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alexiev at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.2.1
 New Comment:

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




Previous Comments:


[2007-02-13 09:54:34] alexiev at gmail dot com

Description:

The dynamic properties are introduced in php 5.2 The problem I found
was when you try to call most of the methods of the ReflectionProperty
instance for a dynamic object property, returned with
ReflectionObject::getProperties.

Additionally when you use ReflectionObject:;getProperty($property_name)
for a dynamic property, an exception is thrown! The metter is duscussed
in #37682

Look at the code for more info.

I was able to test only on php 5.2.0! I don't know if the problem still
exists in php 5.2.1!

Reproduce code:
---
dynamic_member = 'value';
$r = new ReflectionObject($i);
// $r->getProperty('dynamic_member'); throws an exception - there is no
'dynamic_member' property?
$properties = $r->getProperties();
var_dump($properties[0]); // Looks OK
var_dump($properties[0]->getName()); // Also OK
echo $properties[0]->isPublic() ? 'public' : 'notpublic'; // Causes
Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
$properties[0]->isProtected(); // Causes Segmentation fault
$properties[0]->isStatic(); // Causes Segmentation fault
$properties[0]->isDefault(); // Causes Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
?>

Expected result:

object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public


Actual result:
--
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
Segmentation fault






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


#40460 [NEW]: Segfault when calling reflection methods of a dynamic property

2007-02-13 Thread alexiev at gmail dot com
From: alexiev at gmail dot com
Operating system: Linux
PHP version:  5.2.1
PHP Bug Type: Class/Object related
Bug description:  Segfault when calling reflection methods of a dynamic property

Description:

The dynamic properties are introduced in php 5.2 The problem I found was
when you try to call most of the methods of the ReflectionProperty
instance for a dynamic object property, returned with
ReflectionObject::getProperties.

Additionally when you use ReflectionObject:;getProperty($property_name)
for a dynamic property, an exception is thrown! The metter is duscussed in
#37682

Look at the code for more info.

I was able to test only on php 5.2.0! I don't know if the problem still
exists in php 5.2.1!

Reproduce code:
---
dynamic_member = 'value';
$r = new ReflectionObject($i);
// $r->getProperty('dynamic_member'); throws an exception - there is no
'dynamic_member' property?
$properties = $r->getProperties();
var_dump($properties[0]); // Looks OK
var_dump($properties[0]->getName()); // Also OK
echo $properties[0]->isPublic() ? 'public' : 'notpublic'; // Causes
Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
$properties[0]->isProtected(); // Causes Segmentation fault
$properties[0]->isStatic(); // Causes Segmentation fault
$properties[0]->isDefault(); // Causes Segmentation fault
$properties[0]->isPrivate(); // Causes Segmentation fault
?>

Expected result:

object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
public


Actual result:
--
object(ReflectionProperty)#3 (2) {
  ["name"]=>
  string(14) "dynamic_member"
  ["class"]=>
  string(8) "stdClass"
}
string(14) "dynamic_member"
Segmentation fault


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


#40449 [Fbk]: libTidy Rel. 2007-01-23 produces "zend_mm_heap corrupted"

2007-02-13 Thread tony2001
 ID:   40449
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dg at artegic dot de
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: SunsOS 5.9
 PHP Version:  5.2.1
 New Comment:

Also cannot reproduce on Solaris 8 (using libtidy from CVS).


Previous Comments:


[2007-02-12 23:10:54] [EMAIL PROTECTED]

can you please try with libtidy from cvs
(http://sf.net/cvs/?group_id=27659) please? libtidy uses php emalloc
calls, so it is probable that the error is in tidy itself.
(I couldn't try myself yet, because my other pc is not on-line..)



[2007-02-12 19:34:03] [EMAIL PROTECTED]

Works perfectly fine on Linux.



[2007-02-12 19:17:33] dg at artegic dot de

Tried the CVS snapshot PHP 5.2.2-dev 200702121730 - same 
result...



[2007-02-12 18:15:14] [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





[2007-02-12 18:10:53] dg at artegic dot de

Description:

Script produces error message: "zend_mm_heap corrupted"


Configure Command =>  './configure' '--disable-all' '--
disable-cgi' '--disable-ipv6' '--enable-static' '--enable-
shared' '--enable-thread-safety' '--enable-mbstring' '--
enable-mbregex' '--with-pcre-regex' '--with-zlib' '--with-
iconv' '--enable-libxml' '--enable-xml' '--with-libxml-dir=/
usr/local/lib' '--with-tidy' '--enable-zend-multibyte' '--
with-curlwrappers' '--with-dom' '--with-curl' '--without-
sqlite' '--without-pdo-sqlite' '--with-mysql=/usr/local/
mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config'


tidy
Extension Version => 2.0 ($Id: tidy.c,v 1.66.2.8.2.21 
2007/01/23 19:23:29 nlopess Exp $)
tidy.clean_output => no value => no value
tidy.default_config => no value => no value


Reproduce code:
---

a html document
 true,
   'output-xhtml'  => true,
   'wrap'  => 200);
$tidy = new tidy;
$tidy->parseString($html, $config, 'utf8');
$tidy->cleanRepair();
echo $tidy;
?>

Actual result:
--
Sorry - no GDB backtrace on this machine...






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


#40452 [Opn->Asn]: ODBC and SQL Server datetime parameter fields fail on insert

2007-02-13 Thread tony2001
 ID:   40452
 Updated by:   [EMAIL PROTECTED]
 Reported By:  aspen dot olmsted at alliance dot biz
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows 2003, XP
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  wez


Previous Comments:


[2007-02-13 01:31:36] aspen dot olmsted at alliance dot biz

Yes.  If you insert into sql other ways it works perfect.  Including
through php



[2007-02-12 22:22:23] [EMAIL PROTECTED]

Are you sure "2007-02-12 14:5" is correct timestamp for MSSQL?
Doesn't it lack the last symbol?



[2007-02-12 22:07:47] aspen dot olmsted at alliance dot biz

Here is the error:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY010]: Function sequence error: 0 [Microsoft][ODBC Driver
Manager] Function sequence error (SQLExecute[0] at
ext\pdo_odbc\odbc_stmt.c:133)' in C:\Program
Files\nusphere\phped\Projects\ASCPlatform\noname1.php:11 Stack trace:
#0 C:\Program
Files\nusphere\phped\Projects\ASCPlatform\noname1.php(11):
PDOStatement->execute(Array) #1 {main} thrown in C:\Program
Files\nusphere\phped\Projects\ASCPlatform\noname1.php on line 11

The only thing missing from the script is:
$dbh = new PDO('odbc:peo', '11', '11');



[2007-02-12 21:54:51] [EMAIL PROTECTED]

But you forgot the error itself.
And I would appreciate if you include a working script, too.



[2007-02-12 21:43:30] aspen dot olmsted at alliance dot biz

I included a small script in the reproduce code?



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/40452

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


#40459 [Opn->Asn]: Stat and Dir stream wrapper methods do not call constructor

2007-02-13 Thread tony2001
 ID:   40459
 Updated by:   [EMAIL PROTECTED]
 Reported By:  clay at killersoft dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Streams related
 Operating System: irrelevant
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  wez


Previous Comments:


[2007-02-13 07:01:33] clay at killersoft dot com

Description:

The following methods in a userspace stream wrapper will not call the
constructor:

url_stat()
dir_opendir()
rmdir()
mkdir()
rename()
unlink()


Reproduce code:
---
http://killersoft.com/misc/Test_Stream.php.txt

Expected result:

Any time a line of output beginning with '== [method] CALLED' appears,
that line should contain an 'obj: ' value with a uniqid value,
indicating that the constructor was called.

Actual result:
--
== dir_opendir METHOD CALLED (obj: ) ==
...
== dir_readdir METHOD CALLED (obj: ) ==
...
== dir_closedir METHOD CALLED (obj: ) ==
...
== url_stat METHOD CALLED (obj: ) ==
...
== mkdir METHOD CALLED (obj: ) ==
...
== rmdir METHOD CALLED (obj: ) ==
...
== unlink METHOD CALLED (obj: ) ==
...
== rename METHOD CALLED (obj: ) ==
...





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


#40443 [Bgs]: session_start problem

2007-02-13 Thread bjori
 ID:   40443
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lawatia_mhm at yahoo dot com
 Status:   Bogus
 Bug Type: Safe Mode/open_basedir
 Operating System: CentOS
 PHP Version:  5.2.1
 New Comment:

I am sorry, but this is not a support forum.
We simply don't have the time nor the man power to answer 
all questions that can come up.

Please have a look at http://php.net/support for more 
appropriate places to ask.


Previous Comments:


[2007-02-13 07:43:48] lawatia_mhm at yahoo dot com

Hello dear ..
any body here ?? ..

3 sites on the server can't do anything because of this problem :( ..



[2007-02-12 19:06:54] lawatia_mhm at yahoo dot com

Anybody here dear ?



[2007-02-12 10:25:21] lawatia_mhm at yahoo dot com

Dear you said :
Set appropriate session.save_path.

Can you tell me to what do I have to write dear :
; As of PHP 4.0.1, you can define the path as:
; 
; session.save_path = "N;/path"   
;
; where N is an integer.  Instead of storing all the session files in
; /path, what this will do is use subdirectories N-levels deep, and
; store the session data in those directories.  This is useful if you  
   
; or your OS have problems with lots of files in one directory, and is
; a more efficient layout for servers that handle lots of sessions.
   
; 
; NOTE 1: PHP will not create this directory structure automatically.
; You can use the script in the ext/session dir for that
purpose.
; NOTE 2: See the section on garbage collection below if you choose to 
   
; use subdirectories for session storage
; 
; The file storage module creates files using mode 600 by default.
; You can change that by using
;
; session.save_path = "N;MODE;/path"
; 
; where MODE is the octal representation of the mode. Note that this
; does not overwrite the process's umask.
;session.save_path = "/tmp"



[2007-02-12 10:03:15] [EMAIL PROTECTED]

>The script whose uid is 32025 is not allowed to access
>owned by uid 0 in
Set appropriate session.save_path.



[2007-02-12 09:55:43] lawatia_mhm at yahoo dot com

Description:

Dear ..
When I used php 5.2.0 .. the Sound Library Script was working great
with Safe mode ...

But yesterday when I Upgraded to 5.2.1 the library isn't working with
Safe mode ...


Warning: session_start() [function.session-start]: SAFE MODE
Restriction in effect. The script whose uid is 32025 is not allowed to
access owned by uid 0 in /home/xxx/public_html/snd/admin/index.php on
line 10

Fatal error: session_start() [function.session-start]: Failed to
initialize storage module: files (path: ) in
/home/xxx/public_html/snd/admin/index.php on line 10
**

How to fix the problem dear ?

Notes :
I disabled Safe mode .. the library worked but when I enabled it this
what happened ..






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


#40458 [Opn->Fbk]: stream_select

2007-02-13 Thread tony2001
 ID:   40458
 Updated by:   [EMAIL PROTECTED]
 Reported By:  roberto at spadim dot com dot br
-Status:   Open
+Status:   Feedback
-Bug Type: *General Issues
+Bug Type: Streams related
 Operating System: linux 64bits
 PHP Version:  5.2.1
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.




Previous Comments:


[2007-02-13 04:44:49] roberto at spadim dot com dot br

Description:

hello i was using archlinux 32 bits version on pentium3 
i bought an intel core 2 duo e6600 and i'm using archlinux 64
my code on 32 bits was using

$read = array($stream);
if (false === ($num_changed_streams = stream_select($read, $write =
NULL, $except = NULL, 1,0))){

on 32 bits ok, it wait one second or if data received return with
num_changed_stream>0

on 64 bits no, it return imediatly and num_changed_stream=0, since
tcpdump didn't show nothing i think that's an 64bits bug

i created $stream with:

$stream = stream_socket_client("tcp://172.16.0.1:515", $this->errNo,
$this->errStr, $this->timeout);
stream_set_write_buffer($stream,0);
stream_set_blocking($stream,1);
stream_set_timeout($stream,2,0);



Reproduce code:
---
errNo,
$this->errStr, $this->timeout);
stream_set_write_buffer($stream,0);
stream_set_blocking($stream,1);
stream_set_timeout($stream,2,0);

$read = array($stream);
echo microtime(0)."\n";
$num_changed_streams = stream_select($read, $write = NULL, $except =
NULL, 1,0);
echo microtime(0)."\n";

?>

Expected result:

a long time (1 second of diff)

Actual result:
--
on 32bits php ok 
on 64 bits php return .0010 seconds of diff and tcpdump didn't showed
nothing on this stream





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


#40455 [Opn->Fbk]: safe_mode_exec_dir gets executed

2007-02-13 Thread tony2001
 ID:   40455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  richton at nbcs dot rutgers dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: Safe Mode/open_basedir
 Operating System: Solaris
 PHP Version:  5CVS-2007-02-13 (snap)
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

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

Please avoid embedding huge scripts into the report.




Previous Comments:


[2007-02-13 02:00:04] richton at nbcs dot rutgers dot edu

Description:

In PHP 5.2.1 and in snap 5.2 200702122330 the 
safe_mode_exec_dir gets executed. This did not occur in PHP 
5.2.0. I am using proc_open() here.

Reproduce code:
---
 array("pipe", "r"),  1 => array("pipe",
"w"), 2 => array("pipe", "w"));
$process = proc_open("/bin/bash", $descriptorspec, $pipes);
?>


Expected result:

With safe mode off, expected result of /bin/bash getting 
executed from PHP. (Note truss is like strace if you're used 
to Linux.)

$ truss -f ./php -n  ./execdir.php 2>&1 | grep execve
17635:  execve("php", 0xFFBFFBE4, 0xFFBFFBF4)  argc = 3
17636:  execve("/bin/sh", 0xFFBFEFB8, 0xFFBFFBF4)  argc = 3
17638:  execve("/bin/bash", 0x0003A414, 0x0003A41C)  argc = 1

Expected: That this result should be possible with an 
appropriate safe_mode_exec_dir.

Actual result:
--
With safe mode on

$ truss -f ./php -n -d safe_mode=On -d safe_mode_exec_dir=/
bin ./execdir.php 2>&1 | grep execve
17642:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17643:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17645:  execve("/bin/", 0x0003A408, 0x0003A410) 
Err#13 EACCES

safe_mode_exec_dir "/bin" gets executed, despite code for "/
bin/bash." Note that this is not related to the incoming PHP 
code at all:

$ truss -f ./php -n -d safe_mode=On -d 
safe_mode_exec_dir=FOOBAR ./execdir.php 2>&1 | grep execve
17649:  execve("php", 0xFFBFFBAC, 0xFFBFFBCC)  argc = 7
17650:  execve("/bin/sh", 0xFFBFEF80, 0xFFBFFBCC)  argc = 3
17652:  execve("FOOBAR/", 0x0003A408, 0x0003A410)   
Err#2 ENOENT






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


#40446 [Bgs]: php.exe fails to start

2007-02-13 Thread tony2001
 ID:   40446
 Updated by:   [EMAIL PROTECTED]
 Reported By:  a at b dot c dot de
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows XP SP2
 PHP Version:  5.2.1
 New Comment:

Memory limit was not enabled before 5.2.1.


Previous Comments:


[2007-02-13 00:16:40] a at b dot c dot de

So 5.2.0 doesn't mind the 'B', but 5.2.1 does.



[2007-02-13 00:15:18] a at b dot c dot de

Close; the line in php.ini actually read

memory_limit = 128MB  ; Maximum amount of memory a script may
consume (8MB)



[2007-02-12 11:56:38] [EMAIL PROTECTED]

Open your php.ini, find the line looking like this:
memory_limit = 128
and change it to this:
memory_limit = 128M <-- notice the "M" here.
"128" is 128 bytes
"128M" is 128 megabytes.



[2007-02-12 11:46:40] a at b dot c dot de

(I said "edit"). Earlier upgrades included 5.1.6->5.2.0.



[2007-02-12 11:45:39] a at b dot c dot de

Description:

PHP 5.2.1 (manually downloaded, extracted and copied to working
directory) fails to start either as a CLI or as an Apache module;
Apache fails to start also (though this may be a side-effect of
something else).

Installation was through exactly the same installation process as
earlier upgrades (e.g., 5.0.x => 5.1). php.ini is being parsed (one
early attempt at the below reminded me to turn off a third-party
extension with its "Failed Loading" message).

Downgrading to 5.2.0 (through the same installation process) works
successfully. Installing 5.2.1 side-by-side with 5.2.0 in another
directory has the same result as below.

Reproduce code:
---
>From the command line:
c:\> php -v


Expected result:

PHP 5.2.1 (cli) (built: Feb  7 2007 23:19:16)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

Actual result:
--
Fatal error: Allowed memory size of 128 bytes exhausted (tried to
allocate 8192 bytes) in Unknown on line 0





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


#40454 [Opn->Bgs]: PHP 5.2.1 does not work with Apache 2.0.49

2007-02-13 Thread mike
 ID:   40454
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mark at kreine dot ru
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

Please upgrade your nearly three years old Apache.


Previous Comments:


[2007-02-13 00:59:17] mark at kreine dot ru

Description:

Well, I have installed PHP 5.2.1 with Apache 2.0.49. I used the MSI
installer provided on your site. Then I tried to open some local PHP
pages.

Reproduce code:
---
Example code:



Expected result:

I expected to see the string "Hello"...

Actual result:
--
Instead web server hung up and then I got a message saying that there
was an error in web server. Here you can see the resulting file
"error.log" :
http://www.webtalkforum.info/error.log





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


#40456 [Opn->Bgs]: php5.2.1 - Uncaught exception try/catch

2007-02-13 Thread mike
 ID:   40456
 Updated by:   [EMAIL PROTECTED]
 Reported By:  zeldign at zeldign dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: CentOS 4.4
 PHP Version:  5.2.1
 New Comment:

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.




Previous Comments:


[2007-02-13 08:22:13] zeldign at zeldign dot com

Yes .

Use together with and is using eaccelerator coming zend optimizer
present.

Is established to be loaded all by zend_extension Eu, is it related
with it?



[2007-02-13 06:28:09] judas dot iscariote at gmail dot com

works perfectly fine here, do you have any zend_extension loaded ? APC,
eaccelerator, Zend optimizer..or whatever?



[2007-02-13 03:26:31] zeldign at zeldign dot com

Description:

php5.2.0 -> caught exception
php5.2.1 -> Uncaught exception

Reproduce code:
---


Expected result:

Caught Default Exception exception 'a' in
/home/company/solution/public_html/info.php:11 Stack trace: #0 {main}

Actual result:
--
Fatal error: Uncaught exception 'a' in
/home/company/igearmall/public_html/info.php:11 Stack trace: #0 {main}
thrown in /home/company/igearmall/public_html/info.php on line 11





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


#40456 [Opn]: php5.2.1 - Uncaught exception try/catch

2007-02-13 Thread zeldign at zeldign dot com
 ID:   40456
 User updated by:  zeldign at zeldign dot com
 Reported By:  zeldign at zeldign dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: CentOS 4.4
 PHP Version:  5.2.1
 New Comment:

Yes .

Use together with and is using eaccelerator coming zend optimizer
present.

Is established to be loaded all by zend_extension Eu, is it related
with it?


Previous Comments:


[2007-02-13 06:28:09] judas dot iscariote at gmail dot com

works perfectly fine here, do you have any zend_extension loaded ? APC,
eaccelerator, Zend optimizer..or whatever?



[2007-02-13 03:26:31] zeldign at zeldign dot com

Description:

php5.2.0 -> caught exception
php5.2.1 -> Uncaught exception

Reproduce code:
---


Expected result:

Caught Default Exception exception 'a' in
/home/company/solution/public_html/info.php:11 Stack trace: #0 {main}

Actual result:
--
Fatal error: Uncaught exception 'a' in
/home/company/igearmall/public_html/info.php:11 Stack trace: #0 {main}
thrown in /home/company/igearmall/public_html/info.php on line 11





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