#38137 [Opn->Fbk]: Apache 2.0.55-Openldap 2.3.24-php 5.1.4 causes apache to segfault
ID: 38137 Updated by: [EMAIL PROTECTED] Reported By: bill dot macallister at prideindustries dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Debian Sarge with 3.6.8 kernel PHP Version: 5.1.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2006-07-19 06:22:33] bill dot macallister at prideindustries dot com Description: On a Debian Sarge system with a 2.6.8 kernel I am building Apache 2.0.55 with PHP 5.1.4 with LDAP support. The build seems to complete just fine, but the server will not start. When I do a 'apache/bin/apachectl configtest' I get a Syntax OK message just before I get the SEGFAULT message. When I remove the PHP module load directive from the httpd.conf file the SEGFAULT disappears. I get the same result if I build PHP 4.4.2. I have finally gotten the server to build by building against OpenLDAP 2.2.27. It looks like PHP is having some problem with OpenLDAP 2.3.x? Reproduce code: --- Here is the configuration line that works: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.2.27 Here is the one that fails: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.3.24 Expected result: apachectl configtest Syntax OK Actual result: -- apachectl configtest Syntax OK /usr/local/apache/bin/apachectl: line 100: 5039 Segmentation fault $HTTPD -t -- Edit this bug report at http://bugs.php.net/?id=38137&edit=1
#38136 [Opn->Fbk]: Order of ./configure options can result in --enable-memory-limit being ignored
ID: 38136 Updated by: [EMAIL PROTECTED] Reported By: twells at smarterliving dot com -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: RedHat 9 PHP Version: 4.4.2 New Comment: Please try `make clean` first. Previous Comments: [2006-07-19 01:11:57] twells at smarterliving dot com Description: The order of ./configure arguments can result in --enable-memory-limit functionality not being built into the binary. Reproduce code: --- 1) Build PHP with: ./configure --with-mysql=/usr --with-curl --with-gettext --with-mcrypt --with-dom --enable-inline --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-zlib-dir=/usr/lib --with-openssl --enable-ftp --with-apache=../apache_1.3.34 --enable-memcache --enable-mbstring --enable-memory-limit 2) Observe in the configure output that "checking whether to enable a memory limit... yes" 3) Install, make sure memory_limit is set in php.ini and restart apache and load phpinfo(). Observe there is no memory_limit value in the PHP Core output however --enable-memory-limit is listed in the Configure Command output. Test calls to memory_get_usage() will result in a PHP Fatal call to an undefined function. 4) Rebuild PHP with: ./configure --with-mysql=/usr --with-curl --with-gettext --with-mcrypt --with-dom --enable-inline --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-zlib-dir=/usr/lib --with-openssl --enable-ftp --enable-memory-limit --enable-memcache --enable-mbstring --with-apache=../apache_1.3.34 5) Again in the config output you should see: "checking whether to enable a memory limit... yes" 6) Install, restart apache, and load phpinfo(). memory_limit is now visible in the PHP Core output and functions like memory_get_usage() work again Expected result: Both configure lines should result in an identical PHP build Actual result: -- --enable-memory-limit functionality is missing from the build. -- Edit this bug report at http://bugs.php.net/?id=38136&edit=1
#38137 [NEW]: Apache 2.0.55-Openldap 2.3.24-php 5.1.4 causes apache to segfault
From: bill dot macallister at prideindustries dot com Operating system: Debian Sarge with 3.6.8 kernel PHP version: 5.1.4 PHP Bug Type: Reproducible crash Bug description: Apache 2.0.55-Openldap 2.3.24-php 5.1.4 causes apache to segfault Description: On a Debian Sarge system with a 2.6.8 kernel I am building Apache 2.0.55 with PHP 5.1.4 with LDAP support. The build seems to complete just fine, but the server will not start. When I do a 'apache/bin/apachectl configtest' I get a Syntax OK message just before I get the SEGFAULT message. When I remove the PHP module load directive from the httpd.conf file the SEGFAULT disappears. I get the same result if I build PHP 4.4.2. I have finally gotten the server to build by building against OpenLDAP 2.2.27. It looks like PHP is having some problem with OpenLDAP 2.3.x? Reproduce code: --- Here is the configuration line that works: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.2.27 Here is the one that fails: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.3.24 Expected result: apachectl configtest Syntax OK Actual result: -- apachectl configtest Syntax OK /usr/local/apache/bin/apachectl: line 100: 5039 Segmentation fault $HTTPD -t -- Edit bug report at http://bugs.php.net/?id=38137&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38137&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38137&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38137&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38137&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38137&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38137&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38137&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38137&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38137&r=support Expected behavior:http://bugs.php.net/fix.php?id=38137&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38137&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38137&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38137&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38137&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38137&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38137&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38137&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38137&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38137&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38137&r=mysqlcfg
#27823 [Com]: __FILE__ still not working properly in includes under Solaris
ID: 27823 Comment by: wrhj at yahoo dot com Reported By: roy at pine dot nl Status: No Feedback Bug Type: Scripting Engine problem Operating System: Solaris 7 PHP Version: 4CVS-2004-04-29 New Comment: yeeah, you guys are right. Previous Comments: [2006-07-05 04:56:54] kwerle at pobox dot com Please see http://bugs.php.net/bug.php?id=34552 for the cause and solution [2005-09-14 23:03:33] mmayer at blastwave dot org It is still happening. I ran into it today, trying to install the newly released Gallery 2. My system is a Sun Ultra 60, running Solaris 9. I also run Apache 2 and PHP 4.4.0. I installed Gallery 2 under ~/public_html (i.e. in my home directory). When I moved it into the docroot of Apache, it started working. I can also reproduce the problem with the two little scripts provided by roy. But only if the scripts are in a subdirectory of /home/markus/public_html. If they are in a subdirectory of the doc-root, everything is fine. [2005-02-11 01:00:07] 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-02-03 05:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-11-18 06:09:28] chiller at orchidsuites dot net Same problem. __FILE__ returns './filename' instead of '/path/to/filename'. MacOS X Server 10.3.6 / PHP 4.3.9 It seems this bug keeps getting reintroduced. IMO __FILE__ should return the full path. 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/27823 -- Edit this bug report at http://bugs.php.net/?id=27823&edit=1
#38136 [NEW]: Order of ./configure options can result in --enable-memory-limit being ignored
From: twells at smarterliving dot com Operating system: RedHat 9 PHP version: 4.4.2 PHP Bug Type: *Compile Issues Bug description: Order of ./configure options can result in --enable-memory-limit being ignored Description: The order of ./configure arguments can result in --enable-memory-limit functionality not being built into the binary. Reproduce code: --- 1) Build PHP with: ./configure --with-mysql=/usr --with-curl --with-gettext --with-mcrypt --with-dom --enable-inline --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-zlib-dir=/usr/lib --with-openssl --enable-ftp --with-apache=../apache_1.3.34 --enable-memcache --enable-mbstring --enable-memory-limit 2) Observe in the configure output that "checking whether to enable a memory limit... yes" 3) Install, make sure memory_limit is set in php.ini and restart apache and load phpinfo(). Observe there is no memory_limit value in the PHP Core output however --enable-memory-limit is listed in the Configure Command output. Test calls to memory_get_usage() will result in a PHP Fatal call to an undefined function. 4) Rebuild PHP with: ./configure --with-mysql=/usr --with-curl --with-gettext --with-mcrypt --with-dom --enable-inline --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-zlib-dir=/usr/lib --with-openssl --enable-ftp --enable-memory-limit --enable-memcache --enable-mbstring --with-apache=../apache_1.3.34 5) Again in the config output you should see: "checking whether to enable a memory limit... yes" 6) Install, restart apache, and load phpinfo(). memory_limit is now visible in the PHP Core output and functions like memory_get_usage() work again Expected result: Both configure lines should result in an identical PHP build Actual result: -- --enable-memory-limit functionality is missing from the build. -- Edit bug report at http://bugs.php.net/?id=38136&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38136&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38136&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38136&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38136&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38136&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38136&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38136&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38136&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38136&r=support Expected behavior:http://bugs.php.net/fix.php?id=38136&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38136&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38136&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38136&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38136&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38136&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38136&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38136&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38136&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38136&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38136&r=mysqlcfg
#38103 [Bgs]: PDO::FETCH_INTO fails w/extraneous param
ID: 38103
User updated by: jeffmlevy+phpbugs at gmail dot com
Reported By: jeffmlevy+phpbugs at gmail dot com
Status: Bogus
Bug Type: PDO related
Operating System: Debian GNU Linux
PHP Version: 5.1.4
Assigned To: wez
New Comment:
sovled:
$stmt = $this->dbh->query("call load($data_id)",, PDO::FETCH_INTO,
$this);
$stmt->fetch();
wez, can I have your baby? rule.
Previous Comments:
[2006-07-17 21:07:42] jeffmlevy+phpbugs at gmail dot com
I wholeheartedly apologize. I meant "fetch()", not fetchAll().
This issue applies to $stmt->fetch(PDO::FETCH_INTO, $this)
Thank you.
[2006-07-14 12:01:08] [EMAIL PROTECTED]
RTM. At no point does it tell you that you can use FETCH_INFO with
fetchAll(). Think about what that means.
[2006-07-14 10:12:39] jeffmlevy+phpbugs at gmail dot com
Description:
Note: Mysql PDO.
PDO fails with error when calling fetchAll() w/PDO::FETCH_INTO.
Implicit call to setFetchMode(PDO::FETCH_INTO, $oObject) passes the
test, however.
Reproduce code:
---
$stmt = $dbh->prepare("call data_loader()");
$stmt->setFetchMode(PDO::FETCH_INTO, $this);
$stmt->fetchAll();
results in proper assignment of return vars to object props.
BUT:
$stmt = $dbh->prepare("call data_loader()");
$stmt->fetchAll(PDO::FETCH_INTO, $this);
calling with $this results in:
PDOStatement::fetchAll(): SQLSTATE[HY000]: General error:
Extraneous additional parameters
calling without $this results in
PDOStatement::fetchAll(): SQLSTATE[HY000]: General error: No
fetch-into object specified.
Expected result:
Expect class properties to be properly populated.
Actual result:
--
Error thrown.
Could be lack of documenatation??
--
Edit this bug report at http://bugs.php.net/?id=38103&edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: cmi at colcenter dot org Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: May be same problem .. 4.2.3 version, WinXP Only IE 5 and IE 5.5 After login, any link on the page to a file with session_start() sets new (empty) session, and therefore am returned to login page. IE 6, Opera and Firefox all work correctly. Adding php_flag session.use_trans_sid on to my htaccess fixes it, but would rather not do that. Previous Comments: [2006-05-20 21:19:24] tony at tuxick dot net same problem on 5.1.2 and 5.1.4. php.ini shows ;default_charset = "iso-8859-1", suggesting it's default. enabling fixed the problem. [2006-05-10 00:40:56] jeroen at haan dot net Changing the character set from utf-8 to the old iso-8859-1 helped. Now a session cookie is succesfully stored on the client and thereby the sessid and thus one file on the server maintained. However I do not understand this behavior. [2006-04-26 07:00:18] sunmt at usa dot com I expereinced the same problem in PHP 5.0.5 Reading\Writing to session works in the same page but the server loses the session when going between different pages or reloading the page. Please help me.. [2006-02-16 21:16:24] optikey at gmail dot com Same problem with 5.0.5 running on Debian x86_64... Only I.E. does this 2 cookies thing and scroolled my code... Digging the net, i found that those bugs started only in the browsers that executes windows update automatically... So i find that the day that the problems started matches the day of the release of one Microsoft Bugfix that affects I.E. 14/feb/2006 Only the updated browsers behave incorrectly Might we need to blame M$ Any workarounds??? Am i right??? MS did not return the bug report... [2006-02-15 17:05:12] bohn at netbuild dot net got same problem under using php 4.3.10 :( on heavy load, php creates a new session... fc3, apache2, php4.3.10, lvs 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#38135 [NEW]: $n backreference not working in pattern
From: msn at t-network dot nl
Operating system: Windows XP SP2 Home Edition
PHP version: 5.1.4
PHP Bug Type: PCRE related
Bug description: $n backreference not working in pattern
Description:
It's not possible to use the $n style backreference in the pattern of the
PCRE functions.
A pattern like this:
/\[(u|b|i|s)\](.*)\[\/$1\]/si
Should match [b]bold[/b]. However, it does not.
This pattern though:
/\[(u|b|i|s)\](.*)\[\/\\1\]/si
_Will_ match [b]bold[/b].
Reproduce code:
---
$2",
$sString);
return ($sString);
}
echo parseUBB("[b]testb[/b], [u]testu[/u], [i]testi[/i]");
?>
Expected result:
testb, testu, testi
Actual result:
--
[b]test[/b], [u]testu[/u], [i]testi[/i]
--
Edit bug report at http://bugs.php.net/?id=38135&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38135&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38135&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38135&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38135&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38135&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38135&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38135&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38135&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38135&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38135&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38135&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38135&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38135&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38135&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38135&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38135&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38135&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38135&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38135&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38135&r=mysqlcfg
#36708 [Fbk->Opn]: PDO Extension fails to configure proper makefile
ID: 36708 User updated by: jerome at macsaresexy dot com Reported By: jerome at macsaresexy dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.5 PHP Version: 5.1.2 Assigned To: wez New Comment: I just grabbed PHP 5.2 CVS 200607181630 snapshot and attempted to compile it, PHP itself compiled fine, but PDO still does not generate a proper makefile on Mac OS X. after running the php5.2cvs's phpize on ext/pdo, i did configure then make, and it just immediately thinks it's done like it always has been doing. Previous Comments: [2006-07-18 15:43:57] [EMAIL PROTECTED] The next snapshot should be ok. Thanks for the alert. [2006-07-18 15:36:05] jerome at macsaresexy dot com I was unable to try cvs since it failed compiling PHP part way through with: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c: In function zend_mm_mem_mmap_realloc: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: ret undeclared (first use in this function) /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: (Each undeclared identifier is reported only once /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: for each function it appears in.) make: *** [Zend/zend_alloc.lo] Error 1 [2006-06-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-06-20 15:27:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-04-11 13:13:33] jerome at macsaresexy dot com weird, so PDO for some reason is the only one that can't be built separately from PHP on OS X? does that include every PDO driver? because that'll be a downer. 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/36708 -- Edit this bug report at http://bugs.php.net/?id=36708&edit=1
#36708 [Opn->Fbk]: PDO Extension fails to configure proper makefile
ID: 36708 Updated by: [EMAIL PROTECTED] Reported By: jerome at macsaresexy dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.4.5 PHP Version: 5.1.2 Assigned To: wez New Comment: The next snapshot should be ok. Thanks for the alert. Previous Comments: [2006-07-18 15:36:05] jerome at macsaresexy dot com I was unable to try cvs since it failed compiling PHP part way through with: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c: In function zend_mm_mem_mmap_realloc: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: ret undeclared (first use in this function) /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: (Each undeclared identifier is reported only once /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: for each function it appears in.) make: *** [Zend/zend_alloc.lo] Error 1 [2006-06-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-06-20 15:27:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-04-11 13:13:33] jerome at macsaresexy dot com weird, so PDO for some reason is the only one that can't be built separately from PHP on OS X? does that include every PDO driver? because that'll be a downer. [2006-04-11 11:13:39] [EMAIL PROTECTED] Apparently it's not supposed to be possible to even build PDO as shared extension under MacOSX. Just these Wez's hacks don't work and won't give any warning about it but just silently fails. Wez: Obviously you don't check properly whether phpize is used.. 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/36708 -- Edit this bug report at http://bugs.php.net/?id=36708&edit=1
#36708 [NoF->Opn]: PDO Extension fails to configure proper makefile
ID: 36708 User updated by: jerome at macsaresexy dot com Reported By: jerome at macsaresexy dot com -Status: No Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.5 PHP Version: 5.1.2 Assigned To: wez New Comment: I was unable to try cvs since it failed compiling PHP part way through with: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c: In function zend_mm_mem_mmap_realloc: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: ret undeclared (first use in this function) /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: (Each undeclared identifier is reported only once /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: for each function it appears in.) make: *** [Zend/zend_alloc.lo] Error 1 Previous Comments: [2006-06-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-06-20 15:27:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-04-11 13:13:33] jerome at macsaresexy dot com weird, so PDO for some reason is the only one that can't be built separately from PHP on OS X? does that include every PDO driver? because that'll be a downer. [2006-04-11 11:13:39] [EMAIL PROTECTED] Apparently it's not supposed to be possible to even build PDO as shared extension under MacOSX. Just these Wez's hacks don't work and won't give any warning about it but just silently fails. Wez: Obviously you don't check properly whether phpize is used.. [2006-04-11 05:18:51] jerome at macsaresexy dot com Ok so that seems more successful now, I was able to make curl, mysql, xsl, libz, gd on OS X which at least a few failed to before with stable 5.1.2 BUT PDO is still failing to generate a proper Makefile. Seems couple things are empty that shouldn't be as far as I can tell in the Makefile PHP_MODULES = all_targets = $(PHP_MODULES) which fails when make all is run since make all just references all targets. but glad to see every other module seems to be compiling so I can make an extension driven install of PHP. 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/36708 -- Edit this bug report at http://bugs.php.net/?id=36708&edit=1
#33744 [Com]: Concerning ini_set session.save_path & reregistering an id under windows.
ID: 33744 Comment by: f dot hardy at origami-systems dot com Reported By: d43m0n at shaw dot ca Status: No Feedback Bug Type: Session related Operating System: win32 & linux PHP Version: 5.0.4 New Comment: Sorry, i have ommited an important informations : I am ussing session_save_path() instead of ini_set(). Previous Comments: [2006-07-18 15:13:55] f dot hardy at origami-systems dot com I have the same issue under windows XP Pro and php 5.1.4. [2005-07-26 01:00:05] 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-07-18 18:43:44] [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 [2005-07-18 11:05:45] d43m0n at shaw dot ca Description: Hello, While developing a new security fix for a script I am working on, I found this issue corrisponding with Windows 2000 NT, which causes the sessions to not reregister a id if the ini_set redefines teh session.save_path to a relitive location. The following code when used in the windows environment will cause the error which follows: [CODE] [/CODE] [ERROR]Warning: Unknown: open(./tmp\sess_3c0fe03c61bac80ca57a1193d3e54aa8, O_RDWR) failed: No such file or directory (2) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (./tmp) in Unknown on line 0 [/ERROR] Of course I have takin the proper precautions to be sure the directory existed in the first place... of course, if I dont re-define the the session.save_path, and use the default, it gets created secessfully, like as follows: [CODE] [/CODE] Now, ill take it another step further, I tried using an exact file location when I defined the session.save_path like so: [CODE] [/CODE] Of course this prooved successful, except for the obvious change of my directory location to my tmp... Now I did have a chance to try out the same script on a Linux OS with PHP and had no troubles with ./tmp as the tmp directory, so like really, wtf is the problem? -- Edit this bug report at http://bugs.php.net/?id=33744&edit=1
#33744 [Com]: Concerning ini_set session.save_path & reregistering an id under windows.
ID: 33744 Comment by: f dot hardy at origami-systems dot com Reported By: d43m0n at shaw dot ca Status: No Feedback Bug Type: Session related Operating System: win32 & linux PHP Version: 5.0.4 New Comment: I have the same issue under windows XP Pro and php 5.1.4. Previous Comments: [2005-07-26 01:00:05] 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-07-18 18:43:44] [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 [2005-07-18 11:05:45] d43m0n at shaw dot ca Description: Hello, While developing a new security fix for a script I am working on, I found this issue corrisponding with Windows 2000 NT, which causes the sessions to not reregister a id if the ini_set redefines teh session.save_path to a relitive location. The following code when used in the windows environment will cause the error which follows: [CODE] [/CODE] [ERROR]Warning: Unknown: open(./tmp\sess_3c0fe03c61bac80ca57a1193d3e54aa8, O_RDWR) failed: No such file or directory (2) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (./tmp) in Unknown on line 0 [/ERROR] Of course I have takin the proper precautions to be sure the directory existed in the first place... of course, if I dont re-define the the session.save_path, and use the default, it gets created secessfully, like as follows: [CODE] [/CODE] Now, ill take it another step further, I tried using an exact file location when I defined the session.save_path like so: [CODE] [/CODE] Of course this prooved successful, except for the obvious change of my directory location to my tmp... Now I did have a chance to try out the same script on a Linux OS with PHP and had no troubles with ./tmp as the tmp directory, so like really, wtf is the problem? -- Edit this bug report at http://bugs.php.net/?id=33744&edit=1
#35510 [Csd]: [PATCH] ext/gmp: gmp_nextprime()
ID: 35510
Updated by: [EMAIL PROTECTED]
Reported By: ants dot aasma at gmail dot com
Status: Closed
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Patch committed to 5_2 branch too.
Previous Comments:
[2006-04-03 19:47:15] [EMAIL PROTECTED]
Thank you for the patch.
Applied to HEAD (aka PHP6).
[2005-12-01 21:46:08] [EMAIL PROTECTED]
reclassified where this belongs.
[2005-12-01 20:13:44] ants dot aasma at gmail dot com
Description:
Add the gmp_nextprime function to ext/gmp. I need it for
my cryptographically secure random number generator and
it's probably pretty useful to others too (espescially
because I can then release my code properly :).
http://www.hot.ee/stepz/Math_Random/gmp.patch is the
(really simple) patch.
Reproduce code:
---
if (function_exists("gmp_nextprime")) {
echo gmp_strval(gmp_nextprime(1000));
} else {
echo "No function";
}
Expected result:
1009
Actual result:
--
No function
--
Edit this bug report at http://bugs.php.net/?id=35510&edit=1
#38134 [Com]: segfault while calling xslt_process
ID: 38134
Comment by: gabriel dot zerbib at protilab dot com
Reported By: gerome dot fournier at infomaniak dot ch
Status: Feedback
Bug Type: XSLT related
Operating System: Debian Sarge
PHP Version: 4.4.2
New Comment:
The same test data (XML & XSL) in same context (same PHP application,
same version) work and do not fail on Windows XP & IIS, whereas I
experience the same problem on submitter's platform.
Previous Comments:
[2006-07-18 14:14:50] [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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-07-18 13:52:27] gerome dot fournier at infomaniak dot ch
Description:
Making a simple xml transformation using xslt_process
gives from time to time a segfault. The php code looks like this:
$xmlFile = "file.xml";
$xsl_url = "file.xsl";
$result = xslt_process($xh, $xmlFile, $xsl_url);
if ($result) {
echo $result;
} else {
echo "Error";
}
xslt_free($xh);
I provide hereafter a backtrace after the segfault occured:
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -120974 (LWP 4068)]
0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
#1 0xb6db9cbf in ssl_io_hook_writev () from
/opt/apache/libexec/libssl.so
#2 0xbf886f40 in ?? ()
#3 0x0002 in ?? ()
#4 0x081228c4 in ?? ()
#5 0x in ?? ()
#6 0x0017 in ?? ()
#7 0x in ?? ()
#8 0x3908 in ?? ()
#9 0x081228c4 in ?? ()
#10 0x in ?? ()
#11 0x080cbd04 in ?? ()
#12 0x0807f4a7 in ap_hook_call_func ()
#13 0xb7979494 in sapi_send_headers () at
/root/SOURCES/php4-debug/php-4.4.2/main/SAPI.c:813
#14 0xb7987c6e in php_ub_body_write_no_header (
str=0x84413b4 "http://www.w3.org/1999/xhtml\";
lang=\"fr\" xml:lang=\"fr\">\n \nProtilab -
gestion\n
#38041 [Opn]: PHP should support 64 bit long integers
ID: 38041 Updated by: [EMAIL PROTECTED] Reported By: shailesh_bavadekar at yahoo dot com Status: Open Bug Type:Feature/Change Request -PHP Version: 5.1.4 +PHP Version: 6* New Comment: This is planned for PHP 6: http://www.php.net/~derick/meeting-notes.html#add-a-64bit-integer Previous Comments: [2006-07-08 21:12:03] shailesh_bavadekar at yahoo dot com Description: PHP should support 64 bit long data type. Currently there are two choices for integer arithmetic - * 32 bit signed integer and * 64 bit float. In some cases the translation between these types is handled automatically but the behavior is not consistent. e.g. integers operands are automatically converted to float, but integers represented as strings are not. The main problem is - even if integers are seamlessly converted to float, that only extends the range to 2^53. So there is really no way to handle integer values between 2^53 and 2^64. gmp extension is an option of course, but it is cumbersome to use. The lack of 64 bit long support causes incorrect behavior elsewhere in the language - e.g. PHP SOAP extension cannot accurately translate xsd:long data type to PHP. -- Edit this bug report at http://bugs.php.net/?id=38041&edit=1
#38134 [Opn->Fbk]: segfault while calling xslt_process
ID: 38134
Updated by: [EMAIL PROTECTED]
Reported By: gerome dot fournier at infomaniak dot ch
-Status: Open
+Status: Feedback
Bug Type: XSLT related
Operating System: Debian Sarge
PHP Version: 4.4.2
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2006-07-18 13:52:27] gerome dot fournier at infomaniak dot ch
Description:
Making a simple xml transformation using xslt_process
gives from time to time a segfault. The php code looks like this:
$xmlFile = "file.xml";
$xsl_url = "file.xsl";
$result = xslt_process($xh, $xmlFile, $xsl_url);
if ($result) {
echo $result;
} else {
echo "Error";
}
xslt_free($xh);
I provide hereafter a backtrace after the segfault occured:
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -120974 (LWP 4068)]
0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
#1 0xb6db9cbf in ssl_io_hook_writev () from
/opt/apache/libexec/libssl.so
#2 0xbf886f40 in ?? ()
#3 0x0002 in ?? ()
#4 0x081228c4 in ?? ()
#5 0x in ?? ()
#6 0x0017 in ?? ()
#7 0x in ?? ()
#8 0x3908 in ?? ()
#9 0x081228c4 in ?? ()
#10 0x in ?? ()
#11 0x080cbd04 in ?? ()
#12 0x0807f4a7 in ap_hook_call_func ()
#13 0xb7979494 in sapi_send_headers () at
/root/SOURCES/php4-debug/php-4.4.2/main/SAPI.c:813
#14 0xb7987c6e in php_ub_body_write_no_header (
str=0x84413b4 "http://www.w3.org/1999/xhtml\";
lang=\"fr\" xml:lang=\"fr\">\n \nProtilab -
gestion\n
#38134 [NEW]: segfault while calling xslt_process
From: gerome dot fournier at infomaniak dot ch
Operating system: Debian Sarge
PHP version: 4.4.2
PHP Bug Type: XSLT related
Bug description: segfault while calling xslt_process
Description:
Making a simple xml transformation using xslt_process
gives from time to time a segfault. The php code looks like this:
$xmlFile = "file.xml";
$xsl_url = "file.xsl";
$result = xslt_process($xh, $xmlFile, $xsl_url);
if ($result) {
echo $result;
} else {
echo "Error";
}
xslt_free($xh);
I provide hereafter a backtrace after the segfault occured:
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -120974 (LWP 4068)]
0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
#1 0xb6db9cbf in ssl_io_hook_writev () from
/opt/apache/libexec/libssl.so
#2 0xbf886f40 in ?? ()
#3 0x0002 in ?? ()
#4 0x081228c4 in ?? ()
#5 0x in ?? ()
#6 0x0017 in ?? ()
#7 0x in ?? ()
#8 0x3908 in ?? ()
#9 0x081228c4 in ?? ()
#10 0x in ?? ()
#11 0x080cbd04 in ?? ()
#12 0x0807f4a7 in ap_hook_call_func ()
#13 0xb7979494 in sapi_send_headers () at
/root/SOURCES/php4-debug/php-4.4.2/main/SAPI.c:813
#14 0xb7987c6e in php_ub_body_write_no_header (
str=0x84413b4 "http://www.w3.org/1999/xhtml\";
lang=\"fr\" xml:lang=\"fr\">\n \nProtilab -
gestion\n
#38133 [Opn->Fbk]: PHP won't install offline.Internet Explorer won't load *.php files
ID: 38133 Updated by: [EMAIL PROTECTED] Reported By: leonedwards25 at hotmail dot com -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.1.4 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2006-07-18 13:29:12] leonedwards25 at hotmail dot com Description: I have not managed to successfully install PHP. My laptop is offline with TCP/IP services installed but PHP won't install properly.Apache installs ok but when I try to load phpinfo(); the browser can't find the page. When I try to open *.php files a message is displayed which says the file is an invalid win32 application. Reproduce code: --- Expected result: the browser should display the php/apache/ODBC configuration details. Actual result: -- Page could not be found error message in internet explorer. -- Edit this bug report at http://bugs.php.net/?id=38133&edit=1
#38133 [NEW]: PHP won't install offline.Internet Explorer won't load *.php files
From: leonedwards25 at hotmail dot com Operating system: Windows XP PHP version: 5.1.4 PHP Bug Type: *General Issues Bug description: PHP won't install offline.Internet Explorer won't load *.php files Description: I have not managed to successfully install PHP. My laptop is offline with TCP/IP services installed but PHP won't install properly.Apache installs ok but when I try to load phpinfo(); the browser can't find the page. When I try to open *.php files a message is displayed which says the file is an invalid win32 application. Reproduce code: --- Expected result: the browser should display the php/apache/ODBC configuration details. Actual result: -- Page could not be found error message in internet explorer. -- Edit bug report at http://bugs.php.net/?id=38133&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38133&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38133&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38133&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38133&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38133&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38133&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38133&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38133&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38133&r=support Expected behavior:http://bugs.php.net/fix.php?id=38133&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38133&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38133&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38133&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38133&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38133&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38133&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38133&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38133&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38133&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38133&r=mysqlcfg
#38132 [Opn->Fbk]: static property names in ext/reflection are prefixed with \0*\0
ID: 38132 Updated by: [EMAIL PROTECTED] Reported By: php dot net at benjamin dot schulz dot name -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: linux PHP Version: 5.1.4 Assigned To: johannes 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: [2006-07-18 11:31:24] php dot net at benjamin dot schulz dot name Description: the array keys of protected properties in the array ReflectionClass::getStaticProperties gives are prefixed with "\0*\0" and therefore not accessible as "*propertyName" Reproduce code: --- getStaticProperties(); var_dump(isset($properties['*bar'])); // false var_dump(isset($properties["\0*\0bar"])); // true ?> Expected result: true / false Actual result: -- false / true -- Edit this bug report at http://bugs.php.net/?id=38132&edit=1
#38124 [Opn->Fbk]: FATAL: erealloc(): Unable to allocate xxx bytes
ID: 38124 Updated by: [EMAIL PROTECTED] Reported By: boing at boing dot com -Status: Open +Status: Feedback Bug Type: DOM XML related Operating System: openbsd 3.8 PHP Version: 5.1.4 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: [2006-07-18 10:51:44] boing at boing dot com Honestly, I trimmed it down as much as possible. Most of the file is the data it operates on. Some big, ugly (yes, that's redundant :) ) xml file. You should see the original code. Lot's more trash in there. Honest. :) I think the realloc() failure has something to do with the length of the file and building the sufficiently complex nested associative array uglyness. Geff [2006-07-18 10:23:46] [EMAIL PROTECTED] >I put the reproduce code in the original bug report Yes, I saw it. Please try to make is as smaller as you can. Currently it's just HUGE, that's why asked for a short and complete script which is max 20 lines long. Please also try the latest 5.2 snapshot which you can grab at http://snaps.php.net (wait for the next one, there was a major change in the memory manager recently). [2006-07-18 09:55:01] boing at boing dot com [EMAIL PROTECTED], I put the reproduce code in the original bug report. THe files are still on my website. In addition, I don't think it's DOM XML related. My money WAS on xml_parse in the beginning, but no longer. I think it's on the associative arrays. :) reproduce code again... download: http://www.boing.com/phptest.tgz inside there is a phptest.php and a datafile. php phptest.php on openbsd 3.8 will yield the failture to realloc. I tried it on gentoo with successful results. Geff [2006-07-18 06:45:24] [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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-07-17 21:35:46] boing at boing dot com This is going to sound dumb, but does php have a limit on the size of an associative array? Or the number of multi-dimensional associative arrays that are part of one variable? I've googled for these types of things with no results. 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/38124 -- Edit this bug report at http://bugs.php.net/?id=38124&edit=1
#38117 [Opn->Bgs]: php 5.1.2 dom object preserveWhiteSpace
ID: 38117 Updated by: [EMAIL PROTECTED] Reported By: protano at wp dot pl -Status: Open +Status: Bogus Bug Type: DOM XML related Operating System: windows PHP Version: 5.1.4 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 preserveWhiteSpace has no effect using loadHTML() - only XML load methods - so behavior is due to different libxml2 versions (looks like behavior was fixed with newer version) Previous Comments: [2006-07-18 07:45:56] protano at wp dot pl // *** WINDOWS with error ***/ DOM/XML enabled DOM/XML API Version 20031129 libxml Version 2.6.22 HTML Supportenabled XPath Support enabled XPointer Supportenabled Schema Support enabled RelaxNG Support enabled // *** // // *** LINUX works fine *** // DOM/XML enabled DOM/XML API Version 20031129 libxml Version 2.6.16 HTML Supportenabled XPath Support enabled XPointer Supportenabled Schema Support enabled RelaxNG Support enabled // // [2006-07-17 07:07:23] [EMAIL PROTECTED] Are you using the same libxml2 versions on both systems? Maybe that's the reason... [2006-07-17 06:34:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-07-16 22:43:10] protano at wp dot pl Description: In windows version 5.1.2 php dom->preserveWhiteSpace = false; does not act correctly. So as this option would not be put. In PHP Version 5.0.5-Debian-0.8~sarge1 it works correctly. Reproduce code: --- $doc = new DOMDocument; $doc->preserveWhiteSpace = false; $doc->loadHTML($buffer); $xpath = new DOMXPath($doc); $query = '//html/body/td/b'; $entries = $xpath->query($query); $data=$entries->item(1)->nodeValue; Expected result: whitespaces between tags(xml elements) should be ignored. Actual result: -- whitespaces between tags(xml elements) are't ignore. -- Edit this bug report at http://bugs.php.net/?id=38117&edit=1
#38132 [NEW]: static property names in ext/reflection are prefixed with \0*\0
From: php dot net at benjamin dot schulz dot name Operating system: linux PHP version: 5.1.4 PHP Bug Type: Unknown/Other Function Bug description: static property names in ext/reflection are prefixed with \0*\0 Description: the array keys of protected properties in the array ReflectionClass::getStaticProperties gives are prefixed with "\0*\0" and therefore not accessible as "*propertyName" Reproduce code: --- getStaticProperties(); var_dump(isset($properties['*bar'])); // false var_dump(isset($properties["\0*\0bar"])); // true ?> Expected result: true / false Actual result: -- false / true -- Edit bug report at http://bugs.php.net/?id=38132&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38132&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38132&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38132&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38132&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38132&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38132&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38132&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38132&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38132&r=support Expected behavior:http://bugs.php.net/fix.php?id=38132&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38132&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38132&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38132&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38132&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38132&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38132&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38132&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38132&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38132&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38132&r=mysqlcfg
#38124 [Fbk->Opn]: FATAL: erealloc(): Unable to allocate xxx bytes
ID: 38124 User updated by: boing at boing dot com Reported By: boing at boing dot com -Status: Feedback +Status: Open Bug Type: DOM XML related Operating System: openbsd 3.8 PHP Version: 5.1.4 New Comment: Honestly, I trimmed it down as much as possible. Most of the file is the data it operates on. Some big, ugly (yes, that's redundant :) ) xml file. You should see the original code. Lot's more trash in there. Honest. :) I think the realloc() failure has something to do with the length of the file and building the sufficiently complex nested associative array uglyness. Geff Previous Comments: [2006-07-18 10:23:46] [EMAIL PROTECTED] >I put the reproduce code in the original bug report Yes, I saw it. Please try to make is as smaller as you can. Currently it's just HUGE, that's why asked for a short and complete script which is max 20 lines long. Please also try the latest 5.2 snapshot which you can grab at http://snaps.php.net (wait for the next one, there was a major change in the memory manager recently). [2006-07-18 09:55:01] boing at boing dot com [EMAIL PROTECTED], I put the reproduce code in the original bug report. THe files are still on my website. In addition, I don't think it's DOM XML related. My money WAS on xml_parse in the beginning, but no longer. I think it's on the associative arrays. :) reproduce code again... download: http://www.boing.com/phptest.tgz inside there is a phptest.php and a datafile. php phptest.php on openbsd 3.8 will yield the failture to realloc. I tried it on gentoo with successful results. Geff [2006-07-18 06:45:24] [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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-07-17 21:35:46] boing at boing dot com This is going to sound dumb, but does php have a limit on the size of an associative array? Or the number of multi-dimensional associative arrays that are part of one variable? I've googled for these types of things with no results. [2006-07-17 21:22:50] boing at boing dot com Thanks for the speedy response! I tried in linux also, works well in gentoo, not in openbsd. :( But openbsd has some weird stuff going on: propolice, etc. Windows has marks on it where I've been touchin in with the 10 foot poll. course the usual bsd analities result in the linking stage: main/.libs/php_sprintf.o(.text+0x24): In function `php_sprintf': /usr/local/src/php5.2-200607172030/main/php_sprintf.c:38: warning: vsprintf() is often misused, please use vsnprintf() ext/pdo/.libs/pdo_dbh.o(.text+0x37): In function `pdo_raise_impl_error': /usr/local/src/php5.2-200607172030/ext/pdo/pdo_dbh.c:60: warning: strcpy() is almost always misused, please use strlcpy() ext/sqlite/libsqlite/src/.libs/btree.o(.text+0x46ba): In function `checkRef': /usr/local/src/php5.2-200607172030/ext/sqlite/libsqlite/src/btree.c:3201: warning: sprintf() is often misused, please use snprintf() ext/mysql/.libs/php_mysql.o(.text+0x5007): In function `php_mysql_field_info': /usr/local/src/php5.2-200607172030/ext/mysql/php_mysql.c:2418: warning: strcat() is almost always misused, please use strlcat() script results w/ php5.2-200607172030: (same thing, slightly different byte count, of course) kusanagi:/usr/local/apache2/htdocs)unlimit kusanagi:/usr/local/apache2/htdocs)limit cputime unlimited filesize unlimited datasize 262144 kbytes stacksize32768 kbytes coredumpsize unlimited memoryuse392364 kbytes descriptors 1024 memorylocked 392364 kbytes maxproc 512 kusanagi:/usr/local/apache2/htdocs)ls -la typo3temp/extensions.xml.gz -rw-r--r-- 1 boing wheel 599305 Jul 17 02:32 typo3temp/extensions.xml.gz kusanagi:/usr/local/apache2/htdocs)/usr/local/php52/bin/php phptest.php start handler new handler parsing.. The extensions list has been updated and now contains 1777 extension entries. saving... FATAL: erealloc(): Unable to allocate 3346466 bytes 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/38124 -- Edit this bug report at http://bugs.php.net/?id=38124&edit=1
#38131 [Opn->Bgs]: Upgrading from 5.1.2 to 5.1.4 crashes IIS periodically
ID: 38131 Updated by: [EMAIL PROTECTED] Reported By: michael at onlinecity dot dk -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 x64 SP1 PHP Version: 5.1.4 New Comment: We are aware of PHP's problems with stability under IIS and are working to rectify the problem. Unfortunatly your bug report does not contain any extra useful information and we already have enough bug reports open about this issue. If you can provide more detailed information such as a reproducable crash or a backtrace please do so and reopen this bug. Otherwise please keep trying new releases as we are working to resolve the problems on this platform Thanks for your interest in PHP. Previous Comments: [2006-07-18 10:37:47] michael at onlinecity dot dk Description: This occurs in Event Viewer in the Application log: Faulting application php.exe, version 5.1.4.4, faulting module unknown, version 0.0.0.0, fault address 0x027f1c90. Followed by each Application Pool using php crashing I am using Zend Optimizer 3.0 and IIS is running in 32 bit compatibility mode. These are my loaded extensions: extension=php_mbstring.dll extension=php_bz2.dll extension=php_curl.dll extension=php_exif.dll extension=php_gd2.dll extension=php_gettext.dll extension=php_imap.dll extension=php_ldap.dll extension=php_mcrypt.dll extension=php_mhash.dll extension=php_mssql.dll extension=php_mysql.dll extension=php_openssl.dll extension=php_pgsql.dll extension=php_sockets.dll extension=php_tidy.dll extension=php_xmlrpc.dll extension=php_xsl.dll extension=php_fileinfo.dll extension=php_zip.dll extension=php_mysqli.dll extension=php_pdo.dll extension=php_soap.dll extension=php_gzip.dll -- Edit this bug report at http://bugs.php.net/?id=38131&edit=1
#38131 [NEW]: Upgrading from 5.1.2 to 5.1.4 crashes IIS periodically
From: michael at onlinecity dot dk Operating system: Windows Server 2003 x64 SP1 PHP version: 5.1.4 PHP Bug Type: IIS related Bug description: Upgrading from 5.1.2 to 5.1.4 crashes IIS periodically Description: This occurs in Event Viewer in the Application log: Faulting application php.exe, version 5.1.4.4, faulting module unknown, version 0.0.0.0, fault address 0x027f1c90. Followed by each Application Pool using php crashing I am using Zend Optimizer 3.0 and IIS is running in 32 bit compatibility mode. These are my loaded extensions: extension=php_mbstring.dll extension=php_bz2.dll extension=php_curl.dll extension=php_exif.dll extension=php_gd2.dll extension=php_gettext.dll extension=php_imap.dll extension=php_ldap.dll extension=php_mcrypt.dll extension=php_mhash.dll extension=php_mssql.dll extension=php_mysql.dll extension=php_openssl.dll extension=php_pgsql.dll extension=php_sockets.dll extension=php_tidy.dll extension=php_xmlrpc.dll extension=php_xsl.dll extension=php_fileinfo.dll extension=php_zip.dll extension=php_mysqli.dll extension=php_pdo.dll extension=php_soap.dll extension=php_gzip.dll -- Edit bug report at http://bugs.php.net/?id=38131&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38131&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38131&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38131&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38131&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38131&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38131&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38131&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38131&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38131&r=support Expected behavior:http://bugs.php.net/fix.php?id=38131&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38131&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38131&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38131&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38131&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38131&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38131&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38131&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38131&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38131&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38131&r=mysqlcfg
#38124 [Opn->Fbk]: FATAL: erealloc(): Unable to allocate xxx bytes
ID: 38124 Updated by: [EMAIL PROTECTED] Reported By: boing at boing dot com -Status: Open +Status: Feedback Bug Type: DOM XML related Operating System: openbsd 3.8 PHP Version: 5.1.4 New Comment: >I put the reproduce code in the original bug report Yes, I saw it. Please try to make is as smaller as you can. Currently it's just HUGE, that's why asked for a short and complete script which is max 20 lines long. Please also try the latest 5.2 snapshot which you can grab at http://snaps.php.net (wait for the next one, there was a major change in the memory manager recently). Previous Comments: [2006-07-18 09:55:01] boing at boing dot com [EMAIL PROTECTED], I put the reproduce code in the original bug report. THe files are still on my website. In addition, I don't think it's DOM XML related. My money WAS on xml_parse in the beginning, but no longer. I think it's on the associative arrays. :) reproduce code again... download: http://www.boing.com/phptest.tgz inside there is a phptest.php and a datafile. php phptest.php on openbsd 3.8 will yield the failture to realloc. I tried it on gentoo with successful results. Geff [2006-07-18 06:45:24] [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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-07-17 21:35:46] boing at boing dot com This is going to sound dumb, but does php have a limit on the size of an associative array? Or the number of multi-dimensional associative arrays that are part of one variable? I've googled for these types of things with no results. [2006-07-17 21:22:50] boing at boing dot com Thanks for the speedy response! I tried in linux also, works well in gentoo, not in openbsd. :( But openbsd has some weird stuff going on: propolice, etc. Windows has marks on it where I've been touchin in with the 10 foot poll. course the usual bsd analities result in the linking stage: main/.libs/php_sprintf.o(.text+0x24): In function `php_sprintf': /usr/local/src/php5.2-200607172030/main/php_sprintf.c:38: warning: vsprintf() is often misused, please use vsnprintf() ext/pdo/.libs/pdo_dbh.o(.text+0x37): In function `pdo_raise_impl_error': /usr/local/src/php5.2-200607172030/ext/pdo/pdo_dbh.c:60: warning: strcpy() is almost always misused, please use strlcpy() ext/sqlite/libsqlite/src/.libs/btree.o(.text+0x46ba): In function `checkRef': /usr/local/src/php5.2-200607172030/ext/sqlite/libsqlite/src/btree.c:3201: warning: sprintf() is often misused, please use snprintf() ext/mysql/.libs/php_mysql.o(.text+0x5007): In function `php_mysql_field_info': /usr/local/src/php5.2-200607172030/ext/mysql/php_mysql.c:2418: warning: strcat() is almost always misused, please use strlcat() script results w/ php5.2-200607172030: (same thing, slightly different byte count, of course) kusanagi:/usr/local/apache2/htdocs)unlimit kusanagi:/usr/local/apache2/htdocs)limit cputime unlimited filesize unlimited datasize 262144 kbytes stacksize32768 kbytes coredumpsize unlimited memoryuse392364 kbytes descriptors 1024 memorylocked 392364 kbytes maxproc 512 kusanagi:/usr/local/apache2/htdocs)ls -la typo3temp/extensions.xml.gz -rw-r--r-- 1 boing wheel 599305 Jul 17 02:32 typo3temp/extensions.xml.gz kusanagi:/usr/local/apache2/htdocs)/usr/local/php52/bin/php phptest.php start handler new handler parsing.. The extensions list has been updated and now contains 1777 extension entries. saving... FATAL: erealloc(): Unable to allocate 3346466 bytes [2006-07-17 20:01:49] [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 Works fine here (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/38124 -- Edit this bug report at http://bugs.php.net/?id=38124&edit=1
#38124 [Fbk->Opn]: FATAL: erealloc(): Unable to allocate xxx bytes
ID: 38124 User updated by: boing at boing dot com Reported By: boing at boing dot com -Status: Feedback +Status: Open Bug Type: DOM XML related Operating System: openbsd 3.8 PHP Version: 5.1.4 New Comment: [EMAIL PROTECTED], I put the reproduce code in the original bug report. THe files are still on my website. In addition, I don't think it's DOM XML related. My money WAS on xml_parse in the beginning, but no longer. I think it's on the associative arrays. :) reproduce code again... download: http://www.boing.com/phptest.tgz inside there is a phptest.php and a datafile. php phptest.php on openbsd 3.8 will yield the failture to realloc. I tried it on gentoo with successful results. Geff Previous Comments: [2006-07-18 06:45:24] [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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-07-17 21:35:46] boing at boing dot com This is going to sound dumb, but does php have a limit on the size of an associative array? Or the number of multi-dimensional associative arrays that are part of one variable? I've googled for these types of things with no results. [2006-07-17 21:22:50] boing at boing dot com Thanks for the speedy response! I tried in linux also, works well in gentoo, not in openbsd. :( But openbsd has some weird stuff going on: propolice, etc. Windows has marks on it where I've been touchin in with the 10 foot poll. course the usual bsd analities result in the linking stage: main/.libs/php_sprintf.o(.text+0x24): In function `php_sprintf': /usr/local/src/php5.2-200607172030/main/php_sprintf.c:38: warning: vsprintf() is often misused, please use vsnprintf() ext/pdo/.libs/pdo_dbh.o(.text+0x37): In function `pdo_raise_impl_error': /usr/local/src/php5.2-200607172030/ext/pdo/pdo_dbh.c:60: warning: strcpy() is almost always misused, please use strlcpy() ext/sqlite/libsqlite/src/.libs/btree.o(.text+0x46ba): In function `checkRef': /usr/local/src/php5.2-200607172030/ext/sqlite/libsqlite/src/btree.c:3201: warning: sprintf() is often misused, please use snprintf() ext/mysql/.libs/php_mysql.o(.text+0x5007): In function `php_mysql_field_info': /usr/local/src/php5.2-200607172030/ext/mysql/php_mysql.c:2418: warning: strcat() is almost always misused, please use strlcat() script results w/ php5.2-200607172030: (same thing, slightly different byte count, of course) kusanagi:/usr/local/apache2/htdocs)unlimit kusanagi:/usr/local/apache2/htdocs)limit cputime unlimited filesize unlimited datasize 262144 kbytes stacksize32768 kbytes coredumpsize unlimited memoryuse392364 kbytes descriptors 1024 memorylocked 392364 kbytes maxproc 512 kusanagi:/usr/local/apache2/htdocs)ls -la typo3temp/extensions.xml.gz -rw-r--r-- 1 boing wheel 599305 Jul 17 02:32 typo3temp/extensions.xml.gz kusanagi:/usr/local/apache2/htdocs)/usr/local/php52/bin/php phptest.php start handler new handler parsing.. The extensions list has been updated and now contains 1777 extension entries. saving... FATAL: erealloc(): Unable to allocate 3346466 bytes [2006-07-17 20:01:49] [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 Works fine here (Linux). [2006-07-17 13:02:48] boing at boing dot com BTW - openbsd 3.8 package of php 5.0.4 exhibits the same behavior. package name: php5-core-5.0.4p0 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/38124 -- Edit this bug report at http://bugs.php.net/?id=38124&edit=1
#38129 [NEW]: Configure fails when using IBM's V2.0 webserver
From: j dot lammerts at chello dot nl Operating system: AIX 5 PHP version: 5.1.4 PHP Bug Type: Feature/Change Request Bug description: Configure fails when using IBM's V2.0 webserver Description: Normally, when IBMIHS v 2.0(.47.1) is installed, the systemwide variable LIBPATH is NOT changed. Somewhere in the ./configure stage, the version of the webserver is tested (httpd -v). On AIX, when LIBPATH is not set, this fails Reproduce code: --- Calling httpd -v with the LIBPATH variable NOT set to the installationpath of IBMIHS/lib, produces this error : exec(): 0509-036 Cannot load program /usr/IBMIHS/bin/httpd because of the following errors : 0509-150 Dependent module libaprutil-0.so could not be loaded. 0509-022 Cannot load module libaprutil-0.so. 0509-026 System error: A file or directory in the path name does not exist. This error causes the configure script to fail horribly... Expected result: The expected result can be obtained by setting the LIBPATH variable before starting the configure script : export LIBPATH=$LIBPATH:/usr/IBMIHS/lib (or set it to wherever the lib directory for this instance of the webserver is located) (test by calling /usr/IBMIHS/bin/httpd -v) Maybe a check for a correct result of the call httpd -v can be incorporated in the configure script. It took me weeks to figure this one out ! -- Edit bug report at http://bugs.php.net/?id=38129&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38129&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38129&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38129&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38129&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38129&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38129&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38129&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38129&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38129&r=support Expected behavior:http://bugs.php.net/fix.php?id=38129&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38129&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38129&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38129&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38129&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38129&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38129&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38129&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38129&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38129&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38129&r=mysqlcfg
#38117 [Fbk->Opn]: php 5.1.2 dom object preserveWhiteSpace
ID: 38117 User updated by: protano at wp dot pl Reported By: protano at wp dot pl -Status: Feedback +Status: Open Bug Type: DOM XML related Operating System: windows PHP Version: 5.1.4 New Comment: // *** WINDOWS with error ***/ DOM/XML enabled DOM/XML API Version 20031129 libxml Version 2.6.22 HTML Supportenabled XPath Support enabled XPointer Supportenabled Schema Support enabled RelaxNG Support enabled // *** // // *** LINUX works fine *** // DOM/XML enabled DOM/XML API Version 20031129 libxml Version 2.6.16 HTML Supportenabled XPath Support enabled XPointer Supportenabled Schema Support enabled RelaxNG Support enabled // // Previous Comments: [2006-07-17 07:07:23] [EMAIL PROTECTED] Are you using the same libxml2 versions on both systems? Maybe that's the reason... [2006-07-17 06:34:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-07-16 22:43:10] protano at wp dot pl Description: In windows version 5.1.2 php dom->preserveWhiteSpace = false; does not act correctly. So as this option would not be put. In PHP Version 5.0.5-Debian-0.8~sarge1 it works correctly. Reproduce code: --- $doc = new DOMDocument; $doc->preserveWhiteSpace = false; $doc->loadHTML($buffer); $xpath = new DOMXPath($doc); $query = '//html/body/td/b'; $entries = $xpath->query($query); $data=$entries->item(1)->nodeValue; Expected result: whitespaces between tags(xml elements) should be ignored. Actual result: -- whitespaces between tags(xml elements) are't ignore. -- Edit this bug report at http://bugs.php.net/?id=38117&edit=1
