#32168 [Fbk->Opn]: A recovering of variable while using reference to $_SESSION
ID: 32168
User updated by: KRomas at goldentele dot com
Reported By: KRomas at goldentele dot com
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 4.3.10
New Comment:
For now PHP Version is 4.3.11-dev (Linux) and there is the same error:
array(1) {
["a"]=>
&array(1) {
["b"]=>
int(1)
}
}
Win-version work perfectly however:
array(1) {
["a"]=>
NULL
}
Previous Comments:
[2005-03-07 00:40:28] [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
[2005-03-04 14:42:33] KRomas at goldentele dot com
Sorry, Win-version 4.3.10 hasn't this bug, but Linux-version 4.3.10!
[2005-03-03 12:30:16] KRomas at goldentele dot com
There is a result for 3-rd file
[2005-03-03 11:42:53] KRomas at goldentele dot com
Description:
If we erase the $_SESSION and then make the reference to some session
variable X, the value of X is recovering, ie not erased.
Configure Command:
./configure' '--prefix=/usr/local/apache'
'--with-config-file-path=/usr/local/Zend/etc' '--enable-track-vars'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-gd'
'--with-oci8=/oracle/8.1.7' '--enable-trans-sid' '--enable-sigchild'
'--with-zlib' '--enable-sockets' '--with-zlib-dir=/usr/local/include'
'--with-iconv' '--with-iconv-dir=/usr/local' '--disable-debug'
'--with-sybase-ct=/usr/local/freetds'
Reproduce code:
---
Please run folow files in order:
1.php
';
var_dump($_SESSION);
?>
2.php
';
var_dump($_SESSION);
?>
3.php
';
var_dump($_SESSION);
?>
Expected result:
array(1) {
["a"]=>
&NULL
}
Actual result:
--
array(1) {
["a"]=>
&array(1) {
["b"]=>
int(1)
}
}
--
Edit this bug report at http://bugs.php.net/?id=32168&edit=1
#32245 [NEW]: xml_parser_free() in a function assigned to the xml parser gives a segfault
From: MageOfChrisz at Gmail dot com Operating system: Linux 2.6.10 PHP version: 5.0.3 PHP Bug Type: XML related Bug description: xml_parser_free() in a function assigned to the xml parser gives a segfault Description: (Most of what I say here can be found at http://chrisallan.info/segfault/) When putting "xml_parser_free" in a function assigned to the XML parser with xml_set_element_handler, Apache/PHP Gives a Segmentation Fault. The only browser that you can feasibly see it blow up, would be in lynx. In FireFox, if you're at www.google.com and type in the link to the file (http://chrisallan.info/segfault/function_example.php) it will still show google.com and fail to load the new page. A similar result occurs with Internet Explorer, but in Lynx it'll say: "Alert!: Unexpected Network read error; connection aborted;" I made a PHP5.0.4-dev build (as of Mar 09, 2005 05:30 GMT) from snaps.php.net. This was originally discovered in PHP 5.0.3, and then tested in PHP5.0.4-dev Reproduce code: --- You can find the code (neatly) here: http://chrisallan.info/segfault/ Expected result: Some sort of error telling me not to do what I was doing (due to lack of sleep) or the xml resource actually being freed Actual result: -- Segmentation Fault -- Edit bug report at http://bugs.php.net/?id=32245&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32245&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32245&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32245&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32245&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32245&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32245&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32245&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32245&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32245&r=support Expected behavior: http://bugs.php.net/fix.php?id=32245&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32245&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32245&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32245&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32245&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32245&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32245&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32245&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32245&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32245&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32245&r=mysqlcfg
#32244 [Opn]: enabled iconv extension but got "undefined function iconv()" error
ID: 32244
User updated by: wellswang at auo dot com
Reported By: wellswang at auo dot com
Status: Open
Bug Type: ICONV related
Operating System: FreeBSD 5.3
PHP Version: 5.0.3
New Comment:
i found my problem is same as Bug #12443
but my php version is 5.0.3
i don't know how to solve it
i use his script to check :
";
} else {
echo "iconv_get_encoding is not declared";
}
if ($exists_iconv == TRUE) {
echo "iconv is declared";
} else {
echo "iconv is not declared";
}
$test_string = "this is an ascii-only test string";
echo "test_string is: $test_string";
$encoding = iconv_get_encoding($test_string);
echo "encoding is: $encoding";
$result = iconv($encoding,'UTF-8',$test_string);
echo "result is: $result";
?>
and got the same result as Bug #12443:
iconv_get_encoding is declared
iconv is not declared
test_string is: this is an ascii-only test string
encoding is:
Fatal error: Call to undefined function iconv() in
/http/document/root_osa/temp/foo.php on line 24
Previous Comments:
[2005-03-09 07:15:43] wellswang at auo dot com
Description:
enabled iconv extension but got "undefined function iconv()" error
I build php5.0.3 on my freebsd 5.3 box,
My configure command is:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--with-bz2' '--enable-calendar' '--with-zlib' '--enable-ftp'
'--with-gd' '--enable-mbstring' '--with-mysql=/usr/local'
'--with-mysqli' '--enable-sqlite-utf8' '--enable-libxml'
'--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php'
'--with-apxs2=/usr/local/sbin/apxs' '--prefix=/usr/local'
'i386-portbld-freebsd5.3' '--with-xmlrpc'
'--with-iconv-dir=/usr/local/lib'
It say's configured without error:
.
checking for iconv support... yes
checking for iconv... (cached) yes
checking if iconv is glibc's... no
checking if iconv supports errno... no
.
checking whether libxml build works... (cached) yes
checking for XMLRPC-EPI support... yes
checking libexpat dir for XMLRPC-EPI... no
checking iconv dir for XMLRPC-EPI... /usr/local/lib
checking for libiconv in -liconv... (cached) yes
.
By using php -i or phpinfo() ,i got :
iconv
iconv support => enabled
iconv implementation => unknown
iconv library version => unknown
Directive => Local Value => Master Value
iconv.input_encoding => ISO-8859-1 => ISO-8859-1
iconv.internal_encoding => ISO-8859-1 => ISO-8859-1
iconv.output_encoding => ISO-8859-1 => ISO-8859-1
I donot know the meaning of "unknown"
but iconv support is enabled ?!
==
When I use iconv() in my php program,
I got error message such as :
Fatal error: Call to undefined function iconv() in
/http/document/root_osa/classes/blog_function.php on line 683
is it a php bug or my config problem ?
Reproduce code:
---
configure command :
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--with-bz2' '--enable-calendar' '--with-zlib' '--enable-ftp'
'--with-gd' '--enable-mbstring' '--with-mysql=/usr/local'
'--with-mysqli' '--enable-sqlite-utf8' '--enable-libxml'
'--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php'
'--with-apxs2=/usr/local/sbin/apxs' '--prefix=/usr/local'
'i386-portbld-freebsd5.3' '--with-xmlrpc'
'--with-iconv-dir=/usr/local/lib'
in php file:
Expected result:
This is a test.
Actual result:
--
Fatal error: Call to undefined function iconv() in
/http/document/root_osa/test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=32244&edit=1
#32244 [NEW]: enabled iconv extension but got "undefined function iconv()" error
From: wellswang at auo dot com Operating system: FreeBSD 5.3 PHP version: 5.0.3 PHP Bug Type: ICONV related Bug description: enabled iconv extension but got "undefined function iconv()" error Description: enabled iconv extension but got "undefined function iconv()" error I build php5.0.3 on my freebsd 5.3 box, My configure command is: './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--with-bz2' '--enable-calendar' '--with-zlib' '--enable-ftp' '--with-gd' '--enable-mbstring' '--with-mysql=/usr/local' '--with-mysqli' '--enable-sqlite-utf8' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--with-apxs2=/usr/local/sbin/apxs' '--prefix=/usr/local' 'i386-portbld-freebsd5.3' '--with-xmlrpc' '--with-iconv-dir=/usr/local/lib' It say's configured without error: . checking for iconv support... yes checking for iconv... (cached) yes checking if iconv is glibc's... no checking if iconv supports errno... no . checking whether libxml build works... (cached) yes checking for XMLRPC-EPI support... yes checking libexpat dir for XMLRPC-EPI... no checking iconv dir for XMLRPC-EPI... /usr/local/lib checking for libiconv in -liconv... (cached) yes . By using php -i or phpinfo() ,i got : iconv iconv support => enabled iconv implementation => unknown iconv library version => unknown Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 I donot know the meaning of "unknown" but iconv support is enabled ?! == When I use iconv() in my php program, I got error message such as : Fatal error: Call to undefined function iconv() in /http/document/root_osa/classes/blog_function.php on line 683 is it a php bug or my config problem ? Reproduce code: --- configure command : './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--with-bz2' '--enable-calendar' '--with-zlib' '--enable-ftp' '--with-gd' '--enable-mbstring' '--with-mysql=/usr/local' '--with-mysqli' '--enable-sqlite-utf8' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--with-apxs2=/usr/local/sbin/apxs' '--prefix=/usr/local' 'i386-portbld-freebsd5.3' '--with-xmlrpc' '--with-iconv-dir=/usr/local/lib' in php file: Expected result: This is a test. Actual result: -- Fatal error: Call to undefined function iconv() in /http/document/root_osa/test.php on line 2 -- Edit bug report at http://bugs.php.net/?id=32244&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32244&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32244&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32244&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32244&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32244&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32244&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32244&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32244&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32244&r=support Expected behavior: http://bugs.php.net/fix.php?id=32244&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32244&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32244&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32244&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32244&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32244&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32244&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32244&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32244&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32244&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32244&r=mysqlcfg
#32176 [Opn]: (OS 10054)An existing connection was forcibly closed by the remote host. : cor
ID: 32176 User updated by: webmaster at sanders-consultation-group-plu Reported By: webmaster at sanders-consultation-group-plu Status: Open Bug Type: Apache2 related Operating System: Windows 2000 Pro PHP Version: 5.0.3 New Comment: Thought maybe some of this might help...just trying to help identify what's still causing this problem. Server software environment: Apache version 2.0.52 MySQL version 4.1.10 PostgreSQL version 8.0.0 Openssl version 0.9.7e Slimftpd version 3.16 Xmail version 1.21 Perl version 5.8.6 PHP version 5.0.3 readme Python version 2.3.4 Previous Comments: [2005-03-09 04:10:25] webmaster at sanders-consultation-group-plu Done Sniper, restarted the server, and still the following: [Tue Mar 08 21:02:17 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:59:21 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:59:21 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:57:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:57:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:56:59 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:56:58 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:54:51 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:54:29 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:50:41 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:50:41 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network Next question or suggestion? Thanks for the suggestion. [2005-03-09 00:57:10] [EMAIL PROTECTED] Try without those tags around it.. [2005-03-07 23:53:51] webmaster at sanders-consultation-group-plu Well that's nice. I tell you that the httpd.conf already has the syntax as set forth on that page, and the bug post is marked as bogus. Got news, it's not bogus, it's happening despite the following code in it: Win32DisableAcceptEx And I'm STILL getting these other errors too: [Mon Mar 07 11:50:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Mon Mar 07 08:32:44 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Mon Mar 07 08:32:44 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network It's showing up somewhat repeatedly. I'm also getting the more common error associated with the Asynchronous AcceptEx [Mon Mar 07 07:33:05 2005] [warn] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. [Mon Mar 07 07:33:05 2005] [warn] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. As I stated, it's already noted in the httpd.conf. Would you like to tell me that it's still bogus? [2005-03-07 03:29:16] webmaster at sanders-consultation-group-plu Sorry Sniper, that's not it. It's already been added to my httpd.conf, and the problem still persists. [2005-03-06 16:19:27] [EMAIL PROTECTED] http://httpd.apache.org/docs-2.0/faq/error.html#error.acceptex 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/32176 -- Edit this bug report at http://bugs.php.net/?id=32176&edit=1
#32176 [Fbk->Opn]: (OS 10054)An existing connection was forcibly closed by the remote host. : cor
ID: 32176 User updated by: webmaster at sanders-consultation-group-plu Reported By: webmaster at sanders-consultation-group-plu -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Windows 2000 Pro PHP Version: 5.0.3 New Comment: Done Sniper, restarted the server, and still the following: [Tue Mar 08 21:02:17 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:59:21 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:59:21 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:57:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:57:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:56:59 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:56:58 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:54:51 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:54:29 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:50:41 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:50:41 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network Next question or suggestion? Thanks for the suggestion. Previous Comments: [2005-03-09 00:57:10] [EMAIL PROTECTED] Try without those tags around it.. [2005-03-07 23:53:51] webmaster at sanders-consultation-group-plu Well that's nice. I tell you that the httpd.conf already has the syntax as set forth on that page, and the bug post is marked as bogus. Got news, it's not bogus, it's happening despite the following code in it: Win32DisableAcceptEx And I'm STILL getting these other errors too: [Mon Mar 07 11:50:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Mon Mar 07 08:32:44 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Mon Mar 07 08:32:44 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network It's showing up somewhat repeatedly. I'm also getting the more common error associated with the Asynchronous AcceptEx [Mon Mar 07 07:33:05 2005] [warn] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. [Mon Mar 07 07:33:05 2005] [warn] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. As I stated, it's already noted in the httpd.conf. Would you like to tell me that it's still bogus? [2005-03-07 03:29:16] webmaster at sanders-consultation-group-plu Sorry Sniper, that's not it. It's already been added to my httpd.conf, and the problem still persists. [2005-03-06 16:19:27] [EMAIL PROTECTED] http://httpd.apache.org/docs-2.0/faq/error.html#error.acceptex [2005-03-03 16:17:42] webmaster at sanders-consultation-group-plu Description: Just trying to establish that bug #25570 seems to still be alive and well in PHP 5.0.3, as I get the same errors messages that seem to be associated with this previous "closed" bug, though I am running on a different OS. Locahost set-up is Apache 2.0.52, and PHP 5.0.3. The full error is just as the post title, or as follows: (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network I found the 25570 bug while googling for the error message, so hopefully, I am posting this to the correct error. I would have posted it to the 25570 bug, but it states that closed bugs will not be updated and
#32241 [NEW]: Why not have mssql_insert_id function when use Microsoft sql server database!
From: kangtk at 163 dot com Operating system: Windows2000 Server PHP version: 4.3.10 PHP Bug Type: Feature/Change Request Bug description: Why not have mssql_insert_id function when use Microsoft sql server database! Description: I can use this function mysql_insert_id to get the insert id when I connect with mysql database. But I cann't use the mssql_insert_id when I change the code to Microsoft Sql server databse. Can you explain something to me? Thanks. -- Edit bug report at http://bugs.php.net/?id=32241&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32241&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32241&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32241&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32241&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32241&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32241&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32241&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32241&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32241&r=support Expected behavior: http://bugs.php.net/fix.php?id=32241&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32241&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32241&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32241&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32241&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32241&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32241&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32241&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32241&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32241&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32241&r=mysqlcfg
#29587 [Bgs]: ldap_read cannot read RootDSE
ID: 29587 User updated by: DavidSmith at byu dot net Reported By: DavidSmith at byu dot net Status: Bogus Bug Type: LDAP related Operating System: Fedora Core 1 PHP Version: 4.3.8 New Comment: Whatever the case, it may be worth investigating why PHP's ldap_read() failed in this case while the command line ldapsearch continued to function properly despite the ldap.conf settings. Previous Comments: [2005-03-09 01:43:45] DavidSmith at byu dot net Indeed. Please accept my humble apology. --Dave [2005-03-09 01:06:47] [EMAIL PROTECTED] Considering we didn't change anything in ext/ldap between this period and that I did mention ldap.conf once before -> bogus. (it wasn't PHP bug after all, was it? :) [2005-03-08 00:51:42] DavidSmith at byu dot net After installing the new PHP version, and commenting out the BASE line in both my ldap.conf files (one in /etc and one in /etc/openldap), it now works as expected! Good work! --Dave [2005-02-16 22:58:40] deon at wurley dot net I'm seeing this problem in Fedora Core 3 - which is using php 4.3.10. Withouth having to create my own php - any tips on how this can be resolved? Is there a fix in the code available? [2005-02-03 04:51:34] [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 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/29587 -- Edit this bug report at http://bugs.php.net/?id=29587&edit=1
#29587 [Bgs]: ldap_read cannot read RootDSE
ID: 29587 User updated by: DavidSmith at byu dot net Reported By: DavidSmith at byu dot net Status: Bogus Bug Type: LDAP related Operating System: Fedora Core 1 PHP Version: 4.3.8 New Comment: Indeed. Please accept my humble apology. --Dave Previous Comments: [2005-03-09 01:06:47] [EMAIL PROTECTED] Considering we didn't change anything in ext/ldap between this period and that I did mention ldap.conf once before -> bogus. (it wasn't PHP bug after all, was it? :) [2005-03-08 00:51:42] DavidSmith at byu dot net After installing the new PHP version, and commenting out the BASE line in both my ldap.conf files (one in /etc and one in /etc/openldap), it now works as expected! Good work! --Dave [2005-02-16 22:58:40] deon at wurley dot net I'm seeing this problem in Fedora Core 3 - which is using php 4.3.10. Withouth having to create my own php - any tips on how this can be resolved? Is there a fix in the code available? [2005-02-03 04:51:34] [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-10-01 15:26:50] DavidSmith at byu dot net ldap.conf has nothing to do with this bug. I am performing an ldap_read() and explicitly specificying my own search base (the empty string, ""). In this case, PHP and the LDAP libraries should not be reading the "base" directive in ldap.conf. Despite this glaringly obvious fact, I tried removing the "base" directive from ldap.conf to see if that fixed it. It had no effect on the bug. So I tried changing the "base" directive from dc=example,dc=com to the correct one, dc=phpldapadmin,dc=com, but PHP still searches with base dc=example,dc=com (yes I restarted my web server and LDAP server). So then I tried creating ~apache/.ldaprc and setting the base to dc=phpldapadmin,dc=com there. Still no effect on the bug. This is a bug. No matter what setting I have for my base in ldap.conf, PHP should is NOT using the base I specify in my call to ldap_read(). Perhaps PHP is interpreting a base of "" to mean "the default base DN specified somewhere else". This is NOT the desired behavior. The RFCs state that when searching with a base DN set to the empty string and a scope of "base", that the RootDSE entry should be returned. Note also that other versions of PHP work just fine with no changes to the LDAP libraries. See comments from other users as well. Also note that ldapsearch works just fine, so it's obviously not the LDAP client libraries. This is a PHP bug. --Dave 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/29587 -- Edit this bug report at http://bugs.php.net/?id=29587&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
I have tried this with the March 7 build and it is still not working in
the same fashion, but I have a bit more information on it. It is tied
to the fact that there is no previous navigation before the
javascript:whatever is hit.
For example,
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate($nav);
?>
will vanish IE, but
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate("about:blank");
$ie->Navigate($nav);
?>
will keep IE around (you can also use the non alert version). The
point is that the 'pre navigation' to "about:blank" allows the main
navigation to go through somehow.
Previous Comments:
[2005-02-28 21:09:15] [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-01-17 07:46:27] csaba at alum dot mit dot edu
I have replaced the sleep(...) with appropriate com_message_pump(...),
but I still get the same results.
[2005-01-17 04:32:22] [EMAIL PROTECTED]
You should never call sleep() in a script that uses COM, as deadlocks
and bad mojo can result. Instead, use com_message_pump() and specify
your delay in milliseconds.
If that doesn't help any, I'll try to look into this problem later in
the week.
[2005-01-17 04:02:24] csaba at alum dot mit dot edu
As a double check, I downloaded, then installed, PHP ver 5.0.4-dev
(cli) (built Jan 17 2005 02:30:00).
Still the same problem. IE goes away (and rings a bell) as soon as the
Navigate is hit.
[2005-01-15 17:35:38] [EMAIL PROTECTED]
You ofcourse need to reboot AFTER you installed it...
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/31493
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31624 [Com]: session_start() causes segmentation fault on complex objects
ID: 31624
Comment by: casey dot dinsmore at viewplus dot com
Reported By: ericvanblokland at gmail dot com
Status: Open
Bug Type: Session related
Operating System: Fedora Core 2
PHP Version: 4CVS-2005-01-22
New Comment:
Hello,
After upgrading my PHP from 4.3.9 to 4.3.10 on FreeBSD 5.2.1 I am
experiencing this problem. I have tried both apache 2.0.52 and
apache-ssl 1.3.33
I can serve up plain HTML, and basic PHP scripts without any problem
The following script puts a segmentation fault in my log
[Tue Mar 8 16:35:19 2005] [notice] child pid 6673 exit signal
Segmentation fault (11)
Previous Comments:
[2005-02-22 20:56:52] eerror at gmail dot com
for me it segfaults as soon as the code hits session_start. nothing
complex about the code. even a 3 line test script will cause it.
box: suse9.1,apache2.0.52, php4.3.10
[2005-02-05 18:00:17] ericvanblokland at gmail dot com
This is indeed very interesting, I haven't examined your code
thoroughly yet, but my objects tend to do memory consuming data
processing operations on wakeup. So this issue might be related as
well.
Perhaps you want to post your own bug-report about this, because your
issue is very precise and has its own example code. If you do, please
post a link to your report here, because your issue might as well be
mine.
[2005-02-05 15:45:05] bertrand at toggg dot com
I'm experiencing a simpler segfault on PHP4.3.10 FC2 too this way, just
trying to double and again an array:
$arr = array (str_repeat('X', 65536));
$mem = 0;
while ($loop--) {
for ($i = count($arr); $i; $i--) {
$arr[] = $arr[0];
if ($i%16) {
continue;
}
if ( ( ($nmem = memory_get_usage()) - $mem) > 100) {
$mem = $nmem;
echo 'Count:'.count($arr)." ($mem bytes)\n";
flush();
}
}
echo $loop.':'.count($arr).'/'.memory_get_usage() . "
bytes\n";
flush();
}
echo "\n OK \n";
flush();
For 18 loops it breaks my default memory limit of 8 Mo:
Allowed memory size of 8388608 bytes exhausted as expected.
If I add before the loop:
if (ini_set ('memory_limit', 16*1048576)) {
echo "Set memory limit to 16 Mo\n";
}
It's taking an incredible amount of time
and I get segfault.
What is strange, I get the output:
Set memory limit to 16 Mo
17:2/87456
<...snip...>
Count:256113 (11380680 bytes)
0:262144/11621952 bytes
what means the end of last loop reached.
But I never get the final acknowledgement.
I understand it's much more simpler as yours,
but result is quite near.
[2005-02-04 13:05:53] ericvanblokland at gmail dot com
Are you sure this is related to my problem? Do you have any data in
your session? If so, it very well might be related, if you experience
the crash always, no matter what, on session_start(); you should look
for a solution elsewhere.
In my case, the segmentation faults are triggered within the
__wakeup(); functions of my objects that exists in the session. Under
certain conditions the compiler messes up when unserializing the
session (In my last test-run yesterday memory leaks where reported with
a compiler with debug enabled and de segfaults disappeared, without the
debug mode enabled the segfaults returned) causing simple variable
assignments to crash php.
After a lot of testing I found when not putting certain data in the
session, the segfaults would disappear. However this data has nothing
to do with the crashing object. Unless the data has been referenced. It
shouldn't, but http://bugs.php.net/bug.php?id=24485 might be causing a
reference anyway.
Still, the php compiler contains some very serious bugs, that might be
causing, or causing the conditions which result in a segmentation
fault.
[2005-02-04 11:20:15] 1 at movesmountains dot com
Not sure if this is the same bug or not; however, I'm getting a
segfault on every call to session_start(), no matter how trivial the
code ( will do it).
FreeBSD 4.8-STABLE
Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7e PHP/4.3.10
Not sure what other info would be useful to you.
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/31624
--
Edit this bug report at http://bugs.php.net/?id=31624&edit=1
#31091 [Fbk->NoF]: Apache2 crash with SimpleXML and XPath
ID: 31091
Updated by: php-bugs@lists.php.net
Reported By: cpuidle at gmx dot de
-Status: Feedback
+Status: No Feedback
Bug Type: SimpleXML related
Operating System: WinXP SP1
PHP Version: 5CVS-2005-01-10
New Comment:
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".
Previous Comments:
[2005-02-28 21:17:21] [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-01-10 18:03:07] cpuidle at gmx dot de
No, still crashes :(
[2005-01-10 16:29:51] [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
[2004-12-14 17:31:54] cpuidle at gmx dot de
The same code, but without the xpath expression does not crash (and of
course not work...):
foreach
($xml->ListOfRepositoryWorkflowProcess->RepositoryWorkflowProcess->ListOfRepositoryWfStep->RepositoryWfStep->ListOfRepositoryWfStepIOArgument->RepositoryWfStepIOArgument
as $wfArg)
[2004-12-14 17:26:19] cpuidle at gmx dot de
Description:
I'm using xpath to retrieve a child node from an xml structure, then
loop over subelements of this node. This crashes reproducibly at the
foreach loop (apache log file: child process exited with status
3221225477 -- Restarting)
Same happens with latest 5.0.3RC2
Reproduce code:
---
$step = 'FindThisNode';
$node =
$xml->xpath('ListOfRepositoryWorkflowProcess/RepositoryWorkflowProcess/ListOfRepositoryWfStep/RepositoryWfStep[Name3="'.$step.'"]');
print_r($node);
# crash here!
foreach
($node->ListOfRepositoryWfStepIOArgument->RepositoryWfStepIOArgument as
$wfArg)
{
}
Expected result:
no crash?!
--
Edit this bug report at http://bugs.php.net/?id=31091&edit=1
#31618 [Opn->Fbk]: is_readable() results based on ownership of calling script, not file
ID: 31618
Updated by: [EMAIL PROTECTED]
Reported By: kibab at icehouse dot net
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: redhat enterprise
PHP Version: 5.0.3
New Comment:
What libxml2 version do you have installed?
What configure options did you use?
Previous Comments:
[2005-03-09 00:47:17] kibab at icehouse dot net
I tried and it didn't compile:
[EMAIL PROTECTED] php5-200503082130***]$ make
/bin/sh /root/builds/php5-200503082130/libtool --silent
--preserve-dup-deps --mode=compile gcc -Iext/libxml/
-I/root/builds/php5-200503082130/ext/libxml/
-DPHP_ATOM_INC -I/root/builds/php5-200503082130/include
-I/root/builds/php5-200503082130/main
-I/root/builds/php5-200503082130
-I/root/builds/php5-200503082130/Zend
-I/usr/include/libxml2 -I/usr/kerberos/include
-I/usr/include/freetype2 -I/usr/include/imap
-I/root/builds/php5-200503082130/ext/mbstring/oniguruma
-I/root/builds/php5-200503082130/ext/mbstring/libmbfl
-I/root/builds/php5-200503082130/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql -I/usr/include/ncurses
-I/usr/include/pspell
-I/root/builds/php5-200503082130/TSRM -g-O2
-prefer-non-pic
-c /root/builds/php5-200503082130/ext/libxml/libxml.c -o
ext/libxml/libxml.lo
/root/builds/php5-200503082130/ext/libxml/libxml.c:337:
syntax error before "error"
/root/builds/php5-200503082130/ext/libxml/libxml.c: In
function `_php_libxml_free_error':
/root/builds/php5-200503082130/ext/libxml/libxml.c:339:
`error' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:339:
(Each undeclared identifier is reported only once
/root/builds/php5-200503082130/ext/libxml/libxml.c:339:
for each function it appears in.)
/root/builds/php5-200503082130/ext/libxml/libxml.c: At top
level:
/root/builds/php5-200503082130/ext/libxml/libxml.c:343:
syntax error before "error"
/root/builds/php5-200503082130/ext/libxml/libxml.c: In
function `_php_list_set_error_structure':
/root/builds/php5-200503082130/ext/libxml/libxml.c:345:
`xmlError' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:345:
syntax error before "error_copy"
/root/builds/php5-200503082130/ext/libxml/libxml.c:350:
`error_copy' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:352:
`error' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:357:
`XML_ERR_ERROR' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:363:
`msg' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c: At top
level:
/root/builds/php5-200503082130/ext/libxml/libxml.c:455:
syntax error before "xmlErrorPtr"
/root/builds/php5-200503082130/ext/libxml/libxml.c: In
function `php_libxml_structured_error_handler':
/root/builds/php5-200503082130/ext/libxml/libxml.c:457:
`error' undeclared (first use in this function)
make: *** [ext/libxml/libxml.lo] Error 1
I'll try the next few snapshots until one of them compiles
and then provide feedback. Thanks.
[2005-02-28 20:59:48] [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-01-20 22:32:24] kibab at icehouse dot net
Maybe this isn't directly related, but
fopen($myfilename,"r") also fails, even though
include($myfilename) works. Again, $myfilename is in the
safe_mode_include_dir, so fopen should be able to open it.
[2005-01-19 23:05:35] kibab at icehouse dot net
Description:
is_readable($myfilename) in the repro code returns true if
the script calling it is owned by root, but false if it is
owned by someone else.
Permissions are:
-rw-r--r--1 root root 5452 Jan 13
13:02 /var/lib/php_packages/test_templ2.php
drwxr-xr-x4 root root 4096 Jan 19
08:19 /var/lib/php_packages
drwxr-xr-x 27 root root 4096 Jan 12
09:27 /var/lib
drwxr-xr-x 24 root root 4096 Sep 22
13:06 /var
drwxr-xr-x 20 root root 4096 Oct 29 09:48 /
Relevant Settings:
include_path =
".:/var/lib/php_packages:/var/lib/php_packages/pear"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /var/lib/php_packages
Reproduce code:
---
test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
#32176 [Opn->Fbk]: (OS 10054)An existing connection was forcibly closed by the remote host. : cor
ID: 32176 Updated by: [EMAIL PROTECTED] Reported By: webmaster at sanders-consultation-group-plu -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows 2000 Pro PHP Version: 5.0.3 New Comment: Try without those tags around it.. Previous Comments: [2005-03-07 23:53:51] webmaster at sanders-consultation-group-plu Well that's nice. I tell you that the httpd.conf already has the syntax as set forth on that page, and the bug post is marked as bogus. Got news, it's not bogus, it's happening despite the following code in it: Win32DisableAcceptEx And I'm STILL getting these other errors too: [Mon Mar 07 11:50:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Mon Mar 07 08:32:44 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Mon Mar 07 08:32:44 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network It's showing up somewhat repeatedly. I'm also getting the more common error associated with the Asynchronous AcceptEx [Mon Mar 07 07:33:05 2005] [warn] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. [Mon Mar 07 07:33:05 2005] [warn] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. As I stated, it's already noted in the httpd.conf. Would you like to tell me that it's still bogus? [2005-03-07 03:29:16] webmaster at sanders-consultation-group-plu Sorry Sniper, that's not it. It's already been added to my httpd.conf, and the problem still persists. [2005-03-06 16:19:27] [EMAIL PROTECTED] http://httpd.apache.org/docs-2.0/faq/error.html#error.acceptex [2005-03-03 16:17:42] webmaster at sanders-consultation-group-plu Description: Just trying to establish that bug #25570 seems to still be alive and well in PHP 5.0.3, as I get the same errors messages that seem to be associated with this previous "closed" bug, though I am running on a different OS. Locahost set-up is Apache 2.0.52, and PHP 5.0.3. The full error is just as the post title, or as follows: (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network I found the 25570 bug while googling for the error message, so hopefully, I am posting this to the correct error. I would have posted it to the 25570 bug, but it states that closed bugs will not be updated and posting to them will just be deleted. Didn't know what else to do in order to try and bring this to someone's attention. My appologies if I've gone about this the wrong way. Reproduce code: --- Not sure, just getting the same error messages as previously associated with bug #25570. Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=32176&edit=1
#32183 [Opn->Csd]: PHP Seg faults on normal code
ID: 32183 Updated by: [EMAIL PROTECTED] Reported By: zedar at zedar dot org -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Linux 2.4.26 PHP Version: 5.0.3 Previous Comments: [2005-03-08 00:11:55] zedar at zedar dot org Fantastic, works perfectly now. Thanks a lot. [2005-03-07 20:10:25] [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-03-07 04:12:09] zedar at zedar dot org A sample page that produces a segfault is available at the following URL: http://barra.telenet.net.au/WAME/Users/Options/details2.txt Sorry about the lenght, but thats the minimum I could get it down to and still produce the seg fault. I can't give you access to an actual php version on the server as we use auto-prepends on our scripts, and you wouldn't see any output from it anyway. I have put comments in front of the sections of code that can be removed to stop it from segfaulting. [2005-03-04 09:28:35] [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. [2005-03-04 08:24:54] zedar at zedar dot org Description: PHP segmentation faults on lines of unremarkable code (or in some cases, not code at all). The code causing the crashes is part of a large management system so i can't really provide a sample of what causes the crash, but I'm not sure it would help anyway. A couple of sample lines it has crashed on are shown below, but I'm not sure they caused the crash or if it was something else internal. It has also on occasion crashed while on non-php code, in the one case i saw it was a html comment. If i removed the comment, the page loaded fine. Reproduce code: --- // Crashes on this line $selected = ($status==$s)?'selected':''; Actual result: -- >From apache error log: [Fri Mar 4 16:49:54 2005] [error] PHP Warning: Unknown list entry type in request shutdown (1919251285) in Unknown on line 0 [Fri Mar 4 16:49:55 2005] [notice] child pid 23476 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=32183&edit=1
#32200 [Opn->Asn]: Make fails with: ld: -bundle_loader multiply specified
ID: 32200 Updated by: [EMAIL PROTECTED] Reported By: goofreaks at yahoo dot co dot uk -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Mac OS X 10.3.8 PHP Version: 5.0.3 -Assigned To: +Assigned To: sniper Previous Comments: [2005-03-06 23:19:50] goofreaks at yahoo dot co dot uk With the latest snap "./configure --disable-all --with- apxs2=/usr/local/apache2/bin/apxs --with-pcre-regex" and make work, although with a few warnings: /usr/local/php-5.1.0-dev/main/snprintf.c: In function `format_converter': /usr/local/php-5.1.0-dev/main/snprintf.c:917: warning: use of `long double' type; its size may change in a future release /usr/local/php-5.1.0-dev/main/snprintf.c:917: warning: (Long double usage is reported only once for each file. /usr/local/php-5.1.0-dev/main/snprintf.c:917: warning: To disable this warning, use -Wno-long-double.) [...] /usr/local/php-5.1.0-dev/main/spprintf.c: In function `xbuf_format_converter': /usr/local/php-5.1.0-dev/main/spprintf.c:534: warning: use of `long double' type; its size may change in a future release /usr/local/php-5.1.0-dev/main/spprintf.c:534: warning: (Long double usage is reported only once for each file. /usr/local/php-5.1.0-dev/main/spprintf.c:534: warning: To disable this warning, use -Wno-long-double.) [...] ld: warning multiple definitions of symbol _pcre_callout ext/pcre/pcrelib/pcre.o definition of _pcre_callout in section (__DATA,__data) /usr/local/apache2/bin/httpd definition of _pcre_callout ld: warning multiple definitions of symbol _pcre_config ext/pcre/pcrelib/pcre.o definition of _pcre_config in section (__TEXT,__text) /usr/local/apache2/bin/httpd definition of _pcre_config ld: warning multiple definitions of symbol _pcre_free ext/pcre/pcrelib/pcre.o definition of _pcre_free in section (__DATA,__data) /usr/local/apache2/bin/httpd definition of _pcre_free ld: warning multiple definitions of symbol _pcre_malloc ext/pcre/pcrelib/pcre.o definition of _pcre_malloc in section (__DATA,__data) /usr/local/apache2/bin/httpd definition of _pcre_malloc ld: warning multiple definitions of symbol _pcre_stack_free ext/pcre/pcrelib/pcre.o definition of _pcre_stack_free in section (__DATA,__data) /usr/local/apache2/bin/httpd definition of _pcre_stack_free ld: warning multiple definitions of symbol _pcre_stack_malloc ext/pcre/pcrelib/pcre.o definition of _pcre_stack_malloc in section (__DATA,__data) /usr/local/apache2/bin/httpd definition of _pcre_stack_malloc I'll start the configure line over with the other entries -- I guess I got my notes a bit confused! A suggestion for the "./configure --help" though, would it be possible to add in a note saying to only use one or other of --with-apxs2filter / --with-apxs2 ? It might stop someone else from making the same mistake that I did, [2005-03-06 19:25:59] [EMAIL PROTECTED] Are you really able to run configure with BOTH these in the ocnfigure line: --with-apxs2filter=/usr/local/apache2/bin/apxs --with-apxs2=/usr/local/apache2/bin/apxs FYI: You can ONLY have either one. Also, your configure line contains lot of entries which either don't exist or don't have any meaning when building apache module. Try this with the snapshot sources: # rm config.cache # ./configure --disable-all --with-apxs2=/usr/local/apache2/bin/apxs --with-pcre-regex [2005-03-06 19:07:45] goofreaks at yahoo dot co dot uk Make still fails with the snap, but the error is different: ld: warning multiple definitions of symbol _pcre_stack_malloc ext/pcre/pcrelib/pcre.o definition of _pcre_stack_malloc in section (__DATA,__data) /usr/local/apache2/bin/httpd definition of _pcre_stack_malloc make: *** [libs/libphp5.bundle] Error 1 [2005-03-06 16:14:17] [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-03-06 01:10:40] goofreaks at yahoo dot co dot uk Description: Configure works fine, but make fails. Reproduce code: --- ./configure --prefix=/usr/local/php5 --with-apxs2filter=/usr/local/apache2/bin/apxs --with-apxs2=/usr/local/apache2/bin/apxs --enable-cli --enable-cgi --enable-force-cgi-redirect --enable-discard-path --enable-fastcgi --disable-path-info-check --with-config-file-path=/usr/local/php5/lib --enable-safe-mode --with-exec-dir=/usr/local/php5/bin --disable-magic-quotes --disable-rpath --disable-short-tags --enable-libxml --with-libxml-dir=/usr/local/libxml2 --with-openssl-dir=/usr/include/openss
#32213 [Opn->Fbk]: Array key serialize problem 64 bit php
ID: 32213
Updated by: [EMAIL PROTECTED]
Reported By: csmith at cbbc dot murdoch dot edu dot au
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.0.3
New Comment:
Please get the latest snapshot again as this might have been fixed
already. If it isn't, paste the offending line here.
Previous Comments:
[2005-03-08 07:33:42] csmith at cbbc dot murdoch dot edu dot au
Ok. Tried to compile the latest version from cvs for a AMD Opteron (64
bit server) running lunix.
It wouldn't compile. Seems to have a problem with var_unserializer :
/bin/sh /root/software/php5-200503080330/libtool --silent
--preserve-dup-deps --mode=compile gcc -Iext/standard/
-I/root/software/php5-200503080330/ext/standard/ -DPHP_ATOM_INC
-I/root/software/php5-200503080330/include
-I/root/software/php5-200503080330/main
-I/root/software/php5-200503080330
-I/root/software/php5-200503080330/Zend -I/usr/include/libxml2
-I/usr/local/include -I/root/software/php5-200503080330/TSRM -g -O2
-c /root/software/php5-200503080330/ext/standard/var_unserializer.c -o
ext/standard/var_unserializer.lo
/root/software/php5-200503080330/ext/standard/var_unserializer.c: In
function `object_custom':
/root/software/php5-200503080330/ext/standard/var_unserializer.c:296:
warning: passing arg 2 of pointer to function from incompatible pointer
type
/root/software/php5-200503080330/ext/standard/var_unserializer.c:296:
warning: passing arg 3 of pointer to function makes pointer from
integer without a cast
/root/software/php5-200503080330/ext/standard/var_unserializer.c:296:
warning: passing arg 4 of pointer to function makes integer from
pointer without a cast
/root/software/php5-200503080330/ext/standard/var_unserializer.c:296:
too few arguments to function
make: *** [ext/standard/var_unserializer.lo] Error 1
[2005-03-07 20:09:33] [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-03-07 03:45:52] csmith at cbbc dot murdoch dot edu dot au
Description:
Having this bug in 64 bit versions of php only. 32 bit versions work as
expected.
If you create an array with large integers as the keys, serialize the
array, and unserialize the array, (so you can pass it through a
session) the array key value is not being type promoted to a data type
that can store the large integer.
Instead you get a different value back as the key after unserializing
the array.
This is happening with the 64 bit versions of 5.0.3 and 4.3.2.
Reproduce code:
---
$array["1234567891011"] = 'test';
print "The array:";
var_dump( $array);
$array_serialized = serialize($array);
$array_unserialized = unserialize($array_serialized);
print "The unserialized array:";
var_dump($array_unserialized);
Expected result:
The array:
array(1) { [1234567891011]=> string(4) "test" }
The unserialized array:
array(1) { [1234567891011]=> string(4) "test" }
*Note: this is what you get back in the 32 bit version of php.
Actual result:
--
The array:
array(1) { [1234567891011]=> string(4) "test" }
The unserialized array:
array(1) { [1912277059]=> string(4) "test" }
*Note: this is what you get back in the 64 bit version of php.
--
Edit this bug report at http://bugs.php.net/?id=32213&edit=1
#31618 [Fbk->Opn]: is_readable() results based on ownership of calling script, not file
ID: 31618
User updated by: kibab at icehouse dot net
Reported By: kibab at icehouse dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: redhat enterprise
PHP Version: 5.0.3
New Comment:
I tried and it didn't compile:
[EMAIL PROTECTED] php5-200503082130***]$ make
/bin/sh /root/builds/php5-200503082130/libtool --silent
--preserve-dup-deps --mode=compile gcc -Iext/libxml/
-I/root/builds/php5-200503082130/ext/libxml/
-DPHP_ATOM_INC -I/root/builds/php5-200503082130/include
-I/root/builds/php5-200503082130/main
-I/root/builds/php5-200503082130
-I/root/builds/php5-200503082130/Zend
-I/usr/include/libxml2 -I/usr/kerberos/include
-I/usr/include/freetype2 -I/usr/include/imap
-I/root/builds/php5-200503082130/ext/mbstring/oniguruma
-I/root/builds/php5-200503082130/ext/mbstring/libmbfl
-I/root/builds/php5-200503082130/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql -I/usr/include/ncurses
-I/usr/include/pspell
-I/root/builds/php5-200503082130/TSRM -g-O2
-prefer-non-pic
-c /root/builds/php5-200503082130/ext/libxml/libxml.c -o
ext/libxml/libxml.lo
/root/builds/php5-200503082130/ext/libxml/libxml.c:337:
syntax error before "error"
/root/builds/php5-200503082130/ext/libxml/libxml.c: In
function `_php_libxml_free_error':
/root/builds/php5-200503082130/ext/libxml/libxml.c:339:
`error' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:339:
(Each undeclared identifier is reported only once
/root/builds/php5-200503082130/ext/libxml/libxml.c:339:
for each function it appears in.)
/root/builds/php5-200503082130/ext/libxml/libxml.c: At top
level:
/root/builds/php5-200503082130/ext/libxml/libxml.c:343:
syntax error before "error"
/root/builds/php5-200503082130/ext/libxml/libxml.c: In
function `_php_list_set_error_structure':
/root/builds/php5-200503082130/ext/libxml/libxml.c:345:
`xmlError' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:345:
syntax error before "error_copy"
/root/builds/php5-200503082130/ext/libxml/libxml.c:350:
`error_copy' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:352:
`error' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:357:
`XML_ERR_ERROR' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c:363:
`msg' undeclared (first use in this function)
/root/builds/php5-200503082130/ext/libxml/libxml.c: At top
level:
/root/builds/php5-200503082130/ext/libxml/libxml.c:455:
syntax error before "xmlErrorPtr"
/root/builds/php5-200503082130/ext/libxml/libxml.c: In
function `php_libxml_structured_error_handler':
/root/builds/php5-200503082130/ext/libxml/libxml.c:457:
`error' undeclared (first use in this function)
make: *** [ext/libxml/libxml.lo] Error 1
I'll try the next few snapshots until one of them compiles
and then provide feedback. Thanks.
Previous Comments:
[2005-02-28 20:59:48] [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-01-20 22:32:24] kibab at icehouse dot net
Maybe this isn't directly related, but
fopen($myfilename,"r") also fails, even though
include($myfilename) works. Again, $myfilename is in the
safe_mode_include_dir, so fopen should be able to open it.
[2005-01-19 23:05:35] kibab at icehouse dot net
Description:
is_readable($myfilename) in the repro code returns true if
the script calling it is owned by root, but false if it is
owned by someone else.
Permissions are:
-rw-r--r--1 root root 5452 Jan 13
13:02 /var/lib/php_packages/test_templ2.php
drwxr-xr-x4 root root 4096 Jan 19
08:19 /var/lib/php_packages
drwxr-xr-x 27 root root 4096 Jan 12
09:27 /var/lib
drwxr-xr-x 24 root root 4096 Sep 22
13:06 /var
drwxr-xr-x 20 root root 4096 Oct 29 09:48 /
Relevant Settings:
include_path =
".:/var/lib/php_packages:/var/lib/php_packages/pear"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /var/lib/php_packages
Reproduce code:
---
test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
echo "is_readable: $myfilename (false)";
}
include($myfilename);
### test_templ2.php ###
TESTING!
Expected result:
I would expect is_readable() to retur
#32229 [Opn->Bgs]: "CLI has encountered a problem" (ModName: php5ts.dll)
ID: 32229 Updated by: [EMAIL PROTECTED] Reported By: pk at iname dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.0.3 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. #28839 Previous Comments: [2005-03-08 07:29:35] pk at iname dot com Description: The crash is easy to reproduce: C:\php> php -a Interactive mode enabled A PHP window comes up with a message beginning: "CLI has encountered a problem and needs to close. We are sorry for the inconvenience." Reproduce code: --- echo ((1 == 1)? 2 : 3); Expected result: Anything but a core dump. Actual result: -- A PHP window comes up with a message beginning: "CLI has encountered a problem and needs to close. We are sorry for the inconvenience." The error report includes this information: AppName: php.exe AppVer: 5.0.3.3 ModName: php5ts.dll ModVer: 5.0.3.3 Offset: 00015a24 -- Edit this bug report at http://bugs.php.net/?id=32229&edit=1
#30513 [Ver->Bgs]: segfault in cli/cgi interactive mode
ID: 30513
Updated by: [EMAIL PROTECTED]
Reported By: asm at asm dot flynet dot pl
-Status: Verified
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-09
New Comment:
see also bug #32229
Previous Comments:
[2005-03-09 00:43:08] [EMAIL PROTECTED]
See bug #28839
[2005-03-03 19:06:51] mweierophinney at gmail dot com
I have reproduced the problem with the similar code:
:
and 'php -a test.php' produces a segfault.
I can confirm it for PHP versions 5.0.1, 5.0.2, and 5.0.3 -- 5.0.3 on
Gentoo GNU/Linux and 5.0.1 and 5.0.2 on Fedora Core 1.
[2004-10-23 18:28:44] [EMAIL PROTECTED]
Actually it segfaults in interactive mode even on this:
And it's caused by the fact that somehow EX(opline) happens to point to
not initilized memory.
bt:
Program received signal SIGSEGV, Segmentation fault.
0x0819681b in execute (op_array=0x831093c) at zend_vm_execute.h:58
58 if (EX(opline)->handler(&execute_data
TSRMLS_CC) > 0) {
(gdb) bt
#0 0x0819681b in execute (op_array=0x831093c) at zend_vm_execute.h:58
#1 0x0816e574 in execute_new_code () at
/home/dev/php-src/Zend/zend_execute_API.c:1089
#2 0x08159a24 in zendparse () at zend_language_parser.y:166
#3 0x0815c086 in compile_file (file_handle=0xb890, type=2) at
zend_language_scanner.l:375
#4 0x08178445 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src/Zend/zend.c:1049
#5 0x0813fd23 in php_execute_script (primary_file=0xb890) at
/home/dev/php-src/main/main.c:1634
#6 0x081f6250 in main (argc=2, argv=0xb914) at
/home/dev/php-src/sapi/cli/php_cli.c:943
[2004-10-21 16:49:24] asm at asm dot flynet dot pl
Description:
Please forgive, that I haven't attached backtrace, and
whole ./configure options. But I see this behaviour
on diffrent boxes (an old slackware with 2.2 and fedora with 2.4) with
diffrent versions
of PHP5's CLI/CGI interactive mode (so it should be easy to recover).
It doesn't affect PHP4.
Reproduce code:
---
BOX1$ php -v ; php -a
PHP 5.0.0 (cli) (built: Oct 15 2004 17:43:01)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0, Copyright (c) 1998-2004 Zend Technologies
Interactive mode enabled
got itSegmentation fault
***
BOX2$ php5 -v ; php5 -a
PHP 5.0.2 (cli) (built: Oct 17 2004 00:46:25)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies
Interactive mode enabled
got itSegmentation fault
Expected result:
got it
Actual result:
--
expected + segfault
--
Edit this bug report at http://bugs.php.net/?id=30513&edit=1
#28839 [Ver]: SIGSEGV in interactive mode (php -a)
ID: 28839
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: CGI related
Operating System: *
PHP Version: 5CVS-2005-03-06
New Comment:
See also bug #32229 and bug #30513
Previous Comments:
[2004-12-22 05:01:20] [EMAIL PROTECTED]
moving to CGI/CLI, since this bug only is related to the -a option of
php
[2004-12-19 03:59:10] [EMAIL PROTECTED]
This problem isn't the only one. There are a number of different
operations and expressions that crash CLI; while I can't think of any
off-hand, this is not the first time I've seen php -a segfault.
[2004-12-18 23:17:24] samalone at llamagraphics dot com
I think I've tracked this bug down to a logic error in the function
pass_two() in zend_opcode.c, but I'm not familiar enough with the code
to know the correct fix.
My particular case is with PHP 5.0.3 under FreeBSD 4.7.
The bug is that pass_two() is not adjusting op_array->start_op after
calling erealloc on op_array->opcodes. If erealloc returns a pointer
to a different chunk of memory, op_array->start_op is left pointing
into the old memory block which has just been freed. Later code
attempts to execute the opcodes starting at op_array->start_op.
Of course, whether this bug results in a crash or not depends on the
behavior of the memory allocator.
I'm uncertain whether op_array->start_op should be set to NULL in this
function, or set to the same relative location in the opcodes array.
I'm guessing the latter, since this would mimic the behavior on systems
where erealloc simply returns the same chunk of memory.
[2004-06-18 23:23:13] [EMAIL PROTECTED]
Description:
This problem only occurs when php is ran in in interactive mode, it
works perfectly fine from a script.
Reproduce code:
---
php -a
handler(&execute_data,
EX(opline), op_array TSRMLS_CC)) {
(gdb) bt
#0 0x0826aa97 in execute (op_array=0x83c2c6c)
at /xxx/cvs/php/php-src/Zend/zend_execute.c:1389
#1 0x0823ba64 in execute_new_code ()
at /xxx/cvs/php/php-src/Zend/zend_execute_API.c:1069
#2 0x08220598 in zendparse ()
at /xxx/cvs/php/php-src/Zend/zend_language_parser.y:153
#3 0x082246e2 in compile_file (file_handle=0xbfbfe5c0, type=2)
at /xxx/cvs/php/php-src/Zend/zend_language_scanner.l:374
#4 0x082472b0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /xxx/cvs/php/php-src/Zend/zend.c:1057
#5 0x0820172b in php_execute_script (primary_file=0xbfbfe5c0)
at /xxx/cvs/php/php-src/main/main.c:1627
#6 0x08277fb1 in main (argc=2, argv=0xbfbfe630)
at /xxx/cvs/php/php-src/sapi/cli/php_cli.c:943
#7 0x08084632 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=28839&edit=1
#32219 [Bgs->Ver]: Alphabetical sort with accented characters
ID: 32219
Updated by: [EMAIL PROTECTED]
Reported By: php-france at mattoug dot net
-Status: Bogus
+Status: Verified
-Bug Type: Arrays related
+Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4CVS-2005-03-09
New Comment:
Saying that something is supported in PHP 5 isn't gonna make this
'feature' (or fix, IMO) end up in PHP 4. Backport it is.
Previous Comments:
[2005-03-08 23:17:10] [EMAIL PROTECTED]
No bug here, PHP 4 never had support for sorting locale based. I added
this function to PHP 5.0.2 to support it.
[2005-03-08 23:11:54] [EMAIL PROTECTED]
It's a bug if *sort() functions can't handle locales correctly.
[2005-03-07 23:49:57] [EMAIL PROTECTED]
No bug here, the functions don't understand locales unless you add as
second "sort-flag" parameter SORT_LOCALE_STRING to asort(). This option
is introduced in PHP 5.0.2.
The following works fine (if you have the fr_FR locale installed):
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Écosse",
"ON" => "Ontario",
"PE" => "Île-du-Prince-Édouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
[2005-03-07 19:31:22] [EMAIL PROTECTED]
With what locale do you expect that output?
[2005-03-07 14:00:09] php-france at mattoug dot net
Description:
Accented characters are not properly sorted. For example, the right
sorting of "à" is between "a" and "b", for "é" it's between "e" and
"f", and so on...
Reproduce code:
---
$table = array("AB" => "Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Écosse",
"ON" => "Ontario",
"PE" => "Île-du-Prince-Édouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table);
Expected result:
array(13) { ["AB"]=> string(7) "Alberta" ["BC"]=> string(20)
"Colombie-Britannique" ["PE"]=> string(21) "Île-du-Prince-Édouard"
["MB"]=> string(8) "Manitoba" ["NB"]=> string(17) "Nouveau-Brunswick"
["NS"]=> string(15) "Nouvelle-Écosse" ["NU"]=> string(7) "Nunavut"
["ON"]=> string(7) "Ontario" ["QC"]=> string(6) "Québec" ["SK"]=>
string(12) "Saskatchewan" ["NL"]=> string(23)
"Terre-Neuve-et-Labrador" ["YT"]=> string(19) "Territoire du Yukon"
["NT"]=> string(25) "Territoires du Nord-Ouest"}
Actual result:
--
array(13) { ["AB"]=> string(7) "Alberta" ["BC"]=> string(20)
"Colombie-Britannique" ["MB"]=> string(8) "Manitoba" ["NB"]=>
string(17) "Nouveau-Brunswick" ["NS"]=> string(15) "Nouvelle-Écosse"
["NU"]=> string(7) "Nunavut" ["ON"]=> string(7) "Ontario" ["QC"]=>
string(6) "Québec" ["SK"]=> string(12) "Saskatchewan" ["NL"]=>
string(23) "Terre-Neuve-et-Labrador" ["YT"]=> string(19) "Territoire
du Yukon" ["NT"]=> string(25) "Territoires du Nord-Ouest" ["PE"]=>
string(21) "Île-du-Prince-Édouard" }
--
Edit this bug report at http://bugs.php.net/?id=32219&edit=1
#32232 [Fbk]: Bug with CGI HTTP_POST_VARS
ID: 32232 Updated by: [EMAIL PROTECTED] Reported By: crandym2003 at yahoo dot com Status: Feedback Bug Type: CGI related Operating System: Windows/Unix PHP Version: 4.3.10 New Comment: And FYI: I'd be very worried if "series_photo" ended up in $HTTP_POST_VARS (or $_POST, which you should use too) Uploaded file information usually goes into $_FILES.. Previous Comments: [2005-03-08 23:23:37] [EMAIL PROTECTED] I can not reproduce this. With what browser(s) do you get this? Can you anyhow provide a short but COMPLETE script? (the one above does not have even a submit button, not to mention the fact that it's not even close being valid HTML) [2005-03-08 15:02:09] crandym2003 at yahoo dot com Description: When using the POST method in a form defined with enctype="multipart/form-data", a single defined hidden form element is lost between form named EditSeries when submit button posts form to submit_series.php. This only happens when text data entered into the TEXTAREA contains a special trademark character ™. I have seen this same bug before with other special characters. The form "submit_series.php" should get (4) form elements in the attached code which are: series_id, destination, series_desc, series_photo. Performing a dump_var $HTTP_SERVER_VAR at the beginnging of submit_series.php only shows (3) because the first form item "series_id" is somehow lost through CGI intrepretation. This doesn't happen unless data containing ™ is entered into the TEXTAREA box. The workaround is to place all hidden entities in the form after the TEXTAREA item or insert a extra hidden blank entity just above the series_id entity. This also does not happen if the enctype="multipart/form-data" is set to text entry only. In this case however, the form contains an input type=file so the multipart/form-data is necessary. Reproduce code: --- Expected result: When you run dump_vars($HTTP_SERVER_VARS) on the submit_series.php form and print them, there should be a total of (4) form items passed which are which are: series_id, destination, series_desc, series_photo. Actual result: -- When you run dump_vars($HTTP_SERVER_VARS) on the submit_series.php form and print them, there area a total of (3) form items passed which are which are: destination, series_desc, series_photo. Somehow, the first defined hidden entity series_id is lost and not defined in $HTTP_SERVER_VARS. This only happens when a special trademark character is entered as text data in the TEXTAREA box. If you move the location of the hidden items somewhere in the form "after" the TEXTAREA item, all elements are forwarded to the next page (i.e., this is a workaround) -- Edit this bug report at http://bugs.php.net/?id=32232&edit=1
#32232 [Opn->Fbk]: Bug with CGI HTTP_POST_VARS
ID: 32232 Updated by: [EMAIL PROTECTED] Reported By: crandym2003 at yahoo dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: Windows/Unix PHP Version: 4.3.10 New Comment: I can not reproduce this. With what browser(s) do you get this? Can you anyhow provide a short but COMPLETE script? (the one above does not have even a submit button, not to mention the fact that it's not even close being valid HTML) Previous Comments: [2005-03-08 15:02:09] crandym2003 at yahoo dot com Description: When using the POST method in a form defined with enctype="multipart/form-data", a single defined hidden form element is lost between form named EditSeries when submit button posts form to submit_series.php. This only happens when text data entered into the TEXTAREA contains a special trademark character ™. I have seen this same bug before with other special characters. The form "submit_series.php" should get (4) form elements in the attached code which are: series_id, destination, series_desc, series_photo. Performing a dump_var $HTTP_SERVER_VAR at the beginnging of submit_series.php only shows (3) because the first form item "series_id" is somehow lost through CGI intrepretation. This doesn't happen unless data containing ™ is entered into the TEXTAREA box. The workaround is to place all hidden entities in the form after the TEXTAREA item or insert a extra hidden blank entity just above the series_id entity. This also does not happen if the enctype="multipart/form-data" is set to text entry only. In this case however, the form contains an input type=file so the multipart/form-data is necessary. Reproduce code: --- Expected result: When you run dump_vars($HTTP_SERVER_VARS) on the submit_series.php form and print them, there should be a total of (4) form items passed which are which are: series_id, destination, series_desc, series_photo. Actual result: -- When you run dump_vars($HTTP_SERVER_VARS) on the submit_series.php form and print them, there area a total of (3) form items passed which are which are: destination, series_desc, series_photo. Somehow, the first defined hidden entity series_id is lost and not defined in $HTTP_SERVER_VARS. This only happens when a special trademark character is entered as text data in the TEXTAREA box. If you move the location of the hidden items somewhere in the form "after" the TEXTAREA item, all elements are forwarded to the next page (i.e., this is a workaround) -- Edit this bug report at http://bugs.php.net/?id=32232&edit=1
#32219 [Ver->Bgs]: Alphabetical sort with accented characters
ID: 32219
Updated by: [EMAIL PROTECTED]
Reported By: php-france at mattoug dot net
-Status: Verified
+Status: Bogus
Bug Type: Arrays related
Operating System: *
PHP Version: 4CVS-2005-03-09
New Comment:
No bug here, PHP 4 never had support for sorting locale based. I added
this function to PHP 5.0.2 to support it.
Previous Comments:
[2005-03-08 23:11:54] [EMAIL PROTECTED]
It's a bug if *sort() functions can't handle locales correctly.
[2005-03-07 23:49:57] [EMAIL PROTECTED]
No bug here, the functions don't understand locales unless you add as
second "sort-flag" parameter SORT_LOCALE_STRING to asort(). This option
is introduced in PHP 5.0.2.
The following works fine (if you have the fr_FR locale installed):
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Écosse",
"ON" => "Ontario",
"PE" => "Île-du-Prince-Édouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
[2005-03-07 19:31:22] [EMAIL PROTECTED]
With what locale do you expect that output?
[2005-03-07 14:00:09] php-france at mattoug dot net
Description:
Accented characters are not properly sorted. For example, the right
sorting of "à" is between "a" and "b", for "é" it's between "e" and
"f", and so on...
Reproduce code:
---
$table = array("AB" => "Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Écosse",
"ON" => "Ontario",
"PE" => "Île-du-Prince-Édouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table);
Expected result:
array(13) { ["AB"]=> string(7) "Alberta" ["BC"]=> string(20)
"Colombie-Britannique" ["PE"]=> string(21) "Île-du-Prince-Édouard"
["MB"]=> string(8) "Manitoba" ["NB"]=> string(17) "Nouveau-Brunswick"
["NS"]=> string(15) "Nouvelle-Écosse" ["NU"]=> string(7) "Nunavut"
["ON"]=> string(7) "Ontario" ["QC"]=> string(6) "Québec" ["SK"]=>
string(12) "Saskatchewan" ["NL"]=> string(23)
"Terre-Neuve-et-Labrador" ["YT"]=> string(19) "Territoire du Yukon"
["NT"]=> string(25) "Territoires du Nord-Ouest"}
Actual result:
--
array(13) { ["AB"]=> string(7) "Alberta" ["BC"]=> string(20)
"Colombie-Britannique" ["MB"]=> string(8) "Manitoba" ["NB"]=>
string(17) "Nouveau-Brunswick" ["NS"]=> string(15) "Nouvelle-Écosse"
["NU"]=> string(7) "Nunavut" ["ON"]=> string(7) "Ontario" ["QC"]=>
string(6) "Québec" ["SK"]=> string(12) "Saskatchewan" ["NL"]=>
string(23) "Terre-Neuve-et-Labrador" ["YT"]=> string(19) "Territoire
du Yukon" ["NT"]=> string(25) "Territoires du Nord-Ouest" ["PE"]=>
string(21) "Île-du-Prince-Édouard" }
--
Edit this bug report at http://bugs.php.net/?id=32219&edit=1
#32219 [Bgs->Ver]: Alphabetical sort with accented characters
ID: 32219
Updated by: [EMAIL PROTECTED]
Reported By: php-france at mattoug dot net
-Status: Bogus
+Status: Verified
Bug Type: Arrays related
-Operating System:
+Operating System: *
-PHP Version: 4.3.8
+PHP Version: 4CVS-2005-03-09
New Comment:
It's a bug if *sort() functions can't handle locales correctly.
Previous Comments:
[2005-03-07 23:49:57] [EMAIL PROTECTED]
No bug here, the functions don't understand locales unless you add as
second "sort-flag" parameter SORT_LOCALE_STRING to asort(). This option
is introduced in PHP 5.0.2.
The following works fine (if you have the fr_FR locale installed):
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Écosse",
"ON" => "Ontario",
"PE" => "Île-du-Prince-Édouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
[2005-03-07 19:31:22] [EMAIL PROTECTED]
With what locale do you expect that output?
[2005-03-07 14:00:09] php-france at mattoug dot net
Description:
Accented characters are not properly sorted. For example, the right
sorting of "à" is between "a" and "b", for "é" it's between "e" and
"f", and so on...
Reproduce code:
---
$table = array("AB" => "Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Écosse",
"ON" => "Ontario",
"PE" => "Île-du-Prince-Édouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table);
Expected result:
array(13) { ["AB"]=> string(7) "Alberta" ["BC"]=> string(20)
"Colombie-Britannique" ["PE"]=> string(21) "Île-du-Prince-Édouard"
["MB"]=> string(8) "Manitoba" ["NB"]=> string(17) "Nouveau-Brunswick"
["NS"]=> string(15) "Nouvelle-Écosse" ["NU"]=> string(7) "Nunavut"
["ON"]=> string(7) "Ontario" ["QC"]=> string(6) "Québec" ["SK"]=>
string(12) "Saskatchewan" ["NL"]=> string(23)
"Terre-Neuve-et-Labrador" ["YT"]=> string(19) "Territoire du Yukon"
["NT"]=> string(25) "Territoires du Nord-Ouest"}
Actual result:
--
array(13) { ["AB"]=> string(7) "Alberta" ["BC"]=> string(20)
"Colombie-Britannique" ["MB"]=> string(8) "Manitoba" ["NB"]=>
string(17) "Nouveau-Brunswick" ["NS"]=> string(15) "Nouvelle-Écosse"
["NU"]=> string(7) "Nunavut" ["ON"]=> string(7) "Ontario" ["QC"]=>
string(6) "Québec" ["SK"]=> string(12) "Saskatchewan" ["NL"]=>
string(23) "Terre-Neuve-et-Labrador" ["YT"]=> string(19) "Territoire
du Yukon" ["NT"]=> string(25) "Territoires du Nord-Ouest" ["PE"]=>
string(21) "Île-du-Prince-Édouard" }
--
Edit this bug report at http://bugs.php.net/?id=32219&edit=1
#32235 [Opn->Fbk]: Zend Optimizer Fails Make Sparc64 SMP Debian GNU/Linux 3.1 (Sarge)
ID: 32235 Updated by: [EMAIL PROTECTED] Reported By: unixpenguin2004 at earthlink dot net -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Debian GNU/Linux 3.1 PHP Version: 4.3.10 New Comment: 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 Previous Comments: [2005-03-08 18:30:00] unixpenguin2004 at earthlink dot net Description: Zend fails to compile on SMP Sparc64 system with 2.4 kernel on Debian Sarge. Reproduce code: --- http://binaryshadow.org/~penguin/zend_sparc64_errors.txt Expected result: The Zend engine needs to compile for PHP to work. It shouldn't have all of this reproducable broken code. -- Edit this bug report at http://bugs.php.net/?id=32235&edit=1
#32238 [Opn->Csd]: spl_array.c: void function cannot return value
ID: 32238 Updated by: [EMAIL PROTECTED] Reported By: soloturn99 at yahoo dot com -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: solaris 8 PHP Version: 5CVS-2005-03-08 (dev) Assigned To: johannes 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: [2005-03-08 21:31:00] soloturn99 at yahoo dot com Description: "/usr/local/src/php5-STABLE-200503081930/ext/spl/spl_array.c", line 323: void function cannot return value "/usr/local/src/php5-STABLE-200503081930/ext/spl/spl_array.c", line 370: void function cannot return value -- Edit this bug report at http://bugs.php.net/?id=32238&edit=1
#32238 [NEW]: spl_array.c: void function cannot return value
From: soloturn99 at yahoo dot com Operating system: solaris 8 PHP version: 5CVS-2005-03-08 (dev) PHP Bug Type: Compile Failure Bug description: spl_array.c: void function cannot return value Description: "/usr/local/src/php5-STABLE-200503081930/ext/spl/spl_array.c", line 323: void function cannot return value "/usr/local/src/php5-STABLE-200503081930/ext/spl/spl_array.c", line 370: void function cannot return value -- Edit bug report at http://bugs.php.net/?id=32238&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32238&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32238&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32238&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32238&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32238&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32238&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32238&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32238&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32238&r=support Expected behavior: http://bugs.php.net/fix.php?id=32238&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32238&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32238&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32238&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32238&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32238&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32238&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32238&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32238&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32238&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32238&r=mysqlcfg
#32236 [NEW]: Multiple paths for session.save_path
From: justin at redwiredesign dot com Operating system: FreeBSD 5. PHP version: 4.3.10 PHP Bug Type: Feature/Change Request Bug description: Multiple paths for session.save_path Description: In certain circumstances, there is the possibility that the directory referred to by session.save_path is non-writeable. It would be advantageous to be able to specify multiple paths on this line, colon-seperated like include_path so that when PHP tries to create a session file and fails, it has another location to create the file in. -- Edit bug report at http://bugs.php.net/?id=32236&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32236&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32236&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32236&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32236&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32236&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32236&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32236&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32236&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32236&r=support Expected behavior: http://bugs.php.net/fix.php?id=32236&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32236&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32236&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32236&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32236&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32236&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32236&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32236&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32236&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32236&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32236&r=mysqlcfg
#32121 [Opn]: WDDX does not properly serialize variables
ID: 32121
User updated by: jbeall at heraldic dot us
Reported By: jbeall at heraldic dot us
Status: Open
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.0.3
New Comment:
As I mentioned earlier I am unable to add a new comment without
changing the status from feedback to something else. "open" and
"closed" are the only options I am presented with.
Previous Comments:
[2005-03-08 19:36:06] jbeall at heraldic dot us
I have not had a chance to try the snapshot. I will do that as soon as
I have the opportunity.
[2005-03-06 16:50:31] [EMAIL PROTECTED]
Did you or did you not try the snapshot?
[2005-03-01 01:10:09] jbeall at heraldic dot us
I have tracked down the problem to WDDX not properly serializing
arrays. Consider the following:
$data = array(1=>"First value",2=>"Second Value",3=>"Third Value");
$wddxPacket = wddx_serialize_value($data);
$deserialized = wddx_deserialize($wddxPacket);
echo gettype($deserialized[1])." {$deserialized[1]}\n";
var_dump($deserialized);
It outputs:
NULL
array(3) {
["1"]=>
string(11) "First value"
["2"]=>
string(12) "Second Value"
["3"]=>
string(11) "Third Value"
}
You will note that the indices are now string values rather than
integers. This is apparently because the array begins at an index
other than 0. The expected output is of course:
string First value
array(3) {
[1]=>
string(11) "First value"
[2]=>
string(12) "Second Value"
[3]=>
string(11) "Third Value"
}
Perhaps this should be filed as a separate bug report, or is already a
known bug?
As far as changing the status, the only statuses that I am able to set
it to are "open" and "closed" - "feedback" is not listed as one of my
options.
[2005-02-27 13:59:28] jbeall at heraldic dot us
Actually I just had a possible epiphany - I am serializing the entire
$_POST variable using WDDX and recovering on a subsequent page by
deserializing the WDDX packet.
I wonder if when WDDX deserializes an array, it stores everything at
string indices, even if the indices are integers. Note that for
convenience reasons the arrays in question start at [1], not [0]; that
may be significant, I don't know enough about PHP's WDDX functionality
to say.
I will not be able to investigate this further for several days, but I
will post back when I can.
[2005-02-27 13:25:43] [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
ALWAYS try the snapshots first.
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/32121
--
Edit this bug report at http://bugs.php.net/?id=32121&edit=1
#32121 [Fbk->Opn]: WDDX does not properly serialize variables
ID: 32121
User updated by: jbeall at heraldic dot us
Reported By: jbeall at heraldic dot us
-Status: Feedback
+Status: Open
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.0.3
New Comment:
I have not had a chance to try the snapshot. I will do that as soon as
I have the opportunity.
Previous Comments:
[2005-03-06 16:50:31] [EMAIL PROTECTED]
Did you or did you not try the snapshot?
[2005-03-01 01:10:09] jbeall at heraldic dot us
I have tracked down the problem to WDDX not properly serializing
arrays. Consider the following:
$data = array(1=>"First value",2=>"Second Value",3=>"Third Value");
$wddxPacket = wddx_serialize_value($data);
$deserialized = wddx_deserialize($wddxPacket);
echo gettype($deserialized[1])." {$deserialized[1]}\n";
var_dump($deserialized);
It outputs:
NULL
array(3) {
["1"]=>
string(11) "First value"
["2"]=>
string(12) "Second Value"
["3"]=>
string(11) "Third Value"
}
You will note that the indices are now string values rather than
integers. This is apparently because the array begins at an index
other than 0. The expected output is of course:
string First value
array(3) {
[1]=>
string(11) "First value"
[2]=>
string(12) "Second Value"
[3]=>
string(11) "Third Value"
}
Perhaps this should be filed as a separate bug report, or is already a
known bug?
As far as changing the status, the only statuses that I am able to set
it to are "open" and "closed" - "feedback" is not listed as one of my
options.
[2005-02-27 13:59:28] jbeall at heraldic dot us
Actually I just had a possible epiphany - I am serializing the entire
$_POST variable using WDDX and recovering on a subsequent page by
deserializing the WDDX packet.
I wonder if when WDDX deserializes an array, it stores everything at
string indices, even if the indices are integers. Note that for
convenience reasons the arrays in question start at [1], not [0]; that
may be significant, I don't know enough about PHP's WDDX functionality
to say.
I will not be able to investigate this further for several days, but I
will post back when I can.
[2005-02-27 13:25:43] [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
ALWAYS try the snapshots first.
[2005-02-27 13:09:59] jbeall at heraldic dot us
You are right. I must not be truly understanding what is causing the
problem (I am definitely having the problem that I cannot access array
values from a form), but it must be something other than the
name='fname[1]' field name.
I was trying to simplify my code down to less than 20 lines for the
post and I was missing $_REQUEST.
What I may have to do is simply save is serialize the variable that I
have that is causing me so much trouble and post a link to that. I'm
really at a loss at this point as to what might be the cause since it
is apparently not the form problem. Sorry for messing up 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/32121
--
Edit this bug report at http://bugs.php.net/?id=32121&edit=1
#32235 [NEW]: Zend Optimizer Fails Make Sparc64 SMP Debian GNU/Linux 3.1 (Sarge)
From: unixpenguin2004 at earthlink dot net Operating system: Debian GNU/Linux 3.1 PHP version: 4.3.10 PHP Bug Type: Zend Engine 2 problem Bug description: Zend Optimizer Fails Make Sparc64 SMP Debian GNU/Linux 3.1 (Sarge) Description: Zend fails to compile on SMP Sparc64 system with 2.4 kernel on Debian Sarge. Reproduce code: --- http://binaryshadow.org/~penguin/zend_sparc64_errors.txt Expected result: The Zend engine needs to compile for PHP to work. It shouldn't have all of this reproducable broken code. -- Edit bug report at http://bugs.php.net/?id=32235&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32235&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32235&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32235&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32235&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32235&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32235&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32235&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32235&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32235&r=support Expected behavior: http://bugs.php.net/fix.php?id=32235&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32235&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32235&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32235&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32235&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32235&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32235&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32235&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32235&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32235&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32235&r=mysqlcfg
#32230 [Bgs]: single quotes
ID: 32230 User updated by: amal_omairi at yahoo dot com Reported By: amal_omairi at yahoo dot com Status: Bogus Bug Type: Output Control Operating System: Windows XP Pro PHP Version: 4.3.10 New Comment: thank you for repling. actually addslashes and strip slashes are used. you say it is not a php error so do you think the use of html_entity_decode() nor htmlspecialchars()? what do you advice me to do? thank you again:-) Previous Comments: [2005-03-08 10:43:54] [EMAIL PROTECTED] 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. Even if you think it is not a bug, we often know better than you, please consult the support channels first before even considering to reopen this report. Thank you for your interest in PHP. . [2005-03-08 09:06:05] amal_omairi at yahoo dot com Description: i work on a content management area system. where user text inserted to a table in MySQL database and then reteived for preview in atext area. but when user types a single quote it is previewed as double quotes. the magic_quotes_gpc is on, and magic_quotes_sybase is off. addslashes is not used but stripslashes is used when retrieval from databse. please help. Reproduce code: --- Expected result: preview single quote. Actual result: -- previwes double qoutes instead. -- Edit this bug report at http://bugs.php.net/?id=32230&edit=1
#30160 [Opn]: Installing PHP SAPI module fails
ID: 30160 User updated by: tessarek at evermeet dot cx Reported By: tessarek at evermeet dot cx Status: Open Bug Type: Compile Failure Operating System: AIX 5.x and Redhat Linux 8.0 / 9 PHP Version: 5.0.0 New Comment: It works on Fedora Core 3 with gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3). No problems with make install: Build complete. (It is safe to ignore warnings about tempnam and tmpnam). [EMAIL PROTECTED] php5-200503081130]$ make install Installing PHP SAPI module: apache2filter /usr/lib/httpd/build/instdso.sh SH_LIBTOOL='/bin/sh /usr/lib/apr/build/libtool' libphp5.la /usr/lib/httpd/modules /bin/sh /usr/lib/apr/build/libtool --mode=install cp libphp5.la /usr/lib/httpd/modules/ cp .libs/libphp5.so /usr/lib/httpd/modules/libphp5.so cp .libs/libphp5.lai /usr/lib/httpd/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /ext/php5-200503081130/libs' chmod 755 /usr/lib/httpd/modules/libphp5.so [activating module `php5' in /etc/httpd/conf/httpd.conf] Installing PHP CLI binary:/opt/php5/bin/ Installing PHP CLI man page: /opt/php5/man/man1/ Installing PEAR environment: /opt/php5/lib/php/ [PEAR] Archive_Tar: 'xml' PHP extension is not installed [PEAR] Console_Getopt: 'xml' PHP extension is not installed [PEAR] PEAR: 'xml' PHP extension is not installed [PEAR] XML_RPC: 'xml' PHP extension is not installed Installing build environment: /opt/php5/lib/php/build/ Installing header files: /opt/php5/include/php/ Installing helper programs: /opt/php5/bin/ program: phpize program: php-config program: phpextdist As you can see under Linux the .so and the .lai files are copied but under AIX the .a and the .lai. So if the script is changed so that under AIX the .so file is copied, everything should be alright. Previous Comments: [2005-03-08 15:17:43] tessarek at evermeet dot cx I've tried the latest snapshot on AIX 5.3 ML1 with gcc 3.3.2. The problem still persists: Build complete. (It is safe to ignore warnings about tempnam and tmpnam). vulcan14:[root] /ext/php5-200503081130> make install Installing PHP SAPI module: apache2filter /opt/apache/build/instdso.sh SH_LIBTOOL='/opt/apache/build/libtool' libphp5.la /opt/apache/modules rm -f /opt/apache/modules/libphp5.so /opt/apache/build/libtool --mode=install cp libphp5.la /opt/apache/modules/ cp .libs/libphp5.a /opt/apache/modules/libphp5.a cp .libs/libphp5.lai /opt/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /ext/php5-200503081130/libs' chmod 755 /opt/apache/modules/libphp5.so chmod: /opt/apache/modules/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 . make: 1254-004 The error code from the last command is 1. Stop. I do have the Linux toolbox on AIX installed, but grep is used from the AIX commands. I will have to check, if I can find a GNU grep for AIX. But I don't really think that the grep command is responsible for the error. I don't have any Redhat Linux servers anymore - but I will try to install the latest snapshot on a Fedora Core 3 system. [2005-03-07 22:12:42] [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 I can _NOT_ reproduce this on any of those systems you have. Please test the snapshot and if it does not work: Tell us your gcc version used in every system. (and do you have GNU grep on your AIX system?) [2005-02-04 17:10:46] tessarek at evermeet dot cx Just tested it with the latest snapshot. Unfortunately I get the same error message as before. [2005-02-04 16:07:36] tessarek at evermeet dot cx Sorry, I had no time to try the latest snapshot. I will provide the information within the next couple of hours. [2005-01-26 04:39:14] [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 Also check that your grep is working (install GNU grep!) 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/30160 -- Edit this bug report at http://bugs.php.net/?id=30160&edit=1
#30161 [NoF->Csd]: Segmentation fault with exceptions
ID: 30161 User updated by: guth at fiifo dot u-psud dot fr Reported By: guth at fiifo dot u-psud dot fr -Status: No Feedback +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Linux (mandrake 10) PHP Version: 5.0.1 New Comment: It does not segfault any more. Thanks. Previous Comments: [2005-01-21 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-01-13 02:26:38] [EMAIL PROTECTED] Seems to be fixed, as I can't reproduce it with both 5* CVS snapshots. Please, try latest snapshot. [2004-12-03 22:51:42] guth at fiifo dot u-psud dot fr It still segfaults here... [2004-11-28 14:48:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce the segfault. It doesn't output anything, but doesn't segfault too. [2004-10-12 10:30:33] guth at fiifo dot u-psud dot fr Same behaviour with the latest cvs (php 5.1.0-dev)... 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/30161 -- Edit this bug report at http://bugs.php.net/?id=30161&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: xtrange at gmail dot com Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 New Comment: In the php.ini I put: register_argc_argv = On ...and problem solved! Previous Comments: [2005-03-03 21:26:59] reaper at fudo dot org To follow up to myself: my problem was that in php.ini i had: session.save_handler = user This is not the default. The default setting, that works for me, is: session.save_handler = files It was changed by a fellow admin, and i was unaware of this. Changing the setting back to teh defualt allowed everything to work exactly as it should. [2005-03-03 21:09:30] reaper at fudo dot org I am experiencing the same thing with apache 2.0.53, php 4.3.10, and linux 2.6 (debian). I notice that there is no real fix, and that this problem is persistent. I will investigate further, but is this a real problem or not? If it is, it should be dealt with. [2005-02-27 21:11:00] etamme at softhome dot net I am running a FreeBSD 5.3 system and am having the same problem. I checked my php.ini and session.use_trans_sid = 0 is already there. This is a very important bug.. not having sessions renders nearly all our scripts useless. [2005-02-20 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-19 23:34:41] daniel at mainframe dot ath dot cx > Set "session.use_trans_sid = 0" in your php.ini. Problem > solved! This is not the case - My php.ini has _always_ had use_trans_sid disabled, and yet I am still experiencing the problem 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#29915 [Fbk->Opn]: allocate_new_resource() dangling pointer
ID: 29915
User updated by: test dot 007 at seznam dot cz
Reported By: test dot 007 at seznam dot cz
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: any
PHP Version: 5CVS-2004-08-31 (dev)
New Comment:
--- TSRM/TSRM.c 2004-05-23 19:05:10.0 +0200
+++ TSRM/TSRM.c 2005-03-08 14:36:33.25000 +0100
@@ -260,9 +260,11 @@
static void allocate_new_resource(tsrm_tls_entry
**thread_resources_ptr, THREAD_T thread_id)
{
int i;
+ tsrm_tls_entry *new_resource;
TSRM_ERROR((TSRM_ERROR_LEVEL_CORE, "Creating data structures for
thread %x", thread_id));
(*thread_resources_ptr) = (tsrm_tls_entry *)
malloc(sizeof(tsrm_tls_entry));
+ new_resource = (*thread_resources_ptr);
(*thread_resources_ptr)->storage = (void **) malloc(sizeof(void
*)*id_count);
(*thread_resources_ptr)->count = id_count;
(*thread_resources_ptr)->thread_id = thread_id;
@@ -299,7 +301,7 @@
tsrm_mutex_unlock(tsmm_mutex);
if (tsrm_new_thread_end_handler) {
- tsrm_new_thread_end_handler(thread_id,
&((*thread_resources_ptr)->storage));
+ tsrm_new_thread_end_handler(thread_id,
&(new_resource->storage));
}
}
http://test-007.webpark.cz/php29915.u.patch
As I already explained, it may crash with any scripts, it only needs
many concurrent threads, thus I can't give you a good example script.
Previous Comments:
[2005-03-07 21:35:28] [EMAIL PROTECTED]
Please provide any patches in unified diff format (diff -u)
and also, put them online somewhere where we can download them.
Can you also give some short example script which illustrates the
problem this patch supposedly fixes?
[2005-02-16 16:48:31] test dot 007 at seznam dot cz
Hello Tony,
I found the bug in 4.3.8, but I've checked sources of PHP5 (a link you
provided), and the bug is still present in both 4.x and 5.x.
The bug only occurs if there are more PHP threads running, and you have
a bad luck. It is unrelated to a PHP script, it can crash with any
script(s) => I can't provide you with a particular "crashing" or even
"crashes here" script.
To sum up the problem, allocate_new_resource() uses a resource a
microsecond after it has unlocked a mutex. If another thread removes
the resource during the microsecond, crash.
tsrm_mutex_unlock(tsmm_mutex);
if (tsrm_new_thread_end_handler) {
tsrm_new_thread_end_handler(thread_id,
&((*thread_resources_ptr)->storage));
My patch is obviously harmless, and, believe me, it helps :-)
[2005-02-10 00:24:12] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Please provide a short but complete reproduce script if you still
expirience this issue.
Also, I don't quite understand: you're talking about 5.0.x-CVS, but the
patch you provided is against 4.3.x-CVS.
[2004-08-31 15:30:07] test dot 007 at seznam dot cz
Description:
There's a dangling pointer in TSRM.c: allocate_new_resource(), the
last command.
After
tsrm_mutex_unlock(tsmm_mutex);
the (*thread_resources_ptr) is invalid if you're really unlucky.
Fix:
diff ..\php-4.3.8.orig\TSRM\TSRM.c TSRM\TSRM.c
258a259
> tsrm_tls_entry *new_resource;
261a263
> new_resource = (*thread_resources_ptr);
291c293
< tsrm_new_thread_end_handler(thread_id,
&((*thread_resources_ptr)->storage));
---
> tsrm_new_thread_end_handler(thread_id,
> &((new_resource)->storage));
Long description:
I believe there's a bug even in latest PHP 5, which crashes more
probably in debug build, see TSRM/tsrm.c:
ts_resource_ex() calls while owning a mutex:
allocate_new_resource(&thread_resources->next, thread_id);
That should add a new tsrm_tls_entry* thread_resources to the end of
the linked list.
allocate_new_resource(tsrm_tls_entry **thread_resources_ptr, THREAD_T
thread_id) adds a new linked entry (i.e. sets the list tail's next)
(*thread_resources_ptr) = (tsrm_tls_entry *)
malloc(sizeof(tsrm_tls_entry));
unlock the mutex;
tsrm_new_thread_end_handler(thread_id,
&((*thread_resources_ptr)->storage)); /* 2nd arg equals to
(*thread_resources_ptr) */
If another thread, by accident exactly the thread which has been the
last one in the linked list before the allocate_new_resource() called
malloc(), and whose "next" entry was set there, calls ts_free_thread(),
it free()s the thread_resources of ts_resource_ex() --
in debug build, the (thread_resources->next) vulgo
(*thread_resources_ptr) is set to 0xfeeefeee, and the call
tsrm_new_thread_end_handler(0xfeeefeee) cras
#20490 [Com]: enable versioning not supported on OSX
ID: 20490 Comment by: gatesucks at hotmail dot com Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: *Configuration Issues Operating System: OSX 10.2.2 PHP Version: 4CVS-2002-11-18 (dev) New Comment: kill gates trojan bugs found on scan of pc. they came up when i tried to run windowsxp or any windows shit windows dont work. you suck bill gates we lost our ass and you got yours. Previous Comments: [2004-05-31 20:36:41] lockaby at vt dot edu This is still a problem in 4.3.6. [2003-07-07 02:43:56] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-06-30 19:27:44] [EMAIL PROTECTED] Is it some other flag or is it not needed at all for OSX? [2002-12-01 09:56:00] [EMAIL PROTECTED] I sent Marko a patch on this (I think) and he said he'd double check my work today sometime. Hopefully this can be fit into the 4.3 RC schedule. [2002-11-18 20:09:00] [EMAIL PROTECTED] ./configure --enable-versioning uses -export-sybmols in the ld command, this is not supported under osx and should be disabled in the configure script. -- Edit this bug report at http://bugs.php.net/?id=20490&edit=1
#30160 [Fbk->Opn]: Installing PHP SAPI module fails
ID: 30160 User updated by: tessarek at evermeet dot cx Reported By: tessarek at evermeet dot cx -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: AIX 5.x and Redhat Linux 8.0 / 9 PHP Version: 5.0.0 New Comment: I've tried the latest snapshot on AIX 5.3 ML1 with gcc 3.3.2. The problem still persists: Build complete. (It is safe to ignore warnings about tempnam and tmpnam). vulcan14:[root] /ext/php5-200503081130> make install Installing PHP SAPI module: apache2filter /opt/apache/build/instdso.sh SH_LIBTOOL='/opt/apache/build/libtool' libphp5.la /opt/apache/modules rm -f /opt/apache/modules/libphp5.so /opt/apache/build/libtool --mode=install cp libphp5.la /opt/apache/modules/ cp .libs/libphp5.a /opt/apache/modules/libphp5.a cp .libs/libphp5.lai /opt/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /ext/php5-200503081130/libs' chmod 755 /opt/apache/modules/libphp5.so chmod: /opt/apache/modules/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 . make: 1254-004 The error code from the last command is 1. Stop. I do have the Linux toolbox on AIX installed, but grep is used from the AIX commands. I will have to check, if I can find a GNU grep for AIX. But I don't really think that the grep command is responsible for the error. I don't have any Redhat Linux servers anymore - but I will try to install the latest snapshot on a Fedora Core 3 system. Previous Comments: [2005-03-07 22:12:42] [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 I can _NOT_ reproduce this on any of those systems you have. Please test the snapshot and if it does not work: Tell us your gcc version used in every system. (and do you have GNU grep on your AIX system?) [2005-02-04 17:10:46] tessarek at evermeet dot cx Just tested it with the latest snapshot. Unfortunately I get the same error message as before. [2005-02-04 16:07:36] tessarek at evermeet dot cx Sorry, I had no time to try the latest snapshot. I will provide the information within the next couple of hours. [2005-01-26 04:39:14] [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 Also check that your grep is working (install GNU grep!) [2004-10-22 11:04:52] Bjorn dot Wiberg at its dot uu dot se My libphp5.la does not get overwritten when running 'make install', as it seems. Regarding the "255 error", please see http://bugs.php.net/bug.php?id=30011 for a possible temporary work-around. Best regards, Björn 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/30160 -- Edit this bug report at http://bugs.php.net/?id=30160&edit=1
#32232 [NEW]: Bug with CGI HTTP_POST_VARS
From: crandym2003 at yahoo dot com Operating system: Windows/Unix PHP version: 4.3.10 PHP Bug Type: CGI related Bug description: Bug with CGI HTTP_POST_VARS Description: When using the POST method in a form defined with enctype="multipart/form-data", a single defined hidden form element is lost between form named EditSeries when submit button posts form to submit_series.php. This only happens when text data entered into the TEXTAREA contains a special trademark character ™. I have seen this same bug before with other special characters. The form "submit_series.php" should get (4) form elements in the attached code which are: series_id, destination, series_desc, series_photo. Performing a dump_var $HTTP_SERVER_VAR at the beginnging of submit_series.php only shows (3) because the first form item "series_id" is somehow lost through CGI intrepretation. This doesn't happen unless data containing ™ is entered into the TEXTAREA box. The workaround is to place all hidden entities in the form after the TEXTAREA item or insert a extra hidden blank entity just above the series_id entity. This also does not happen if the enctype="multipart/form-data" is set to text entry only. In this case however, the form contains an input type=file so the multipart/form-data is necessary. Reproduce code: --- Expected result: When you run dump_vars($HTTP_SERVER_VARS) on the submit_series.php form and print them, there should be a total of (4) form items passed which are which are: series_id, destination, series_desc, series_photo. Actual result: -- When you run dump_vars($HTTP_SERVER_VARS) on the submit_series.php form and print them, there area a total of (3) form items passed which are which are: destination, series_desc, series_photo. Somehow, the first defined hidden entity series_id is lost and not defined in $HTTP_SERVER_VARS. This only happens when a special trademark character is entered as text data in the TEXTAREA box. If you move the location of the hidden items somewhere in the form "after" the TEXTAREA item, all elements are forwarded to the next page (i.e., this is a workaround) -- Edit bug report at http://bugs.php.net/?id=32232&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32232&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32232&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32232&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32232&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32232&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32232&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32232&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32232&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32232&r=support Expected behavior: http://bugs.php.net/fix.php?id=32232&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32232&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32232&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32232&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32232&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32232&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32232&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32232&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32232&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32232&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32232&r=mysqlcfg
#30106 [Com]: SOAP cannot not parse 'ref' element. Causes Uncaught SoapFault exception.
ID: 30106 Comment by: h at designplastik dot com Reported By: phpcoder at gmx dot at Status: Assigned Bug Type: SOAP related Operating System: Windows XP PHP Version: 5CVS-2004-09-16 (dev) Assigned To: dmitry New Comment: I'm getting this error to on Gentoo with PHP 5.03. Please fix this :) Previous Comments: [2005-01-11 01:11:19] jfxberns at hotmail dot com Not to be a nag--but is this bug being worked on or just ignored? I just need to know what kind of priority it has or expected timeframe for resolution so I can make decisions for project planning. I realize that this is maintained by contributors--but it helps everybody if we at least know what is happening [2004-12-18 22:02:37] jfxberns at hotmail dot com Is there any status on this bug? I see it has been assigned for a quite a while. I just would like to know if there is a solution on the horizon in the near-term. [2004-10-13 20:39:04] jfxberns at hotmail dot com I am having this problem and I am also having problems with PEAR::SOAP on 5.0.2... I can't wait for a fix--I am dead in the water! Is there an earlier version of 5.0.x (I am using 5.0.2) that does not have this issue--or do I have to roll all the way back to PHP 4.3.x? [2004-10-04 05:49:05] jfxberns at hotmail dot com I am using the release version of 5.0.2 on Linux--same bug, same error message: http://www.precisionreservations.com/PRWebServ/getOtherInformation.asmx?WSDL"; ); ?> [2004-09-16 10:26:54] phpcoder at gmx dot at note: also happens with PHP Version 5.1.0-dev 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/30106 -- Edit this bug report at http://bugs.php.net/?id=30106&edit=1
#29316 [Fbk->Opn]: Executing Stored Procedure with more than one Resultset
ID: 29316
User updated by: patrick dot schutte at gmx dot de
Reported By: patrick dot schutte at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Suse8.2
PHP Version: 5.0.0
New Comment:
nope, Im using php 5.1.0-dev 200508030930 with freetds 0.62.4.
The stored procedure executes 2 Select-Statements. The frist with no
result, the second with 5 lines.
On tsql-console from freetds:
1> use php
2> go
1> exec dbo.dt_mehrfach
2> go
id produktname tagesbedarf kvnr
id produktname tagesbedarf kvnr
17 Schnecken 1 Tüten / Tag 2135860009
18 Colorado1 Tüte / Monat NULL
19 Gummibärchen2 Tüten / tgl. NULL
20 TestNULL
16 Phantasia 12 Tüten / WocheNULL
(return status = 0)
the first line "id produktname tagesbedarf kvnr" show no
matches for the first select.
PHP:
echo "Select1: ".mssql_num_rows($rs);
mssql_next_result($rs);
echo "Select2: ".mssql_num_rows($rs);
Returns
5
5
instead 0,5 still after updating php with latetst snap.
The Problem still exists.
Previous Comments:
[2005-03-06 20:51:38] [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
[2004-07-22 10:35:13] patrick dot schutte at gmx dot de
Description:
I've written stored Procedures that returns 2 and more Resultsets
(Select-Querys). If one of theese Results doesn't have any Matches I
get the next one instead.
System: Suse8.2, freetds 0.62.3 ./configure ... --with-mssql
freetds with TDS-Version 7.0 and MSSQL-Server2000. Same Code works fine
with WindowsNT4.0
Reproduce code:
---
CREATE PROCEDURE [dbo].[dt_mehrfach] AS
-- first Query: no match
SELECT * FROM tbl_haribo
WHERE id=1
-- second Query: 15 matches
SELECT * FROM tbl_haribo
PHP:
$p=mssql_init("dt_mehrfach);
$result=mssql_execute($p);
echo mssql_num_rows($result)."\n";
mssql_next_result($result);
echo mssql_num_rows($result);
Expected result:
0
15
would be ok
Actual result:
--
but I get
15
15
--
Edit this bug report at http://bugs.php.net/?id=29316&edit=1
#32223 [Opn]: weird behaviour of pg_last_notice
ID: 32223 User updated by: valiak at gmail dot com Reported By: valiak at gmail dot com Status: Open Bug Type: PostgreSQL related Operating System: Irrelevant PHP Version: 5.0.3 New Comment: if you switch the places of include_once and define there is no bug there is no difference in the behaviour if include_once is changed to include or require_once or require Previous Comments: [2005-03-08 13:08:12] [EMAIL PROTECTED] I'm reproducing the bug too. I'm using PHP 5.0.0 (on Windows) and PostgreSQL 7.4.7 (on Linux): PHP 5.0.0 (cli) (built: Jul 13 2004 21:39:58) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.0, Copyright (c) 1998-2004 Zend Technologies Even without the exceptions pg_last_notice() doesn't work as expected. Try the following code: It gives me bool(false) on my windows server (PHP 5) and string(14) "NOTICE: 1" on a linux server (PHP 4.3.9). If I comment the include line, or move the commands outside of the function body, it works just fine. [2005-03-08 12:22:44] valiak at gmail dot com I reproduced the problem on Darwin ceco.local 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power Macintosh powerpc with the same php and postgresql installed [2005-03-08 08:59:31] valiak at gmail dot com the problem still exists :-( [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php test.php 1 [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php -v PHP 5.1.0-dev (cli) (built: Mar 8 2005 09:54:24) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies [2005-03-07 20:06:21] [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-03-07 18:13:54] valiak at gmail dot com Description: i've tried to localize to as smallest code as I could the correct result happens even if you comment the include line or the global directive or not using exceptions ... (there are few other modifications too) it happens with the cli version and with the apache module version [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php -v PHP 5.0.3 (cli) (built: Mar 2 2005 13:13:40) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies compiled with ./configure --with-gettext --with-oci8 --with-apxs=/usr/bin/apxs --with-gd --with-pgsql --with-readline --with-zlib --with-mysql=/usr --with- jpeg-dir --with-png-dir --enable-mbstring --enable-sockets --enable-pcntl --enable-sigchild --with-exec-dir=/usr/bin --with-config-file-path= /etc/php5 pgsql PostgreSQL Support => enabled PostgreSQL(libpq) Version => 8.0.1 Multibyte character support => enabled SSL support => disabled Active Persistent Links => 0 Active Links => 0 Directive => Local Value => Master Value pgsql.allow_persistent => Off => Off pgsql.auto_reset_persistent => Off => Off pgsql.ignore_notice => Off => Off pgsql.log_notice => Off => Off pgsql.max_links => Unlimited => Unlimited pgsql.max_persistent => Unlimited => Unlimited if some more info is needed tell me what to do? Reproduce code: --- [EMAIL PROTECTED] ~/tmp/pg_last_notice $ cat test.inc.php [EMAIL PROTECTED] ~/tmp/pg_last_notice $ cat test.php getMessage(), 1; } ?> Expected result: [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php test.php NOTICE: 11 Actual result: -- [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php test.php 1 -- Edit this bug report at http://bugs.php.net/?id=32223&edit=1
#32223 [Opn]: weird behaviour of pg_last_notice
ID: 32223 User updated by: valiak at gmail dot com Reported By: valiak at gmail dot com Status: Open Bug Type: PostgreSQL related Operating System: debian linux sarge PHP Version: 5.0.3 New Comment: I reproduced the problem on Darwin ceco.local 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power Macintosh powerpc with the same php and postgresql installed Previous Comments: [2005-03-08 08:59:31] valiak at gmail dot com the problem still exists :-( [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php test.php 1 [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php -v PHP 5.1.0-dev (cli) (built: Mar 8 2005 09:54:24) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies [2005-03-07 20:06:21] [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-03-07 18:13:54] valiak at gmail dot com Description: i've tried to localize to as smallest code as I could the correct result happens even if you comment the include line or the global directive or not using exceptions ... (there are few other modifications too) it happens with the cli version and with the apache module version [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php -v PHP 5.0.3 (cli) (built: Mar 2 2005 13:13:40) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies compiled with ./configure --with-gettext --with-oci8 --with-apxs=/usr/bin/apxs --with-gd --with-pgsql --with-readline --with-zlib --with-mysql=/usr --with- jpeg-dir --with-png-dir --enable-mbstring --enable-sockets --enable-pcntl --enable-sigchild --with-exec-dir=/usr/bin --with-config-file-path= /etc/php5 pgsql PostgreSQL Support => enabled PostgreSQL(libpq) Version => 8.0.1 Multibyte character support => enabled SSL support => disabled Active Persistent Links => 0 Active Links => 0 Directive => Local Value => Master Value pgsql.allow_persistent => Off => Off pgsql.auto_reset_persistent => Off => Off pgsql.ignore_notice => Off => Off pgsql.log_notice => Off => Off pgsql.max_links => Unlimited => Unlimited pgsql.max_persistent => Unlimited => Unlimited if some more info is needed tell me what to do? Reproduce code: --- [EMAIL PROTECTED] ~/tmp/pg_last_notice $ cat test.inc.php [EMAIL PROTECTED] ~/tmp/pg_last_notice $ cat test.php getMessage(), 1; } ?> Expected result: [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php test.php NOTICE: 11 Actual result: -- [EMAIL PROTECTED] ~/tmp/pg_last_notice $ php test.php 1 -- Edit this bug report at http://bugs.php.net/?id=32223&edit=1
#30959 [NoF->Opn]: __call does not return by reference
ID: 30959
User updated by: joel at zmail dot pt
Reported By: joel at zmail dot pt
-Status: No Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
-PHP Version: 5.0.2
+PHP Version: php5-200503080930
New Comment:
I've just tested with latest php 5 (php5-200503080930)
and the problem is not solved.
Previous Comments:
[2005-03-08 01:00:09] 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-28 21:20:25] [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
[2004-12-02 12:43:27] joel at zmail dot pt
Description:
__call doesn't return by reference
Reproduce code:
---
class A{
private $x = 123;
public function & __call($m,$a){
return $this->x;
}
}
$a = new A();
$x = & $a->UndefMethod();
$x = 789;
$y = & $a->UndefMethod();
Expected result:
$y should be 789, but it is 123
--
Edit this bug report at http://bugs.php.net/?id=30959&edit=1
#32231 [NEW]: zend_objects_clone_obj ( Exception ) => segfault
From: bugs at niluje dot net
Operating system: Debian linux x86
PHP version: 5.0.3
PHP Bug Type: Reproducible crash
Bug description: zend_objects_clone_obj ( Exception ) => segfault
Description:
var_dump() on an exception crashes php5.
#0 0xb57f0c0e in zend_objects_clone_obj () from
/usr/lib/apache/1.3/libphp5.so
(gdb) bt
#0 0xb57f0c0e in zend_objects_clone_obj () from
/usr/lib/apache/1.3/libphp5.so
#1 0xb577f00d in php_var_dump () from /usr/lib/apache/1.3/libphp5.so
#2 0xb577ee3f in url_adapt () from /usr/lib/apache/1.3/libphp5.so
#3 0xb57e5986 in zend_hash_apply_with_arguments () from
/usr/lib/apache/1.3/libphp5.so
#4 0xb577f0b7 in php_var_dump () from /usr/lib/apache/1.3/libphp5.so
#5 0xb577f1d6 in zif_var_dump () from /usr/lib/apache/1.3/libphp5.so
#6 0xb581b851 in zend_do_fcall_common_helper () from
/usr/lib/apache/1.3/libphp5.so
#7 0xb581bfd0 in zend_do_fcall_handler () from
/usr/lib/apache/1.3/libphp5.so
#8 0xb580024f in execute () from /usr/lib/apache/1.3/libphp5.so
#9 0xb57df043 in zend_execute_scripts () from
/usr/lib/apache/1.3/libphp5.so
#10 0xb57a8c55 in php_execute_script () from
/usr/lib/apache/1.3/libphp5.so
#11 0xb5824755 in apache_php_module_main () from
/usr/lib/apache/1.3/libphp5.so
#12 0xb582537e in apache_php_module_main () from
/usr/lib/apache/1.3/libphp5.so
#13 0xb58253e5 in apache_php_module_main () from
/usr/lib/apache/1.3/libphp5.so
#14 0x080553c3 in ap_invoke_handler ()
#15 0x08068465 in ap_some_auth_required ()
#16 0x08068614 in ap_process_request ()
#17 0x08060bd2 in ap_child_terminate ()
#18 0x08060de7 in ap_child_terminate ()
#19 0x080610c7 in ap_child_terminate ()
#20 0x08061a48 in ap_child_terminate ()
#21 0x08061ff8 in main ()
Reproduce code:
---
catch (Exception $e) {
var_dump ($e);
}
--
Edit bug report at http://bugs.php.net/?id=32231&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32231&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32231&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32231&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32231&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32231&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32231&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32231&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32231&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32231&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32231&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32231&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32231&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32231&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32231&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32231&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32231&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32231&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32231&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32231&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32231&r=mysqlcfg
#29886 [Opn->Fbk]: segment fault when processing curl output with "wrapper-registered" stream
ID: 29886 Updated by: [EMAIL PROTECTED] Reported By: public at grik dot net -Status: Open +Status: Feedback Bug Type: cURL related Operating System: Linux PHP Version: 5CVS-2004-08-30 (dev) New Comment: Set to feedback until real feedback has been provided. Previous Comments: [2005-03-08 09:35:39] public at grik dot net Thank you, I'll try with the new version today. [2005-03-07 21:33:34] [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 I can't get it to crash.. [2004-08-30 02:08:19] public at grik dot net Description: I register a wrapper, create a stream and pass the pointer to the curl_setopt to process CURL output. When amount of data returned by CURL exeeds 8192 bytes (size of the CURL buffer), PHP ends with Segmentation fault. I could not reach the crash using fwrite(). Similar problem was in PHP 4.3.3, in 4.3.7 everything works fine. I detected this problem again in 5.0.0 and replicated it in the latest stable CSV. I do not know if it happens upon shutdown and if it is relevant to bug #29358. This happens with CURL only. Reproduce code: --- The sample code can be found at: http://www.grik.net/sample.phps Can be run form command line: php -f sample.php Expected result: In PHP 4.3.7 this script would output the amount of bytes obtained from CURL: 8192 8192 ... Actual result: -- In PHP 5.0.0: 8192 8192 Segmentation fault Backtrace (I am not enough good with gdb, could not locate): (gdb) bt #0 0x081f714a in _zval_copy_ctor (zvalue=0x8344684, __zend_filename=0x8273780 "/usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c", __zend_lineno=3001) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_variables.c:136 #1 0x08227ab6 in zend_send_by_var_helper (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3001 #2 0x08221824 in zend_send_var_handler (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3061 #3 0x0821cb76 in execute (op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:1400 #4 0x081ed157 in zend_call_function (fci=0xbfffb370, fci_cache=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:835 #5 0x081ec1a9 in call_user_function_ex (function_table=0x0, object_pp=0x82e5f00, function_name=0xbfffb400, retval_ptr_ptr=0xbfffb3fc, param_count=1, params=0xbfffb3f0, no_separation=0, symbol_table=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:550 #6 0x081cd58c in php_userstreamop_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/userspace.c:459 #7 0x081c539d in _php_stream_write_buffer (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:889 #8 0x081c561f in _php_stream_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:1000 #9 0x081c7c66 in stream_cookie_writer (cookie=0x83446c4, buffer=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., size=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/cast.c:96 #10 0x42062019 in _IO_cookie_write () from /lib/tls/libc.so.6 #11 0x4206d09e in new_do_write () from /lib/tls/libc.so.6 #12 0x4206d036 in _IO_new_do_write () from /lib/tls/libc.so.6 #13 0x4206d7b8 in _IO_new_file_overflow () from /lib/tls/libc.so.6 #14 0x4206e220 in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #15 0x42062a62 in fwrite () from /lib/tls/libc.so.6 #16 0x40027de3 in last_use () from /usr/lib/20040412/curl.so #17 0x4064c139 in Curl_client_write (data=0x834c50c, type=1, ptr=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., len=1448) at sendf.c:337 #18 0x40663fcf in Curl_httpchunk_read (conn=0x8344f3c, datap=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes
#32230 [Opn->Bgs]: single quotes
ID: 32230 Updated by: [EMAIL PROTECTED] Reported By: amal_omairi at yahoo dot com -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Windows XP Pro PHP Version: 4.3.10 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. Even if you think it is not a bug, we often know better than you, please consult the support channels first before even considering to reopen this report. Thank you for your interest in PHP. . Previous Comments: [2005-03-08 09:06:05] amal_omairi at yahoo dot com Description: i work on a content management area system. where user text inserted to a table in MySQL database and then reteived for preview in atext area. but when user types a single quote it is previewed as double quotes. the magic_quotes_gpc is on, and magic_quotes_sybase is off. addslashes is not used but stripslashes is used when retrieval from databse. please help. Reproduce code: --- Expected result: preview single quote. Actual result: -- previwes double qoutes instead. -- Edit this bug report at http://bugs.php.net/?id=32230&edit=1
#32228 [Opn->Bgs]: broken email with attachments
ID: 32228 Updated by: [EMAIL PROTECTED] Reported By: vlada dot misic at service24 dot at -Status: Open +Status: Bogus Bug Type: Mail related Operating System: w2k/xp/win 2003 PHP Version: 4.3.9 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. Even if you think it is not a bug, we often know better than you, please consult the support channels first before even considering to reopen this report. Thank you for your interest in PHP. You're abusing the header parameter for email content (body). Previous Comments: [2005-03-08 01:53:46] vlada dot misic at service24 dot at Description: The problem is that mail function does not parse correct parameters when sending emails. It does not prints out all new line characters which are sent in the header. I marked those missing \n in the example. I also found the same problem here http://aspn.activestate.com/ASPN/Mail/Message/php-windows/2508303 I made a lot of tests and seem to be general problem on any windows platform or version of PHP. When I open the source of broken email and just add those four missing \n in the ascii editor the email becomes correct and attacment also. I also noticed that all \n chars missing in the message body. So I think it is general problem with \n chars in the process of generating email message. Reproduce code: --- $header.= "Content-Type: multipart/mixed; boundary=$uid\n\n"; $header.= "--$uid\n"; $header.= "Content-Type: text/plain;\n"; $header.= "\t"; $header.= "charset=\"iso-8859-1\"\n"; $header.= "Content-Transfer-Encoding: quoted-printable\n\n"; //the second \n is missing $header.= "$message\n\n"; //the second \n is missing $header.= "--$uid\n"; $header.= "Content-Type: application/msword;\n"; $header.= "\t"; $header.= "name=\"invoice.doc\"\n"; $header.= "Content-Transfer-Encoding: base64\n"; $header.= "Content-Disposition: attachment;\n"; $header.= "\t"; $header.= "filename=\"invoice.doc\"\n\n"; //the second \n is missing $invoice= chunk_split(base64_encode($invoice)); $header.= "$invoice\n\n"; //the second \n is missing $header.= "--$uid\n"; Expected result: Content-Type: multipart/mixed; boundary=_NextPart_5901498AE5B7167A32D274DEED0E3965 Return-Path: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> X-OriginalArrivalTime: 08 Mar 2005 00:06:57.0578 (UTC) FILETIME=[BE4B58A0:01C52372] --_NextPart_5901498AE5B7167A32D274DEED0E3965 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some content - first line some content - third line (one is empty) --_NextPart_5901498AE5B7167A32D274DEED0E3965 Content-Type: application/msword; name="invoice.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="invoice.doc" 0M8R4KGxGuEAPgADAP7/CQAGAAACpwAA .. not complete attachment since it is irrelevant . AAA= --_NextPart_5901498AE5B7167A32D274DEED0E3965 Actual result: -- Content-Type: multipart/mixed; boundary=_NextPart_5901498AE5B7167A32D274DEED0E3965 Return-Path: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> X-OriginalArrivalTime: 08 Mar 2005 00:06:57.0578 (UTC) FILETIME=[BE4B58A0:01C52372] --_NextPart_5901498AE5B7167A32D274DEED0E3965 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some content - first line some content - third line (one is empty) --_NextPart_5901498AE5B7167A32D274DEED0E3965 Content-Type: application/msword; name="invoice.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="invoice.doc" 0M8R4KGxGuEAPgADAP7/CQAGAAACpwAA .. not complete attachment since it is irrelevant . AAA= --_NextPart_5901498AE5B7167A32D274DEED0E3965 -- Edit this bug report at http://bugs.php.net/?id=32228&edit=1
#32217 [Asn]: html_errors don't contain clickable function names
ID: 32217
User updated by: m at tacker dot org
Reported By: m at tacker dot org
Status: Assigned
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-07)
Assigned To: andi
New Comment:
I see - It works with fatal errors.
I included a call to require_once('somefile'); in my example and this
produces an error message with a link.
Previous Comments:
[2005-03-07 20:08:11] [EMAIL PROTECTED]
Reclassified and assigned to Andi who can decide what to do. :) This is
not exactly a bug but a feature request..
[2005-03-07 19:57:55] [EMAIL PROTECTED]
This is cause by the fact that the zend_wrong_param_count() does NOT
use the php_error_docref() function..
[2005-03-07 13:04:43] m at tacker dot org
Description:
Even if html_errors, docref_root and docref_ext are set according to
the description, no links are contained in the error messages.
Online test: http://www.tacker.org/html_errors.php
Online test source: http://www.tacker.org/html_errors.phps
Reproduce code:
---
ini_set('html_errors', 'On');
ini_set('docref_root', '/php-doc/');
ini_set('docref_ext', '.html');
$test = str_replace();
Expected result:
str_replace() beeing linked to /php-doc/functions.str_replace.html
Actual result:
--
Warning: Wrong parameter count for str_replace() in
/mnt/store/www/tacker.org/htdoc/html_errors.php on line
25
--
Edit this bug report at http://bugs.php.net/?id=32217&edit=1
#32216 [Fbk->Opn]: mysql & iodbc support
ID: 32216 User updated by: paolo at ahead dot it Reported By: paolo at ahead dot it -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: linux i386 PHP Version: 5.0.3 New Comment: [EMAIL PROTECTED] site]# gdb /dati/inetpub/php/bin/php GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -f test.php Starting program: /dati/inetpub/php/bin/php -f test.php Error while mapping shared library sections: : Success. Error while reading shared library symbols: : No such file or directory. [Thread debugging using libthread_db enabled] [New Thread -150633024 (LWP 6217)] Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -150633024 (LWP 6217)] 0x00223e51 in my_SQLPrepare () from /usr/lib/libmyodbc3.so (gdb) bt #0 0x00223e51 in my_SQLPrepare () from /usr/lib/libmyodbc3.so #1 0x00220be3 in SQLExecDirect () from /usr/lib/libmyodbc3.so #2 0x001d45f1 in SQLExecDirect_Internal (hstmt=0x93a1420, szSqlStr=0x939d5cc, cbSqlStr=-3, waMode=0 '\0') at execute.c:374 #3 0x001d47e4 in SQLExecDirect (hstmt=0x93a1420, szSqlStr=0x939d5cc "select 1", cbSqlStr=-3) at execute.c:443 #4 0x080c3ef9 in zif_odbc_exec (ht=2, return_value=0x93a215c, this_ptr=0x0, return_value_used=1) at /dati/inetpub/src/php-5.0.3/ext/odbc/php_odbc.c:1309 #5 0x081bf75e in zend_do_fcall_common_helper (execute_data=0xfefd2120, opline=0x93a1c88, op_array=0x939d87c) at /dati/inetpub/src/php-5.0.3/Zend/zend_execute.c:2711 #6 0x081bcd62 in execute (op_array=0x939d87c) at /dati/inetpub/src/php-5.0.3/Zend/zend_execute.c:1400 #7 0x081a317b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /dati/inetpub/src/php-5.0.3/Zend/zend.c:1069 #8 0x081754b4 in php_execute_script (primary_file=0xfefd44b0) at /dati/inetpub/src/php-5.0.3/main/main.c:1628 #9 0x081c625a in main (argc=3, argv=0xfefd4574) at /dati/inetpub/src/php-5.0.3/sapi/cgi/cgi_main.c:1568 (gdb) Previous Comments: [2005-03-07 20:09:22] [EMAIL PROTECTED] 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 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. [2005-03-07 11:49:40] paolo at ahead dot it Description: on my linux box fedora core2 with kernel 2.6.5-1.358 i have a segmentation fault on code reported if i compile php with mysql support. if i remove mysql support with --without-mysql all work correctly. on windows 2003 work with both mysql & iodbc support. this is my configuration: ./configure --with-mysql=/dati/inetpub/mysql --prefix=/dati/inetpub/php --with-gd --enable-gd-native-ttf --enable-sockets --enable-pcntl --without-pear --with-zlib --with-jpeg-dir=/dati/inetpub/src/jpeg-6b --with-curl --with-ttf --with-freetype-dir --with-imap=/dati/inetpub/src/imap-2004a --with-iodbc=/dati/inetpub/iodbc --with-kerberos Reproduce code: --- Expected result: 1 Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=32216&edit=1
#29886 [Fbk->Opn]: segment fault when processing curl output with "wrapper-registered" stream
ID: 29886 User updated by: public at grik dot net Reported By: public at grik dot net -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 5CVS-2004-08-30 (dev) New Comment: Thank you, I'll try with the new version today. Previous Comments: [2005-03-07 21:33:34] [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 I can't get it to crash.. [2004-08-30 02:08:19] public at grik dot net Description: I register a wrapper, create a stream and pass the pointer to the curl_setopt to process CURL output. When amount of data returned by CURL exeeds 8192 bytes (size of the CURL buffer), PHP ends with Segmentation fault. I could not reach the crash using fwrite(). Similar problem was in PHP 4.3.3, in 4.3.7 everything works fine. I detected this problem again in 5.0.0 and replicated it in the latest stable CSV. I do not know if it happens upon shutdown and if it is relevant to bug #29358. This happens with CURL only. Reproduce code: --- The sample code can be found at: http://www.grik.net/sample.phps Can be run form command line: php -f sample.php Expected result: In PHP 4.3.7 this script would output the amount of bytes obtained from CURL: 8192 8192 ... Actual result: -- In PHP 5.0.0: 8192 8192 Segmentation fault Backtrace (I am not enough good with gdb, could not locate): (gdb) bt #0 0x081f714a in _zval_copy_ctor (zvalue=0x8344684, __zend_filename=0x8273780 "/usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c", __zend_lineno=3001) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_variables.c:136 #1 0x08227ab6 in zend_send_by_var_helper (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3001 #2 0x08221824 in zend_send_var_handler (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3061 #3 0x0821cb76 in execute (op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:1400 #4 0x081ed157 in zend_call_function (fci=0xbfffb370, fci_cache=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:835 #5 0x081ec1a9 in call_user_function_ex (function_table=0x0, object_pp=0x82e5f00, function_name=0xbfffb400, retval_ptr_ptr=0xbfffb3fc, param_count=1, params=0xbfffb3f0, no_separation=0, symbol_table=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:550 #6 0x081cd58c in php_userstreamop_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/userspace.c:459 #7 0x081c539d in _php_stream_write_buffer (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:889 #8 0x081c561f in _php_stream_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:1000 #9 0x081c7c66 in stream_cookie_writer (cookie=0x83446c4, buffer=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., size=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/cast.c:96 #10 0x42062019 in _IO_cookie_write () from /lib/tls/libc.so.6 #11 0x4206d09e in new_do_write () from /lib/tls/libc.so.6 #12 0x4206d036 in _IO_new_do_write () from /lib/tls/libc.so.6 #13 0x4206d7b8 in _IO_new_file_overflow () from /lib/tls/libc.so.6 #14 0x4206e220 in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #15 0x42062a62 in fwrite () from /lib/tls/libc.so.6 #16 0x40027de3 in last_use () from /usr/lib/20040412/curl.so #17 0x4064c139 in Curl_client_write (data=0x834c50c, type=1, ptr=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., len=1448) at sendf.c:337 #18 0x40663fcf in Curl_httpchunk_read (conn=0x8344f3c, datap=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., datalen=1448, wrotep=0xbfffb880) at http_chunks.c:186 #19 0x40660fd7 in Curl_readwrite (conn=0x8344f3c, done=0xbfffb8df "") at transfer.c:980 #20 0x40661f56 in Tran
#32230 [NEW]: single quotes
From: amal_omairi at yahoo dot com Operating system: Windows XP Pro PHP version: 4.3.10 PHP Bug Type: Output Control Bug description: single quotes Description: i work on a content management area system. where user text inserted to a table in MySQL database and then reteived for preview in atext area. but when user types a single quote it is previewed as double quotes. the magic_quotes_gpc is on, and magic_quotes_sybase is off. addslashes is not used but stripslashes is used when retrieval from databse. please help. Reproduce code: --- Expected result: preview single quote. Actual result: -- previwes double qoutes instead. -- Edit bug report at http://bugs.php.net/?id=32230&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32230&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32230&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32230&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32230&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32230&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32230&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32230&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32230&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32230&r=support Expected behavior: http://bugs.php.net/fix.php?id=32230&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32230&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32230&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32230&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32230&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32230&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32230&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32230&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32230&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32230&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32230&r=mysqlcfg
