#21427 [NEW]: Function xslt_set_encoding() undefined
From: [EMAIL PROTECTED] Operating system: WindowsXP PHP version: 4.3.0 PHP Bug Type: XSLT related Bug description: Function xslt_set_encoding() undefined I am using Apache 2.0.43 and I have just upgraded to PHP 4.3.0 and my scripts now fail with the error message: "Call to undefined function: xslt_set_encoding()" I have downloaded the latest sablotron version from www.gingerall.com, but the error persists. Could it be that the Windows binary was not compioled with the "with encoding" option? -- Edit bug report at http://bugs.php.net/?id=21427&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21427&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21427&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21427&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21427&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21427&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21427&r=support Expected behavior: http://bugs.php.net/fix.php?id=21427&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21427&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21427&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21427&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21427&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21427&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21427&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21427&r=gnused
Bug #16438 Updated: Segmentation fault
ID: 16438
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Red Hat Linux release 6.2
PHP Version: 4.1.2
New Comment:
chatv2.crash.php
='$starttime' and
JoinTime<='$stoptime' and Chat_ID > 0 order by Chat_ID, JoinTime";
$chatsession = array();
if($qid1 = SQL_Query($q1)) {
while($r = mysql_fetch_assoc($qid1)) {
$id = strtolower($r['Eyeball_ID']);
$chatid = $r['Chat_ID'];
if (!isset($chatsession[$chatid])) {
$chatsession[$chatid] = array();
$chatsession[$chatid]['Begin'] = $r['JointTime'];
$chatsession[$chatid]['End'] = $r['LeaveTime'];
} else if ($r['LeaveTime'] < $chatsession[$chatid]['End'])
$chatsession[$chatid]['End'] = $r['LeaveTime'];
echo count($chatsession)."\n";
}
$chats = count($chatsession);
if ($chats > 0) foreach($chatsession as $r) {
$logintm = MakeTM($r["Begin"]);
if($r["End"] !="")
$duration = MakeTM($r["End"]) - $logintm;
else
$duration = $curtm - $logintm;
$duration = $duration < 0? 0 : $duration>86400? 21600 :
$duration);
$chatseconds += $duration;
if($duration <= 60) $chats_le1 ++;
else if($duration <= 600) $chats_le10 ++;
else if($duration <= 1800) $chats_le30 ++;
else $chats_gt30 ++;
}
}
Previous Comments:
[2002-04-05 12:50:59] [EMAIL PROTECTED]
Please provide a short reproducing script.
Derick
[2002-04-05 12:48:43] [EMAIL PROTECTED]
1. there're more than 65536 rows. use php 4.1.2 it crashes after 65538
2. tried with PHP 4.2.0RC2, program got "Segmentation fault" again.
crashed after 65534
configuration
=
./configure --with-mysql --with-socket --enable-trans-sid --with-progel
--with-gd --enable-discard-path --prefix=/mnt/nfshome/tony/php
debug info
==
$ gdb bin/php /home/tony/stats/bin/core
GNU gdb 19991004
Copyright 1998 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"...
Core was generated by `bin/php /home/tony/stats/bin/chatv2.crash.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /usr/lib/libgd.so.1...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
#0 0x80e7eb1 in zend_hash_add_or_update (ht=0xa51f04c, arKey=0x818150c
"End",
nKeyLength=4, pData=0xbfffce10, nDataSize=4, pDest=0xbfffce1c,
flag=1)
at zend_hash.c:275
275 ht->arBuckets[nIndex] = p;
(gdb) bt
#0 0x80e7eb1 in zend_hash_add_or_update (ht=0xa51f04c, arKey=0x818150c
"End",
nKeyLength=4, pData=0xbfffce10, nDataSize=4, pDest=0xbfffce1c,
flag=1)
at zend_hash.c:275
#1 0x810362c in zend_fetch_dimension_address_inner (ht=0xa51f04c,
op2=0x8184a80,
Ts=0xbfffce84, type=1) at ./zend_execute.c:627
#2 0x80fb8fb in zend_fetch_dimension_address (result=0x8184a60,
op1=0x8184a70,
op2=0x8184a80, Ts=0xbfffce84, type=1) at ./zend_execute.c:762
#3 0x80fd912 in execute (op_array=0x817ca84) at ./zend_execute.c:1274
#4 0x80e54b7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:810
#5 0x8062eaa in php_execute_script (primary_file=0xba74) at
main.c:1381
#6 0x8060f99 in main (argc=2, argv=0xbad4) at cgi_main.c:785
(gdb)
[2002-04-04 21:08:09] [EMAIL PROTECTED]
First, please try with PHP 4.2.0RC2 from http://www.php.net/~derick/
Second question is, how many rows are there in the
array causing the crash?
#19600 [NEW]: requires full pathname
From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version: 4.2.3
PHP Bug Type: Sablotron XSL
Bug description: requires full pathname
I am using Windows XP, PHP 4.2.3, Apache 1.3.26
I am using XSLT to produce HTML output. The code I use is as follows:
$arg_buffer = array("/xml" => $xml_string, "/xslt" => $xsl_string);
$result = xslt_process($xp, "arg:/xml", "arg:/xslt", NULL, $arg_buffer,
$params)))
My xsl file contains as 'include' statement which points to a file which
exists in the same folder as the PHP script.
I initially tried it as but it
produced this error:
'arg:/pagination.xsl' not found (error code: 65)
I then tried it with and got
this error:
cannot open file '/pagination.xsl' (error code: 4)
It only works if I enter the full path, as in
It is very inconvenient to have to specify the full pathname in every
statement. Should it not first look in the current
directory?
This may be more of an enhancement request than a bug.
--
Edit bug report at http://bugs.php.net/?id=19600&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19600&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19600&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19600&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19600&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19600&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19600&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19600&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19600&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19600&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19600&r=globals
#19641 [NEW]: test "position()mod 2" not being processed correctly
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.2.3 PHP Bug Type: XSLT related Bug description: test "position()mod 2" not being processed correctly I have the following code in my XSL file: odd even It's purpose is to set the class of the element depending on whether the row is odd-numbered or even-numbered so that the background colour can be set accordingly. This works perfectly with the MSXML parser, but with PHP the first row comes out as "odd" (correct), but all subsequent rows come out as "even". The only way I can get it to work is to modify the test to "position()mod 2-1", but this should not be necessary. -- Edit bug report at http://bugs.php.net/?id=19641&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19641&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19641&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19641&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19641&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19641&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19641&r=support Expected behavior: http://bugs.php.net/fix.php?id=19641&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19641&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19641&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19641&r=globals
#19600 [Fbk->Opn]: requires full pathname
ID: 19600
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: XSLT related
Operating System: Windows XP
PHP Version: 4.2.3
New Comment:
That works, thank you. Problem solved.
Previous Comments:
[2002-10-03 04:28:57] [EMAIL PROTECTED]
Please try http://www.php.net/manual/en/function.xslt-set-base.php to
solve your problem.
Regards, Kai
[2002-09-25 13:53:10] [EMAIL PROTECTED]
I am using Windows XP, PHP 4.2.3, Apache 1.3.26
I am using XSLT to produce HTML output. The code I use is as follows:
$arg_buffer = array("/xml" => $xml_string, "/xslt" => $xsl_string);
$result = xslt_process($xp, "arg:/xml", "arg:/xslt", NULL, $arg_buffer,
$params)))
My xsl file contains as 'include' statement which points to a file
which exists in the same folder as the PHP script.
I initially tried it as but it
produced this error:
'arg:/pagination.xsl' not found (error code: 65)
I then tried it with and
got this error:
cannot open file '/pagination.xsl' (error code: 4)
It only works if I enter the full path, as in
It is very inconvenient to have to specify the full pathname in every
statement. Should it not first look in the current
directory?
This may be more of an enhancement request than a bug.
--
Edit this bug report at http://bugs.php.net/?id=19600&edit=1
Bug #14397 Updated: Wrong results when reading a float
ID: 14397 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Sybase (dblib) related Operating System: Linux PHP Version: 4.0.6 New Comment: I have the same error with PHP4.1.1. Even though I use float(16) instead of float(8), or use decimal(15,5), I got the wrong display when fetch a float/decimal/double field. Previous Comments: [2002-01-28 10:41:54] [EMAIL PROTECTED] No feedback. [2002-01-07 02:35:05] [EMAIL PROTECTED] Can you reproduce this error with PHP 4.1.1? [2001-12-10 02:36:19] [EMAIL PROTECTED] I found that the wrong float results happen with float(8) but NOT with float(16) !!! [2001-12-10 02:05:59] [EMAIL PROTECTED] I have successfully written a float number into a sybase system - that I can display correctly with isql. But when reading with php I got back 0 oder some strange numbers as 6.784567 instead of teh correct float number. -- Edit this bug report at http://bugs.php.net/?id=14397&edit=1
Bug #16438: Segmentation fault
From: [EMAIL PROTECTED] Operating system: Red Hat Linux release 6.2 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: Segmentation fault configuration line == ./configure --with-mysql --with-socket --enable-trans-sid --with-progel --with-gd --enable-discard-path description === chatv2.php - daily batch program, read database (MySQL), generate statistics, write database. As the records increased, it's occurs more often. debug info == $ gdb /usr/local/bin/php /home/tony/stats/bin/core GNU gdb 19991004 Copyright 1998 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"... Core was generated by `/usr/local/bin/php /home/tony/stats/bin/chatv2.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) run /home/tony/stats/bin/chatv2.php Starting program: /usr/local/bin/php /home/tony/stats/bin/chatv2.php X-Powered-By: PHP/4.1.2 Content-type: text/html Process day : 2002-04-03 Program received signal SIGSEGV, Segmentation fault. 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) bt #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 #1 0x8070996 in php_mysql_fetch_hash (ht=1, return_value=0xa4feb24, this_ptr=0x0, return_value_used=1, result_type=1, expected_args=1) at php_mysql.c:1590 #2 0x8070b68 in zif_mysql_fetch_assoc (ht=1, return_value=0xa4feb24, this_ptr=0x0, return_value_used=1) at php_mysql.c:1664 #3 0x81057e6 in execute (op_array=0x8184f54) at ./zend_execute.c:1590 #4 0x80ebcb6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #5 0x8062aba in php_execute_script (primary_file=0xba74) at main.c:1307 #6 0x8060e6b in main (argc=2, argv=0xbad4) at cgi_main.c:738 (gdb) -- Edit bug report at http://bugs.php.net/?id=16438&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16438&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16438&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16438&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16438&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16438&r=support Expected behavior: http://bugs.php.net/fix.php?id=16438&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16438&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16438&r=submittedtwice
Bug #16438 Updated: Segmentation fault
ID: 16438 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Red Hat Linux release 6.2 PHP Version: 4.1.2 New Comment: 1. there're more than 65536 rows. use php 4.1.2 it crashes after 65538 2. tried with PHP 4.2.0RC2, program got "Segmentation fault" again. crashed after 65534 configuration = ./configure --with-mysql --with-socket --enable-trans-sid --with-progel --with-gd --enable-discard-path --prefix=/mnt/nfshome/tony/php debug info == $ gdb bin/php /home/tony/stats/bin/core GNU gdb 19991004 Copyright 1998 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"... Core was generated by `bin/php /home/tony/stats/bin/chatv2.crash.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 0x80e7eb1 in zend_hash_add_or_update (ht=0xa51f04c, arKey=0x818150c "End", nKeyLength=4, pData=0xbfffce10, nDataSize=4, pDest=0xbfffce1c, flag=1) at zend_hash.c:275 275 ht->arBuckets[nIndex] = p; (gdb) bt #0 0x80e7eb1 in zend_hash_add_or_update (ht=0xa51f04c, arKey=0x818150c "End", nKeyLength=4, pData=0xbfffce10, nDataSize=4, pDest=0xbfffce1c, flag=1) at zend_hash.c:275 #1 0x810362c in zend_fetch_dimension_address_inner (ht=0xa51f04c, op2=0x8184a80, Ts=0xbfffce84, type=1) at ./zend_execute.c:627 #2 0x80fb8fb in zend_fetch_dimension_address (result=0x8184a60, op1=0x8184a70, op2=0x8184a80, Ts=0xbfffce84, type=1) at ./zend_execute.c:762 #3 0x80fd912 in execute (op_array=0x817ca84) at ./zend_execute.c:1274 #4 0x80e54b7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #5 0x8062eaa in php_execute_script (primary_file=0xba74) at main.c:1381 #6 0x8060f99 in main (argc=2, argv=0xbad4) at cgi_main.c:785 (gdb) Previous Comments: [2002-04-04 21:08:09] [EMAIL PROTECTED] First, please try with PHP 4.2.0RC2 from http://www.php.net/~derick/ Second question is, how many rows are there in the array causing the crash? [2002-04-04 21:02:10] [EMAIL PROTECTED] configuration line == ./configure --with-mysql --with-socket --enable-trans-sid --with-progel --with-gd --enable-discard-path description === chatv2.php - daily batch program, read database (MySQL), generate statistics, write database. As the records increased, it's occurs more often. debug info == $ gdb /usr/local/bin/php /home/tony/stats/bin/core GNU gdb 19991004 Copyright 1998 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"... Core was generated by `/usr/local/bin/php /home/tony/stats/bin/chatv2.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) run /home/tony/stats/bin/chatv2.php Starting program: /usr/local/bin/php /home/tony/stats/bin/chatv2.php X-Powered-By: PHP/4
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: tony at hotmail dot com Reported By: asmi at owear dot ru Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: asian gang bang then http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang and on. http://asian-gang-bang.spb.su/ Previous Comments: [2005-04-15 14:20:55] [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-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: tony at hotmail dot com Reported By: asmi at owear dot ru Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: We are seriously concerned on asian gang bang the http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang for success. http://asian-gang-bang.spb.su/ Previous Comments: [2005-04-18 09:39:42] tony at hotmail dot com asian gang bang then http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang and on. http://asian-gang-bang.spb.su/ [2005-04-15 14:20:55] [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-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: tony at hotmail dot com Reported By: asmi at owear dot ru Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: We appreciate asian gang bang creates the need for http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ Previous Comments: [2005-04-18 09:40:18] tony at hotmail dot com We are seriously concerned on asian gang bang the http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang for success. http://asian-gang-bang.spb.su/ [2005-04-18 09:39:42] tony at hotmail dot com asian gang bang then http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang and on. http://asian-gang-bang.spb.su/ [2005-04-15 14:20:55] [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-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: tony at hotmail dot com Reported By: asmi at owear dot ru Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: asian gang bang and find details of http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ Previous Comments: [2005-04-18 09:40:31] tony at hotmail dot com We appreciate asian gang bang creates the need for http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ [2005-04-18 09:40:18] tony at hotmail dot com We are seriously concerned on asian gang bang the http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang for success. http://asian-gang-bang.spb.su/ [2005-04-18 09:39:42] tony at hotmail dot com asian gang bang then http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang and on. http://asian-gang-bang.spb.su/ [2005-04-15 14:20:55] [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-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: tony at hotmail dot com Reported By: asmi at owear dot ru Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: Be sure to read asian gang bang is able to provide http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang, nothing else. http://asian-gang-bang.spb.su/ Previous Comments: [2005-04-18 09:40:45] tony at hotmail dot com asian gang bang and find details of http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ [2005-04-18 09:40:31] tony at hotmail dot com We appreciate asian gang bang creates the need for http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ [2005-04-18 09:40:18] tony at hotmail dot com We are seriously concerned on asian gang bang the http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang for success. http://asian-gang-bang.spb.su/ [2005-04-18 09:39:42] tony at hotmail dot com asian gang bang then http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang and on. http://asian-gang-bang.spb.su/ [2005-04-15 14:20:55] [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/31981 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31981 [Com]: Crash in shutdown_memory_manager
ID: 31981 Comment by: tony at hotmail dot com Reported By: asmi at owear dot ru Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.11 New Comment: asian gang bang http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang. http://asian-gang-bang.spb.su/ Previous Comments: [2005-04-18 09:41:08] tony at hotmail dot com Be sure to read asian gang bang is able to provide http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang, nothing else. http://asian-gang-bang.spb.su/ [2005-04-18 09:40:45] tony at hotmail dot com asian gang bang and find details of http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ [2005-04-18 09:40:31] tony at hotmail dot com We appreciate asian gang bang creates the need for http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang! http://asian-gang-bang.spb.su/ [2005-04-18 09:40:18] tony at hotmail dot com We are seriously concerned on asian gang bang the http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang for success. http://asian-gang-bang.spb.su/ [2005-04-18 09:39:42] tony at hotmail dot com asian gang bang then http://asian-gang-bang.spb.su/"; target=_blank>asian gang bang and on. http://asian-gang-bang.spb.su/ 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/31981 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#28089 [NEW]: pg_field_size always returns -1 instead of actual field size
From: tony at gigaday dot com Operating system: Gentoo Linux PHP version: 4.3.4 PHP Bug Type: PostgreSQL related Bug description: pg_field_size always returns -1 instead of actual field size Description: I am unable to get pg_field_size to return the correct storage size of a field; I have pg_field_num and pg_field_type working but not pg_field_size. Reproduce code: --- Expected result: res:Resource id #3 code:0 type:bpchar size:-1 Actual result: -- res:Resource id #3 code:0 type:bpchar size:6 since psql gives:- pacs=# \d ccy Table "public.ccy" Column | Type | Modifiers ---+---+--- ccy_code | character(6) | not null ccy_desc | character(20) | ccy_curr_rate | numeric(12,4) | ccy_std_rate | numeric(12,4) | ccy_alt_rate | numeric(12,4) | Indexes: ccy_pkey primary key btree (ccy_code) pacs=# -- Edit bug report at http://bugs.php.net/?id=28089&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28089&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28089&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28089&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28089&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28089&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28089&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28089&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28089&r=support Expected behavior: http://bugs.php.net/fix.php?id=28089&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28089&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28089&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28089&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28089&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28089&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28089&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28089&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28089&r=float
#28089 [Opn]: pg_field_size always returns -1 instead of actual field size
ID: 28089 User updated by: tony at gigaday dot com Reported By: tony at gigaday dot com Status: Open Bug Type: PostgreSQL related Operating System: Gentoo Linux PHP Version: 4.3.4 New Comment: Sorry, I got the actual and expect results in the wrong boxes in the bug report. :( The incorrect value of -1 is the actual returned value. Previous Comments: [2004-04-21 12:17:37] tony at gigaday dot com Description: I am unable to get pg_field_size to return the correct storage size of a field; I have pg_field_num and pg_field_type working but not pg_field_size. Reproduce code: --- Expected result: res:Resource id #3 code:0 type:bpchar size:-1 Actual result: -- res:Resource id #3 code:0 type:bpchar size:6 since psql gives:- pacs=# \d ccy Table "public.ccy" Column | Type | Modifiers ---+---+--- ccy_code | character(6) | not null ccy_desc | character(20) | ccy_curr_rate | numeric(12,4) | ccy_std_rate | numeric(12,4) | ccy_alt_rate | numeric(12,4) | Indexes: ccy_pkey primary key btree (ccy_code) pacs=# -- Edit this bug report at http://bugs.php.net/?id=28089&edit=1
#28089 [Bgs]: pg_field_size always returns -1 instead of actual field size
ID: 28089 User updated by: tony at gigaday dot com Reported By: tony at gigaday dot com Status: Bogus Bug Type: PostgreSQL related Operating System: Gentoo Linux PHP Version: 4.3.4 New Comment: Thanks for getting back. Maybe I am doing something wrong, in which case I am sorry to waste your time, but I still think that this is a bug. I am aware that a return of -1 indicates a variable length field, but none of the fields is variable length and I just gave the field ccy_code (fixed length) as an example. None of the fields is variable length but they all return -1. Previous Comments: [2004-04-22 01:52:39] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PQfsize returns the size in bytes of the field associated with the given field index. If the size returned is -1, the field is a variable length field. The PQfsize() is the underlying function behind pg_field_size(). [2004-04-21 12:23:43] tony at gigaday dot com Sorry, I got the actual and expect results in the wrong boxes in the bug report. :( The incorrect value of -1 is the actual returned value. [2004-04-21 12:17:37] tony at gigaday dot com Description: I am unable to get pg_field_size to return the correct storage size of a field; I have pg_field_num and pg_field_type working but not pg_field_size. Reproduce code: --- Expected result: res:Resource id #3 code:0 type:bpchar size:-1 Actual result: -- res:Resource id #3 code:0 type:bpchar size:6 since psql gives:- pacs=# \d ccy Table "public.ccy" Column | Type | Modifiers ---+---+--- ccy_code | character(6) | not null ccy_desc | character(20) | ccy_curr_rate | numeric(12,4) | ccy_std_rate | numeric(12,4) | ccy_alt_rate | numeric(12,4) | Indexes: ccy_pkey primary key btree (ccy_code) pacs=# -- Edit this bug report at http://bugs.php.net/?id=28089&edit=1
#28297 [NEW]: make install or make test segfault
From: tony at unihost dot net Operating system: Linux PHP version: 5.0.0RC2 PHP Bug Type: *Compile Issues Bug description: make install or make test segfault Description: After a successful compile of RC2 (with a few warnings) running 'make test' or make install segfaults with an 'Error 139' Bear with me, I'm not really a coder, so I've tried to include any needed information. I'll gladly provide any more if you need it. I've compiled with --enable-debug and the backtrace in this report is from the core file from 'make test'. Like I said, I'm not sure how helpful this is. If you need more information, I'll be happy to provide it. I couldn't find any other bugs matching this in the DB. Cheers T. Reproduce code: --- I've compiled RC2 with the following config options... ./configure --prefix=/usr/local/php5 --with-mysql=/usr --with-pgsql --enable-fastcgi --with-gd --with-openssl --with-ncurses \ --with-zlib --program-prefix=php5_ --enable-trans-sid --enable-sockets --with-xslt --with-mcrypt --with-ldap \ --enable-magic-quotes --with-dom --with-bz2 --with-curl --with-pdflib --with-cpdflib --with-snmp \ --enable-wddx --with-pdf --enable-gd-native-ttf --with-java --with-xpm-dir=/usr/X11R6/lib \ --with-png-dir=/usr/lib --with-freetype-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-tiff-dir=/usr/lib \ --enable-bcmath --with-pear --enable-debug Core was generated by `/home/tony/src/php-5.0.0RC2/sapi/cli/php -d open_basedir= -d safe_mode=0 -d out' Actual result: -- Additionally, I've run the following command: (gdb) bt #0 0x4009e5eb in RSA_sign () from /usr/local/pgsql/lib/libpq.so.3 #1 0xbfffe250 in ?? () #2 0x4010e040 in md2_md () from /usr/local/pgsql/lib/libpq.so.3 #3 0x0001 in ?? () #4 0x4009e5ac in RSA_sign () from /usr/local/pgsql/lib/libpq.so.3 #5 0x0001 in ?? () #6 0x4065c000 in ?? () #7 0x4065c19c in ?? () #8 0xbfffe200 in ?? () #9 0x4000c6f1 in fixup (l=Variable "l" is not available. ) at dl-runtime.c:102 Previous frame inner to this frame (corrupt stack?) Then followed by: (gdb) frame 9 #9 0x4000c6f1 in fixup (l=Variable "l" is not available. ) at dl-runtime.c:102 102 dl-runtime.c: No such file or directory. in dl-runtime.c -- Edit bug report at http://bugs.php.net/?id=28297&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28297&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28297&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28297&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28297&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28297&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28297&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28297&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28297&r=support Expected behavior: http://bugs.php.net/fix.php?id=28297&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28297&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28297&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28297&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28297&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28297&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28297&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28297&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28297&r=float
#28297 [Bgs]: make install or make test segfault
ID: 28297 User updated by: tony at unihost dot net Reported By: tony at unihost dot net Status: Bogus Bug Type: *Compile Issues Operating System: Linux PHP Version: 5.0.0RC2 New Comment: Okay, I did as you said and took out the PostgreSQL include, and it compiles and tests just fine. But my question from here is what has broken between 4.3.6 and 5.0RC2? I use exactly the same libraries to compile 4.3.6 without any problems at all? T. Previous Comments: [2004-05-06 19:28:23] [EMAIL PROTECTED] I'm pretty sure it is the postgresql libs crashing. Remove --with-pgsql and try again. You can remove --with-java too, it's not distributed with the man PHP distribution anymore. If it still happends without postgresql support, reopen this report. I'm pretty sure it's the postgresql libs crashing. Recompile postgresql with debugging turned on and submit a bug report to them or your distribution vendor. [2004-05-06 13:55:32] tony at unihost dot net Description: After a successful compile of RC2 (with a few warnings) running 'make test' or make install segfaults with an 'Error 139' Bear with me, I'm not really a coder, so I've tried to include any needed information. I'll gladly provide any more if you need it. I've compiled with --enable-debug and the backtrace in this report is from the core file from 'make test'. Like I said, I'm not sure how helpful this is. If you need more information, I'll be happy to provide it. I couldn't find any other bugs matching this in the DB. Cheers T. Reproduce code: --- I've compiled RC2 with the following config options... ./configure --prefix=/usr/local/php5 --with-mysql=/usr --with-pgsql --enable-fastcgi --with-gd --with-openssl --with-ncurses \ --with-zlib --program-prefix=php5_ --enable-trans-sid --enable-sockets --with-xslt --with-mcrypt --with-ldap \ --enable-magic-quotes --with-dom --with-bz2 --with-curl --with-pdflib --with-cpdflib --with-snmp \ --enable-wddx --with-pdf --enable-gd-native-ttf --with-java --with-xpm-dir=/usr/X11R6/lib \ --with-png-dir=/usr/lib --with-freetype-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-tiff-dir=/usr/lib \ --enable-bcmath --with-pear --enable-debug Core was generated by `/home/tony/src/php-5.0.0RC2/sapi/cli/php -d open_basedir= -d safe_mode=0 -d out' Actual result: -- Additionally, I've run the following command: (gdb) bt #0 0x4009e5eb in RSA_sign () from /usr/local/pgsql/lib/libpq.so.3 #1 0xbfffe250 in ?? () #2 0x4010e040 in md2_md () from /usr/local/pgsql/lib/libpq.so.3 #3 0x0001 in ?? () #4 0x4009e5ac in RSA_sign () from /usr/local/pgsql/lib/libpq.so.3 #5 0x0001 in ?? () #6 0x4065c000 in ?? () #7 0x4065c19c in ?? () #8 0xbfffe200 in ?? () #9 0x4000c6f1 in fixup (l=Variable "l" is not available. ) at dl-runtime.c:102 Previous frame inner to this frame (corrupt stack?) Then followed by: (gdb) frame 9 #9 0x4000c6f1 in fixup (l=Variable "l" is not available. ) at dl-runtime.c:102 102 dl-runtime.c: No such file or directory. in dl-runtime.c -- Edit this bug report at http://bugs.php.net/?id=28297&edit=1
#28297 [Bgs->Opn]: (SNMP) make install or make test segfault
ID: 28297 User updated by: tony at unihost dot net -Summary: make install or make test segfault Reported By: tony at unihost dot net -Status: Bogus +Status: Open Bug Type: *Compile Issues Operating System: Linux PHP Version: 5.0.0RC2 New Comment: After much playing around, adding debugging to the PostgreSQL libs showed nothing of interest, however disabling SNMP support allowed error free compile and segfault free test and install. I've had problems with SNMP in PHP for as long as I can remember. So although I have no valid technical feedback, I suggest the issue is with SNMP code in PHP since this is the only change from the previous segfaulting compile. Whether you wish investigate further or simply close this one down is your call. Cheers T. Previous Comments: [2004-05-06 22:31:28] tony at unihost dot net Okay, I did as you said and took out the PostgreSQL include, and it compiles and tests just fine. But my question from here is what has broken between 4.3.6 and 5.0RC2? I use exactly the same libraries to compile 4.3.6 without any problems at all? T. [2004-05-06 19:28:23] [EMAIL PROTECTED] I'm pretty sure it is the postgresql libs crashing. Remove --with-pgsql and try again. You can remove --with-java too, it's not distributed with the man PHP distribution anymore. If it still happends without postgresql support, reopen this report. I'm pretty sure it's the postgresql libs crashing. Recompile postgresql with debugging turned on and submit a bug report to them or your distribution vendor. ---- [2004-05-06 13:55:32] tony at unihost dot net Description: After a successful compile of RC2 (with a few warnings) running 'make test' or make install segfaults with an 'Error 139' Bear with me, I'm not really a coder, so I've tried to include any needed information. I'll gladly provide any more if you need it. I've compiled with --enable-debug and the backtrace in this report is from the core file from 'make test'. Like I said, I'm not sure how helpful this is. If you need more information, I'll be happy to provide it. I couldn't find any other bugs matching this in the DB. Cheers T. Reproduce code: --- I've compiled RC2 with the following config options... ./configure --prefix=/usr/local/php5 --with-mysql=/usr --with-pgsql --enable-fastcgi --with-gd --with-openssl --with-ncurses \ --with-zlib --program-prefix=php5_ --enable-trans-sid --enable-sockets --with-xslt --with-mcrypt --with-ldap \ --enable-magic-quotes --with-dom --with-bz2 --with-curl --with-pdflib --with-cpdflib --with-snmp \ --enable-wddx --with-pdf --enable-gd-native-ttf --with-java --with-xpm-dir=/usr/X11R6/lib \ --with-png-dir=/usr/lib --with-freetype-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-tiff-dir=/usr/lib \ --enable-bcmath --with-pear --enable-debug Core was generated by `/home/tony/src/php-5.0.0RC2/sapi/cli/php -d open_basedir= -d safe_mode=0 -d out' Actual result: -- Additionally, I've run the following command: (gdb) bt #0 0x4009e5eb in RSA_sign () from /usr/local/pgsql/lib/libpq.so.3 #1 0xbfffe250 in ?? () #2 0x4010e040 in md2_md () from /usr/local/pgsql/lib/libpq.so.3 #3 0x0001 in ?? () #4 0x4009e5ac in RSA_sign () from /usr/local/pgsql/lib/libpq.so.3 #5 0x0001 in ?? () #6 0x4065c000 in ?? () #7 0x4065c19c in ?? () #8 0xbfffe200 in ?? () #9 0x4000c6f1 in fixup (l=Variable "l" is not available. ) at dl-runtime.c:102 Previous frame inner to this frame (corrupt stack?) Then followed by: (gdb) frame 9 #9 0x4000c6f1 in fixup (l=Variable "l" is not available. ) at dl-runtime.c:102 102 dl-runtime.c: No such file or directory. in dl-runtime.c -- Edit this bug report at http://bugs.php.net/?id=28297&edit=1
#24446 [NEW]: unrecognized files
From: tony at tonybibbs dot com Operating system: RedHat 9 PHP version: 5.0.0b1 (beta1) PHP Bug Type: Compile Failure Bug description: unrecognized files Description: On stock RH9 system I removed Apache2 and installed 1.3.27. Then went ahead and tried a simple compile: ./configure --with-mysql --with-apxs Got an unrecognized file on ctype.lo, so I added --disable-ctype to configure Got an unreconized file on some dom.lo file so I added --without-dom to configure Got an unrecognized file on php_mysql.lo which I absolutely needed so I quit. -- Edit bug report at http://bugs.php.net/?id=24446&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24446&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24446&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24446&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24446&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24446&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24446&r=support Expected behavior: http://bugs.php.net/fix.php?id=24446&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24446&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24446&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24446&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24446&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24446&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24446&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24446&r=gnused
#24446 [Bgs]: unrecognized files
ID: 24446 User updated by: tony at tonybibbs dot com Reported By: tony at tonybibbs dot com Status: Bogus Bug Type: Compile Failure Operating System: RedHat 9 PHP Version: 5.0.0b1 (beta1) New Comment: Try a 'make clean'. This worked for me. Previous Comments: [2003-07-01 17:19:58] [EMAIL PROTECTED] Try: make clean make You most probably have a stale file somewhere. [2003-07-01 15:06:55] tony at tonybibbs dot com Description: On stock RH9 system I removed Apache2 and installed 1.3.27. Then went ahead and tried a simple compile: ./configure --with-mysql --with-apxs Got an unrecognized file on ctype.lo, so I added --disable-ctype to configure Got an unreconized file on some dom.lo file so I added --without-dom to configure Got an unrecognized file on php_mysql.lo which I absolutely needed so I quit. -- Edit this bug report at http://bugs.php.net/?id=24446&edit=1
#25103 [NEW]: Session handling that seg faults apache
From: tony at tonybibbs dot com Operating system: Linux (RedHat) PHP version: 4.3.2 PHP Bug Type: Reproducible crash Bug description: Session handling that seg faults apache Description: I have a custom php session handler that interacts with a database via PEAR::DB. I have set session.save_handler to user. I have test this using both MySQL and MS SQL Server 2000 on the backend. Running this code can kill one of the Apache process consistently. The short version of what I am doing is I authenticate my app, stick a user object in the session using $_SESSION['user'] = &$userObj; Then later I try to get that object out of the session by using $userObj = &$_SESSION['user']. To get code that reproduces this go here: http://www.tonybibbs.com/filemgmt/visit.php?lid=5 Reproduce code: --- http://www.tonybibbs.com/filemgmt/visit.php?lid=5 Expected result: I would expect that on page 2 I would get an instance of the object out of the session Ok. -- Edit bug report at http://bugs.php.net/?id=25103&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25103&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25103&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25103&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25103&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25103&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25103&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25103&r=support Expected behavior: http://bugs.php.net/fix.php?id=25103&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25103&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25103&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25103&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25103&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25103&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25103&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25103&r=gnused
#40740 [Com]: PDO::execute() errors when parameters are used in LIMIT clause
ID: 40740 Comment by: tony at tonybibbs dot com Reported By: phpbugs at filofox dot com Status: No Feedback Bug Type: PDO related Operating System: Linux Debian Sarge 3.1 PHP Version: 5.2.1 Assigned To: wez New Comment: Same issue on 5.3.0RC2 using pretty much the same code in the initial bug report. Previous Comments: [2009-02-18 08:51:00] nduteil at freedev dot org Hi, Still not fixed in the 5.2.8 release. If PDOStatement::bindParam or PDOStatement::bindValue is used to specified the parameter type (ie : PDO::PARAM_INT) everything works as expected. Not forcing the parameter type to integer generates an error in Mysql. [2008-11-26 10:57:40] miha dot vrhovnik at domenca dot si I re-compiled pdo and pdo_mysql from 5.2.7 RC4 and overwritten libraries from php 5.2.6. Is this enough? If it is, then this issue is not fixed. [2008-11-12 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-11-04 15:25:02] fel...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-11-02 03:43:00] dev at bcdiv dot com PHP v 5.2.6 MySQL v 5.0.51b-community-nt Vista Ultimate SP1 Similar (though not exactly) usage of PDO to run a stored procedure w/ a parameter that sets the number in a limit clause does not replicate error. $dbc = new DBO; $dbc->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $sproc = $dbc->prepare(“CALL spLimitProc ?”); $sproc->bindParam(1,$limit, PDO::PARAM_INT); $result = $sproc->execute(); Result returns table rows as expected (similar to direct MySQL sproc call). Perhaps resolved or not experienced across platforms? 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/40740 -- Edit this bug report at http://bugs.php.net/?id=40740&edit=1
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=1 ID: 51216 Comment by: tony at tonybibbs dot com Reported by: dtm2mcs at gmail dot com Summary: Segmentation fault when compiling PHP with PHAR Status: Open Type: Bug Package: PHAR related Operating System: Ubuntu 6.04 + CentOS 5.4 PHP Version: 5.3.2 New Comment: Same issue on 32bit Ubuntu 9.10 Previous Comments: [2010-03-26 00:16:11] mm_half3 at yahoo dot com For what it is worth, I had the same issue on Solaris 10 sparc, compiling with gcc-4.3.1, and php-5.32 (tried with stable release and latest development src). Further research found other solaris types getting segmentation faults during php 5.2.xx make test, see http://bugs.php.net/bug.php?id=47824&edit=1 . Which I also could reproduce. Setting CFLAGS=-O1, got php5.32 to compile and make test successfully with phar, and 5.2.xx to compile without fatal errors. The seg fault is probably not a php issue, but something in the gcc version. The make test looks like all the tests run, but there is an issue when the Test Summary is done for both: WARNED TEST SUMMARY - via [ext/pdo_sqlite/tests/common.phpt] SQLite PDO Common: Bug #34630 (inserting streams as LOBs) [ext/pdo_sqlite/tests/bug_34630.phpt] (warn: XFAIL section but test passes) via [ext/sqlite/tests/pdo/common.phpt] SQLite2 PDO Common: Bug #34630 (inserting streams as LOBs) [ext/sqlite/tests/pdo/bug_34630.phpt] (warn: XFAIL section but test passes) = You may have found a problem in PHP. We would like to send this report automatically to the PHP QA team, to give us a better understanding of how the test cases are doing. If you don't want to send it immediately, you can choose "s" to save the report to a file that you can send us later. Do you want to send this report now? [Yns]: s Please send /tmp/php-5.3.2/php_test_results_20100325_2040.txt to qa-repo...@lists.php.net manually, thank you. [2010-03-24 17:51:27] paul at boxuk dot com i can also reproduce this, i believe it's something to do with the fix for bug #50829 amended that bug with the details [2010-03-22 11:32:02] creatorbri at gmail dot com I have the same problem when attempting to compile PHP 5.3.2. Details: PHP Version: PHP 5.3.2 - I downloaded the "stable" release dated "04 Mar 2010" directly from one of the usual php.net mirrors Platform: Ubuntu 9.10 Karmic Koala x64 [Asus G60Jx-RBBx05 - Core i5-430 2.26 GHz 4.0 GB RAM] Configure Options: ./configure --prefix=PREFIX --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr -- with-mysqli=/usr/bin/mysql_config --with-pgsql=/usr --with-tidy=/usr --with- curl=/usr/bin --with-curlwrappers --with-openssl-dir=/usr --with-zlib-dir=/usr - -enable-mbstring --with-xpm-dir=/usr --with-pdo-pgsql=/usr --with-pdo-mysql=/usr --with-xsl=/usr --with-ldap --with-xmlrpc --with-iconv-dir=/usr --with-snmp=/usr --enable-exif --enable-calendar --with-bz2=/usr --with-mcrypt=/usr --with-gd -- with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-freetype- dir=/usr --enable-mbstring --enable-zip --with-pear ERROR: ext/sqlite3/libsqlite/.libs/sqlite3.o: In function `memset': /usr/include/bits/string3.h:82: warning: memset used with constant zero length parameter; this could be due to transposed parameters Generating phar.php Segmentation fault make: *** [ext/phar/phar.php] Error 139 [2010-03-16 16:22:12] vnegrier at optilian dot com Not PHAR related, this is actually the php-cli binary segfaulting during the make process. Here is a trace : 0x0839c8f4 in zend_startup_module_ex (module=0x8732210, tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_API.c:1618 1618EG(current_module) = NULL; (gdb) where #0 0x0839c8f4 in zend_startup_module_ex (module=0x8732210, tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_API.c:1618 #1 0x083a177a in zend_hash_apply (ht=0x8711460, apply_func=0x839c850 , tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_hash.c:673 #2 0x0839c75a in zend_startup_modules (tsrm_ls=0x8712070) at /usr/src/php-5.3.2/Zend/zend_API.c:1662 #3 0x083372f0 in php_module_startup (sf=0x86f82c0, additional_modules=0x0, num_additional_modules=0) at /usr/src/php-5.3.2/main/main.c:2022 #4 0x084299f1 in php_cli_startup (sapi_module=0x86f82c0) at /usr/src/php-5.3.2/sapi/cli/php_cli.c:401 #5 0x0842a32c in main (argc=1, argv=0xbfffcf74) at
#42188 [Com]: session_start segfaults with Apache 2
ID: 42188
Comment by: tony at mcrsys dot com
Reported By: h dot fietz at dezem dot de
Status: No Feedback
Bug Type: Session related
Operating System: Gentoo 2006.1
PHP Version: 5.2.3
New Comment:
Mac OSX 10.5 (Leopard), PHP 5.2.3
Same stack trace, from index.php, session_start() before any output.
Previous Comments:
[2007-08-11 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-08-03 01:04:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-08-02 20:03:12] h dot fietz at dezem dot de
Description:
PHP crashes ("Child pid xxx exit signal segmentation fault" in Apache's
error_log) on calling session_start().
Environment:
AMD Opteron 146 (64bit)
Gentoo Linux 2006.1
Apache 2.0.58
PHP 5.2.3 from portage ebuild
Reproduce code:
---
";
?>
Expected result:
session starts
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46971518093328 (LWP 26146)]
0x2ab8688ac430 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0x2ab8688ac430 in strlen () from /lib/libc.so.6
#1 0x2ab86a81c934 in zif_session_encode () from
/usr/lib64/apache2/modules/libphp5.so
#2 0x2ab86a81efc5 in php_session_start () from
/usr/lib64/apache2/modules/libphp5.so
#3 0x2ab86a81f8b9 in zif_session_start () from
/usr/lib64/apache2/modules/libphp5.so
#4 0x2ab86a975512 in execute () from
/usr/lib64/apache2/modules/libphp5.so
#5 0x2ab86a9660d3 in execute () from
/usr/lib64/apache2/modules/libphp5.so
#6 0x2ab86a94715d in zend_execute_scripts () from
/usr/lib64/apache2/modules/libphp5.so
#7 0x2ab86a905b18 in php_execute_script () from
/usr/lib64/apache2/modules/libphp5.so
#8 0x2ab86a9c5dbd in php_ap2_register_hook () from
/usr/lib64/apache2/modules/libphp5.so
#9 0x00426d69 in ap_run_handler ()
#10 0x00429c62 in ap_invoke_handler ()
#11 0x00424d38 in ap_process_request ()
#12 0x0041fd30 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=42188&edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: tony at tuxick dot net Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: same problem on 5.1.2 and 5.1.4. php.ini shows ;default_charset = "iso-8859-1", suggesting it's default. enabling fixed the problem. Previous Comments: [2006-05-10 00:40:56] jeroen at haan dot net Changing the character set from utf-8 to the old iso-8859-1 helped. Now a session cookie is succesfully stored on the client and thereby the sessid and thus one file on the server maintained. However I do not understand this behavior. [2006-04-26 07:00:18] sunmt at usa dot com I expereinced the same problem in PHP 5.0.5 Reading\Writing to session works in the same page but the server loses the session when going between different pages or reloading the page. Please help me.. [2006-02-16 21:16:24] optikey at gmail dot com Same problem with 5.0.5 running on Debian x86_64... Only I.E. does this 2 cookies thing and scroolled my code... Digging the net, i found that those bugs started only in the browsers that executes windows update automatically... So i find that the day that the problems started matches the day of the release of one Microsoft Bugfix that affects I.E. 14/feb/2006 Only the updated browsers behave incorrectly Might we need to blame M$ Any workarounds??? Am i right??? MS did not return the bug report... [2006-02-15 17:05:12] bohn at netbuild dot net got same problem under using php 4.3.10 :( on heavy load, php creates a new session... fc3, apache2, php4.3.10, lvs [2006-01-30 22:21:11] geso at inmail dot sk I've got same problem with 5.1.2 (and previously with 4.3.8). Both clean install, Win2k, IIS 5.0. Everytime I enter (reload) a page, it creates a new file in my sessions directory. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#36161 [NEW]: go-pear.bat doesn't install pear.bat
From: tony at tonybibbs dot com Operating system: Windows XP PHP version: 5.1.2 PHP Bug Type: Unknown/Other Function Bug description: go-pear.bat doesn't install pear.bat Description: Installing PEAR from the bundled go-pear.bat that is packaged with the ZIP package doens't install pear.bat Reproduce code: --- 1) Unzip to PHP 5.1.2 zip to C:\PHP 2) open DOS command prompt and change directory to c:\PHP 3) at DOS prompt run go-pear.php 4) Choose system wide copy 5) change "Installation base" to c:\PHP\PEAR 6) If needed, change "Path to CLI php.exe" to c:\PHP 7) Hit enter (to install with those settings) 8) Once installed, change directory to C:\PHP\PEAR 9) do a directory listing...I see pear.bat old but not pear.bat 10) use XP search feature to search recursively on c:\PHP for pear.bat to ensure pear.bat didn't get put somewhere unexpected (didn't work for me). Expected result: I expect to see pear.bat somewhere. Actual result: -- No pear.bat produced. -- Edit bug report at http://bugs.php.net/?id=36161&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36161&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36161&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36161&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36161&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36161&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36161&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36161&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36161&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36161&r=support Expected behavior:http://bugs.php.net/fix.php?id=36161&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36161&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36161&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36161&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36161&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36161&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36161&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36161&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36161&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36161&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36161&r=mysqlcfg
Req #46260 [Com]: __FILE__ should not resolve symlink paths
Edit report at https://bugs.php.net/bug.php?id=46260&edit=1 ID: 46260 Comment by: tony at brown dot org Reported by:bugs dot php dot net at callum-macdonald dot com Summary:__FILE__ should not resolve symlink paths Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Linux PHP Version:5.2.6 Block user comment: N Private report: N New Comment: I'm another +1 for this, causing me some real headaches because for deployment I store multiple versions of a site with the latest been symlinked to for apache. There are modules in the application which are licensed and use the file path as part of it's verification. When we deploy, the path is seen as changed and the modules get disabled. :-( Previous Comments: [2011-04-27 04:38:48] gnoodl+php at gmail dot com $_SERVER["SCRIPT_FILENAME"] cannot be used in place of __FILE__ as it does not resolve the path of an included file. Eg, // file1.php include 'file2.php'; // file2.php echo $_SERVER['SCRIPT_FILENAME']; Executing file1.php will result in "/path/to/file1.php" [2010-12-10 18:12:17] php at micropro dot cz I think I have a resoulution ... use $_SERVER["SCRIPT_FILENAME"] instead of __file__. It should work the same way, but is absolute path, not resolved. It works for me fine :-) [2010-11-10 16:52:41] jimmy at powerzone dot dk I agree. Hosting multiple PHP systems based on the same installation is no easy task, when __FILE__ is used in conjunction with symlinks. Very frustrating. I vote for a new contant; __FILEPATH__ which does not resolve symlinks. [2010-08-26 09:12:33] rix at mindginative dot com +1 for this. I encountered this issue today and was hoping that there's a better way not to resolve symlink in __FILE__. As suggested above, perhaps __FILE_LINK__ that either return the symlink path or false if none. [2009-09-26 21:01:15] miguel-php at cr dot uz Another vote for this. The current implementation does not seem like the proper way to treat symlinks, and it makes sharing included files between directories very difficult. I understand that changing this now has the potential to cause breakage in scripts that depend on the current behaviour. But there really does need to be a way for a file to find its own effective location. 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 https://bugs.php.net/bug.php?id=46260 -- Edit this bug report at https://bugs.php.net/bug.php?id=46260&edit=1
#46677 [Com]: Can not make install php5.2.6
ID: 46677 Comment by: tony dot dziedzic at oracle dot com Reported By: chunhuan dot pan at alcatel-sbell dot com dot cn Status: No Feedback Bug Type: Compile Failure Operating System: HP-UX 11.23 PHP Version: 5.2.6 New Comment: I also ran into this bug using PHP 5.2.9 on HP-UX. Here is a stack backtrace obtained when executing the test script described in this bug report on HP-UX 11.31: #0 _zval_ptr_dtor (zval_ptr=0x7fff98b0) at /p5h/reliaty/web/php-5.2.9/Zend/zend_execute_API.c:412 #1 0x46e9cd0:0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff9940) at zend_execute.h:155 #2 0x46c0b60:0 in execute (op_array=0x40099128) at zend_vm_execute.h:92 #3 0x466c050:0 in zend_execute_scripts (type=8, retval=, file_count=3) at /p5h/reliaty/web/php-5.2.9/Zend/zend.c:1134 #4 0x45be820:0 in php_execute_script (primary_file=Error accessing memory address 0x8: Invalid argument. ) at /p5h/reliaty/web/php-5.2.9/main/main.c:2023 #5 0x47f2d60:0 in main (argc=Error accessing memory address 0xc: Invalid argument. ) at /p5h/reliaty/web/php-5.2.9/sapi/cli/php_cli.c:1133 Note that the bug does NOT occur when using php5.2-200906111230.tar. FYI, Joseph Dziedzic Previous Comments: [2008-12-23 09:36:43] chunhuan dot pan at alcatel-sbell dot com dot cn Hello guys : Thank you for your greate help on this issues. For server migration is an urgent time ,and this problem broke me too much time ,so ,I take a new server with solaris OS to instead of. So ,from now ,I lost the permission to keep tracking on this coredump. Shall I close this ER? [2008-12-17 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-12-09 10:28:02] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-12-09 01:36:30] chunhuan dot pan at alcatel-sbell dot com dot cn Hello jani: See my backtrace below: --- (gdb) bt #0 0x2330 in () warning: Attempting to unwind past bad PC 0x2330 #1 0x6f7269675f76616c in () (gdb) --- PS: To get a best test ,could you show me the test source ,steps ,I am not very clearly how to get a best backtrace to help you solve the error! Thx a lot ,:-) [2008-12-08 12:32:25] j...@php.net Now, can you please provide the requested _backtrace_ finally? In gdb using command 'bt'.. 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/46677 -- Edit this bug report at http://bugs.php.net/?id=46677&edit=1
#46315 [NEW]: arrayObject count doesn't work correctly a specific instance.
From: tony dot fraser at gmail dot com
Operating system: MAMP
PHP version: 5.3.0alpha2
PHP Bug Type: SPL related
Bug description: arrayObject count doesn't work correctly a specific instance.
Description:
I have a class that extends ArrayObject. That class is a collection
(GenericCollection). Inside this GenericCollection, i have a little wrapper
class that wraps around whatever kind of classes I need to store in the
collection.
In that GenericCollection, I have a method that goes into the objects in
the array object, searches a a text field in a certain way, is supposed to
return another instance of the class with a subset of the collection.
(like, all status=active collection objects in another genericcollection)
The problem is with that internal temporary instance of the collection,
tempGenericCollection->count doens't work.
Note, in main class of GenericCollection, count works fine, just not in
the temporary object that the GenericCollection creates.
Reproduce code:
---
The following is working code, but the comment says what doesn't work.
This code comes from within the GenericCollection class.
$counter=0;
while ($_iterator->valid()){
$_tmp = $this->data->offSetGet($_iterator->key());
$_thisObject =$_tmp->getObject();
$_thisObjectID = $_tmp->getID();
if ($_thisObject->getProperty($_field) == $_value){
$_returnCollection->addObject($_thisObjectID, $_thisObject);
$_counter++;
}
$_iterator->next();
}
//right here.. $_returnCollection->count() can't be used, always returns
zero.
if ($_counter > 0) {
//error_log('returning an object with N items. N=' .
$_returnCollection->count());
return $_returnCollection;
}
Expected result:
I expect it to return the number of objects in the array. I have a print
method that shows everything, but even though the array is working
correctly, it isn't counting
Actual result:
--
0
--
Edit bug report at http://bugs.php.net/?id=46315&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46315&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46315&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46315&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46315&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46315&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46315&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46315&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46315&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46315&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46315&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46315&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46315&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46315&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46315&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46315&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46315&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46315&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46315&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46315&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46315&r=mysqlcfg
#46315 [Fbk->Opn]: arrayObject count doesn't work correctly a specific instance.
ID: 46315
User updated by: tony dot fraser at gmail dot com
Reported By: tony dot fraser at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: SPL related
Operating System: MAMP
PHP Version: 5.3.0alpha2
Assigned To: colder
New Comment:
No, you would think it was user error. I was certain it was, but when
it came down to it, I literally had it down to the $count variable and
the ->count() function side by side commenting them back and forth. the
->count variable always returned zero even though the collection was
there. Try it yourself, and don't hesitate to email me directly if you
want me to zip the entire directory tree for you.
Also, I would have rather had this class be an abstract but I wasn't
able to instantiate another instance of itself from within the class
itself. That's probably just my own misunderstanding of the language,
but it's a notable problem that we had to work around. I have a concrete
that just calls parent::construct(), it just wouldn't work from within
the class. Some type of circular reference I would imagine.
BTW, it's the kinds of advancements in objects like this that are
really pushing forward the acceptance of PHP as a true business
language. I was specifically asked if I wanted to take this full blown
project out of PHP and push it to Java. I told them no, but they had
full funding to do it.
Here are both classes. Note, DBHandle is not used anywhere in anything
that you see, so you can just discard it altogether for the purpose of
this class.
id = $_id;
$this->object = $_object;
}
function getObject(){
return $this->object;
}
function printObject() {
print_r($this);
}
function getID() {
return $this->id;
}
}
data = new ArrayObject();
//error_log('constructor of GC' . get_class($this->data));
}
function getData() {
return $this->data;
}
function count() {
/*
* This is here because of a bug in the datatype. Yes, it's
* already a function of the ArrayObject, but please leave this
* here perhaps until a few versions of PHP later.
*/
return $this->data->count();
}
/** Add an object of type Collection Object */
function addObject($_id, $_object){
//error_log('attempting to add object');
$_thisItem = new CollectionObject($_id, $_object);
//print_r($this->data);
$this->data->offSetSet($_id, $_thisItem);
}
function deleteObject($_id){
$this->data->offsetUnset($_id);
}
function objectExists($_id){
//error_log('GC object exists');
//error_log('id' . $_id);
if ($this->data->offsetExists($_id)){
$_return="true";
}
else $_return = "";
return $_return;
}
function getObject($_id,$_dbHandle) {
$_thisObject = $this->data->offSetGet($_id);
if (isset($_thisObject))
return $_thisObject->getObject();
else
return null;
}
function printCollection() {
print_r($this->data);
}
function getObjectType($_id, $_dbHandle) {
$_thisObject = getObject($_id, $_dbHandle);
if (isset($_thisObject))
return $_thisObject->getObject();
else
return null;
}
function returnObjectsByProperty($_field, $_value){
//error_log('in here');
$_returnCollection = new GenericCollection();
$_iterator = $this->data->getIterator();
$_counter = 0; //For some reason, $_returnCollection->count
doesn't
work here.
while ($_iterator->valid()){
//error_log($_iterator->key() . " IS KEY ");
//error_log(get_class($_iterator->current()));
$_tmp = $this->data->offSetGet($_iterator->key());
$_thisObject =$_tmp->getObject();
$_thisObjectID = $_tmp->getID();
//print_r($_thisObject);
if ($_thisObject->getDataType($_field) == $_value){
Bug #44683 [Com]: popen with modes such as "e" or "er" cause php.exe to crash
Edit report at http://bugs.php.net/bug.php?id=44683&edit=1 ID: 44683 Comment by: tony dot dziedzic at oracle dot com Reported by:d_kelsey at uk dot ibm dot com Summary:popen with modes such as "e" or "er" cause php.exe to crash Status: Closed Type: Bug Package:Reproducible crash Operating System: win32 only - Windows XP PHP Version:5.2.8 Assigned To:pajoye Block user comment: N New Comment: If a caller specifies an invalid mode argument (e.g., "w+"), this change results in the message "PHP Warning: popen(...) No error in
#42636 [NEW]: Problem - loading mysql database in dreamweaver mx:
From: tony at veederline dot com dot au Operating system: windows xp PHP version: 5.2.4 PHP Bug Type: Dynamic loading Bug description: Problem - loading mysql database in dreamweaver mx: Description: I am using dream weaver 6.0 to build a dynamic web site with php and mysql. I try connecting to an existing database, dreamweaver can't find it. I even went to macromedia web site and found that this is a known problem. I,ve triple, triple checked all parameters and still no solution. I get and successfully test conection but no tables will load. -- Edit bug report at http://bugs.php.net/?id=42636&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42636&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42636&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42636&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42636&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42636&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42636&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42636&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42636&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42636&r=support Expected behavior:http://bugs.php.net/fix.php?id=42636&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42636&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42636&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42636&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42636&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42636&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42636&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42636&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42636&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42636&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42636&r=mysqlcfg
#39163 [NEW]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.
From: tony dot stone at gmail dot com
Operating system: Windows Vista RC 1 Build 5600
PHP version: 5.1.6
PHP Bug Type: Win32API related
Bug description: Invalid API call from php5isapi.dll causing IIS7 Application
Pool failure.
Description:
I've seen a few other people post concerning random crashes, but my issue
can be reproduced every time I try to access any web page on my server
since configuring it to use php5isapi.dll
I am running Vista RC1 build 5600 with IIS 7 installed. php5isapi.dll
appears to be making an API call not recognized by the OS. Ever since I
installed PHP my DefaultAppPool stops when I access any web page on my
server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.
Details from App Log:
- System
- Provider
[ Name] Microsoft-Windows-IIS-W3SVC-WP
[ Guid] {670080D9-742A-4187-8D16-41143D1290BD}
[ EventSourceName] W3SVC-WP
- EventID 2295
[ Qualifiers] 49152
Version 0
Level 2
Task 0
Opcode 0
Keywords 0x80
- TimeCreated
[ SystemTime] 2006-10-16T02:05:59.000Z
EventRecordID 1205
Correlation
- Execution
[ ProcessID] 0
[ ThreadID] 0
Channel Application
Computer epsilon
Security
- EventData
ModuleDll C:\Inetpub\PHP\php5isapi.dll
7F00
--
Edit bug report at http://bugs.php.net/?id=39163&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39163&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39163&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39163&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39163&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39163&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39163&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39163&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39163&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39163&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39163&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39163&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39163&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39163&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39163&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39163&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39163&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39163&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39163&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39163&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39163&r=mysqlcfg
#39163 [Fbk->Opn]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.
ID: 39163
User updated by: tony dot stone at gmail dot com
Reported By: tony dot stone at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Win32API related
Operating System: Windows Vista RC 1 Build 5600
PHP Version: 5.1.6
New Comment:
PHP isn't crashing so there's no way to get a backtrace (that I know
of). I did download the debug files and install them, but there's no
popup or window of any sort that would allow me to click Cancel or
enter a debug view. PHP isn't technically crashing. php5isapi.dll
is making an API call to the OS via the DefaultAppPool in IIS7 and the
DefaultAppPool is shutting down and generating an event log error,
which reads, "Failed to find the RegisterModule entrypoint in the
module DLL C:\Inetpub\PHP\php5isapi.dll. The data is the error."
Maybe I'm just not getting it, but I don't see any way to get the
backtrace info per the directions
(http://bugs.php.net/bugs-generating-backtrace-win32.php) based on this
behavior.
Previous Comments:
[2006-10-16 07:30:10] [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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
----
[2006-10-16 02:45:27] tony dot stone at gmail dot com
Description:
I've seen a few other people post concerning random crashes, but my
issue can be reproduced every time I try to access any web page on my
server since configuring it to use php5isapi.dll
I am running Vista RC1 build 5600 with IIS 7 installed. php5isapi.dll
appears to be making an API call not recognized by the OS. Ever since
I installed PHP my DefaultAppPool stops when I access any web page on
my server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.
Details from App Log:
- System
- Provider
[ Name] Microsoft-Windows-IIS-W3SVC-WP
[ Guid] {670080D9-742A-4187-8D16-41143D1290BD}
[ EventSourceName] W3SVC-WP
- EventID 2295
[ Qualifiers] 49152
Version 0
Level 2
Task 0
Opcode 0
Keywords 0x80
- TimeCreated
[ SystemTime] 2006-10-16T02:05:59.000Z
EventRecordID 1205
Correlation
- Execution
[ ProcessID] 0
[ ThreadID] 0
Channel Application
Computer epsilon
Security
- EventData
ModuleDll C:\Inetpub\PHP\php5isapi.dll
7F00
--
Edit this bug report at http://bugs.php.net/?id=39163&edit=1
#39163 [Fbk->Opn]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.
ID: 39163
User updated by: tony dot stone at gmail dot com
Reported By: tony dot stone at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Win32API related
Operating System: Windows Vista RC 1 Build 5600
PHP Version: 5.1.6
New Comment:
No it doesn't. I installed the following version:
16 Oct 2006 12:40:40 +0200
Version: 5.2.0RC6-dev
Branch
Previous Comments:
[2006-10-17 07:42:10] [EMAIL PROTECTED]
Does it work with 5.2.0 snapshots from http://snaps.php.net/ ?
[2006-10-17 00:43:25] tony dot stone at gmail dot com
PHP isn't crashing so there's no way to get a backtrace (that I know
of). I did download the debug files and install them, but there's no
popup or window of any sort that would allow me to click Cancel or
enter a debug view. PHP isn't technically crashing. php5isapi.dll
is making an API call to the OS via the DefaultAppPool in IIS7 and the
DefaultAppPool is shutting down and generating an event log error,
which reads, "Failed to find the RegisterModule entrypoint in the
module DLL C:\Inetpub\PHP\php5isapi.dll. The data is the error."
Maybe I'm just not getting it, but I don't see any way to get the
backtrace info per the directions
(http://bugs.php.net/bugs-generating-backtrace-win32.php) based on this
behavior.
[2006-10-16 07:30:10] [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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
----
[2006-10-16 02:45:27] tony dot stone at gmail dot com
Description:
I've seen a few other people post concerning random crashes, but my
issue can be reproduced every time I try to access any web page on my
server since configuring it to use php5isapi.dll
I am running Vista RC1 build 5600 with IIS 7 installed. php5isapi.dll
appears to be making an API call not recognized by the OS. Ever since
I installed PHP my DefaultAppPool stops when I access any web page on
my server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.
Details from App Log:
- System
- Provider
[ Name] Microsoft-Windows-IIS-W3SVC-WP
[ Guid] {670080D9-742A-4187-8D16-41143D1290BD}
[ EventSourceName] W3SVC-WP
- EventID 2295
[ Qualifiers] 49152
Version 0
Level 2
Task 0
Opcode 0
Keywords 0x80
- TimeCreated
[ SystemTime] 2006-10-16T02:05:59.000Z
EventRecordID 1205
Correlation
- Execution
[ ProcessID] 0
[ ThreadID] 0
Channel Application
Computer epsilon
Security
- EventData
ModuleDll C:\Inetpub\PHP\php5isapi.dll
7F00
--
Edit this bug report at http://bugs.php.net/?id=39163&edit=1
#39163 [Opn]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.
ID: 39163
User updated by: tony dot stone at gmail dot com
Reported By: tony dot stone at gmail dot com
Status: Open
Bug Type: Win32API related
Operating System: Windows Vista RC 1 Build 5600
PHP Version: 5.1.6
New Comment:
Is there anything else I can do to assist with this?
Previous Comments:
[2006-10-17 11:03:01] tony dot stone at gmail dot com
No it doesn't. I installed the following version:
16 Oct 2006 12:40:40 +0200
Version: 5.2.0RC6-dev
Branch
[2006-10-17 07:42:10] [EMAIL PROTECTED]
Does it work with 5.2.0 snapshots from http://snaps.php.net/ ?
[2006-10-17 00:43:25] tony dot stone at gmail dot com
PHP isn't crashing so there's no way to get a backtrace (that I know
of). I did download the debug files and install them, but there's no
popup or window of any sort that would allow me to click Cancel or
enter a debug view. PHP isn't technically crashing. php5isapi.dll
is making an API call to the OS via the DefaultAppPool in IIS7 and the
DefaultAppPool is shutting down and generating an event log error,
which reads, "Failed to find the RegisterModule entrypoint in the
module DLL C:\Inetpub\PHP\php5isapi.dll. The data is the error."
Maybe I'm just not getting it, but I don't see any way to get the
backtrace info per the directions
(http://bugs.php.net/bugs-generating-backtrace-win32.php) based on this
behavior.
[2006-10-16 07:30:10] [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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
----
[2006-10-16 02:45:27] tony dot stone at gmail dot com
Description:
I've seen a few other people post concerning random crashes, but my
issue can be reproduced every time I try to access any web page on my
server since configuring it to use php5isapi.dll
I am running Vista RC1 build 5600 with IIS 7 installed. php5isapi.dll
appears to be making an API call not recognized by the OS. Ever since
I installed PHP my DefaultAppPool stops when I access any web page on
my server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.
Details from App Log:
- System
- Provider
[ Name] Microsoft-Windows-IIS-W3SVC-WP
[ Guid] {670080D9-742A-4187-8D16-41143D1290BD}
[ EventSourceName] W3SVC-WP
- EventID 2295
[ Qualifiers] 49152
Version 0
Level 2
Task 0
Opcode 0
Keywords 0x80
- TimeCreated
[ SystemTime] 2006-10-16T02:05:59.000Z
EventRecordID 1205
Correlation
- Execution
[ ProcessID] 0
[ ThreadID] 0
Channel Application
Computer epsilon
Security
- EventData
ModuleDll C:\Inetpub\PHP\php5isapi.dll
7F00
--
Edit this bug report at http://bugs.php.net/?id=39163&edit=1
[PHP-BUG] Bug #65571 [NEW]: Compiling fails with - missing binary operator before token "extern"
From: tony dot ar dot wright at bt dot com Operating system: SuSE 9 PHP version: 5.5.3 Package: Compile Failure Bug Type: Bug Bug description:Compiling fails with - missing binary operator before token "extern" Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit bug report at https://bugs.php.net/bug.php?id=65571&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65571&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65571&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65571&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65571&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65571&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65571&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65571&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65571&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65571&r=support Expected behavior: https://bugs.php.net/fix.php?id=65571&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65571&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65571&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65571&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65571&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65571&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65571&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65571&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65571&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65571&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65571&r=mysqlcfg
Bug #51185 [Com]: Apache won't start after PHP 5.3.1 is installed
Edit report at https://bugs.php.net/bug.php?id=51185&edit=1 ID: 51185 Comment by: tony dot bedford at live dot co dot uk Reported by:randy at thehiringsurvey dot com Summary:Apache won't start after PHP 5.3.1 is installed Status: Bogus Type: Bug Package:Windows Installer Operating System: Windows 7 (x64) PHP Version:5.3.1 Block user comment: N Private report: N New Comment: I had the same problem with 5.3.5 on Windows 7 with Apache 2.2. Here's how I fixed it. When reinstalling Apache (as it failed to start after installing PHP) I got the error 'failed to load php5apache2_2.dll'. That of course was a clue. Checking httpd.conf I saw that the PHP installer had not set the PHP ini directory correctly (just empty quotes) and the path to the DLL was not added. I manually fixed these (I installed PHP to C:\PHP) and everything worked fine. By the way, based on comments above and elsewhere, I checked the path was set with correct case. Everything was in order so that wasn't the problem in this case. Hope this helps. Previous Comments: [2010-07-21 21:36:19] smacdav at gmail dot com You're right, of course. I was just realizing the issue and coming back to comment. That was silly of me. Sorry. [2010-07-21 21:30:27] paj...@php.net @smacdav at gmail dot com Your install is a mess then. php 5.2's sapi dll cannot work nor load with 5.3. Please ask php-setup or php-windows mailing for further supports (to any other reporters looking for help regarding the problem described here). [2010-07-21 21:26:58] smacdav at gmail dot com It's not the path variable; it's the dll file. I had exactly the same issue. I made sure my path had the right case and tried starting Apache: no dice. I had backed up my old php (from PHP 5.2.11) folder before installing PHP 5.3, so I tried copying php5apache2_2.dll from the backed up folder into the installation folder for PHP 5.3. Bingo! Apache started up and seems to be running fine. (Haven't tested and PHP 5.3 only features yet, though.) [2010-03-16 00:48:07] randy at thehiringsurvey dot com Two points: 1. I did not have to manually define any PATH variables when I installed PHP 5.2.13 after I had uninstalled 5.3.1. So the 5.2.13 installer is working where the 5.3.1 failed. 2. After I got PHP 5.2.13 running I installed PEAR. I ran into a non-fatal installation problem in PEAR as well. I found out that Windows 7 is case sensitive when referring to PATHs. PEAR was creating it's PATH variable with the directory in all upper, but the actual folder was all lower. That worked on earlier Windows, but not on 7. I don't know which Windows version they made that change in. But once I edited PEAR's PATH variables to match the actual directory case the non-fatal error was resolved. I suspect that PHP 5.3.1's installer is creating a path with the wrong case, based upon the assumption that Windows doesn't care. Can't prove it without uninstalling PHP, and I can't do that right now. [2010-03-16 00:41:04] paj...@php.net @cunobatis at bluewin dot ch that's a configuration problem. Adding the PHP directory to your PATH is a required step when you configure PHP with Apache. 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 https://bugs.php.net/bug.php?id=51185 -- Edit this bug report at https://bugs.php.net/bug.php?id=51185&edit=1
#22792 [NEW]: cannot use include statement inside a class
From: tony at marston-home dot demon dot co dot uk Operating system: WindowsXP PHP version: 4.3.1 PHP Bug Type: Scripting Engine problem Bug description: cannot use include statement inside a class I have a script containing the following: File person.class.inc contains the following: File std.table.class.inc contains the following: When I run it I get the following error: "Parse error: parse error, unexpected T_INCLUDE, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in F:\Apache2\HTDOCS\XAMPLE\std.table.class.inc on line 4" The only variation that actually works is:- $result = include 'test.inc'; BTW, I am using the ISAPI version of PHP under Apache 2.0.44 -- Edit bug report at http://bugs.php.net/?id=22792&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22792&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22792&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22792&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22792&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22792&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22792&r=support Expected behavior: http://bugs.php.net/fix.php?id=22792&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22792&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22792&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22792&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22792&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22792&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22792&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22792&r=gnused
#23939 [NEW]: strpos is case insensitive when it should not be
From: tony at marston-home dot demon dot co dot uk Operating system: WindowsXP PHP version: 4.3.2 PHP Bug Type: Strings related Bug description: strpos is case insensitive when it should not be $haystack contains "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" so why does $pos = strpos($haystack, 's'); return me the position of 'S' instead of 's'? If I wanted a case insensitive search I would use stripos instead. -- Edit bug report at http://bugs.php.net/?id=23939&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23939&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23939&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23939&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23939&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23939&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=23939&r=support Expected behavior: http://bugs.php.net/fix.php?id=23939&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=23939&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=23939&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23939&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23939&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23939&r=dst IIS Stability: http://bugs.php.net/fix.php?id=23939&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=23939&r=gnused
#23939 [Fbk->Csd]: strpos is case insensitive when it should not be
ID: 23939 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Closed Bug Type: Strings related Operating System: WindowsXP PHP Version: 4.3.2 New Comment: Ignore this - I found my mistake. Previous Comments: [2003-06-01 13:49:09] [EMAIL PROTECTED] I cannot confirm this: Outputs: strpos position 44 gives me s stripos position 18 gives me S Can you double check? Tested: Linux, PHP 4.3.2 / 5.0.0 [2003-06-01 13:31:33] tony at marston-home dot demon dot co dot uk $haystack contains "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" so why does $pos = strpos($haystack, 's'); return me the position of 'S' instead of 's'? If I wanted a case insensitive search I would use stripos instead. -- Edit this bug report at http://bugs.php.net/?id=23939&edit=1
#29681 [Fbk->Opn]: Parent: child process exited with status 3221225477
ID: 29681
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-STABLE-2005-01-18
New Comment:
I have tried that snapshot and the problem has not re-appeared. It
appears you have fixed it.
Previous Comments:
[2005-04-29 11:57:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-03-31 09:21:16] mail at kasimir-k dot fi
In addition to my yesterday's comment: I installed PHP 4.3.10 on the
WinXP - no effect on the problem.
And pardon me if I'm too vague, but I'd like to mention that I remember
having this problem a couple times before: once the data got large
enough, my WinXP testing server stopped working, but Linux production
server worked fine - hth.
Also, it seems that this might be an Apache bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=12340
[2005-03-30 12:06:49] mail at kasimir-k dot fi
I have this loop:
for ($i = 0, $_i = count($items); $i < $_i; $i++) {
$item_index[$items[$i]['item_id']] =& $items[$i];
}
I run it on two platforms:
WinXP - PHP 4.3.4 - Apache/2.0.48 (Win32)
Linux - PHP 4.3.10 - Apache/2.0.52 (Fedora)
On Linux - no problems.
On WinXP - once count($item_classes) > 107, the script dies
[2005-01-18 14:55:44] [EMAIL PROTECTED]
The original problem here, reproduced using the script bundle posted by
Tony, triggers crashes in free() when run with "MALLOC_CHECK_=3", using
5.0.4-dev. Backtrace below. Doesn't look like this is
Apache-related:
#5 0x0041baca in free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x010035b7 in _efree (ptr=0x86e443c) at
/net/jedi/local/php/5.0/Zend/zend_alloc.c:287
p = (zend_mem_header *) 0x4e0800
cache_index = 6
#7 0x0101f1fa in zend_hash_destroy (ht=0x86f1714)
at /net/jedi/local/php/5.0/Zend/zend_hash.c:526
p = (Bucket *) 0x0
q = (Bucket *) 0x86e47dc
#8 0x01029c7f in zend_objects_free_object_storage (object=0x872be84)
at /net/jedi/local/php/5.0/Zend/zend_objects.c:91
No locals.
#9 0x0102c24a in zend_objects_store_del_ref (zobject=0x0)
at /net/jedi/local/php/5.0/Zend/zend_objects_API.c:159
handle = 1
obj = (struct _store_object *) 0x86d9b88
#10 0x010170d0 in _zval_dtor (zvalue=0x86efb2c)
at /net/jedi/local/php/5.0/Zend/zend_variables.c:61
No locals.
#11 0x0100c491 in _zval_ptr_dtor (zval_ptr=0x10a995c)
at /net/jedi/local/php/5.0/Zend/zend_execute_API.c:392
No locals.
#12 0x0104b894 in zend_do_fcall_common_helper
(execute_data=0xbff34610,
opline=0x86ee780, op_array=0x86e306c)
at /net/jedi/local/php/5.0/Zend/zend_execute.c:2797
i = 141458196
p = (zval **) 0x86efb2c
arg_count = 17471360
original_return_value = (zval **) 0xbff346ac
current_scope = (zend_class_entry *) 0x0
current_this = (zval *) 0x0
return_value_used = 1
should_change_scope = 1 '\001'
#13 0x0104ba48 in zend_do_fcall_by_name_handler (execute_data=0x0,
opline=0x86ee780,
op_array=0x86e306c) at
/net/jedi/local/php/5.0/Zend/zend_execute.c:2825
No locals.
#14 0x01039b77 in execute (op_array=0x86e306c)
at /net/jedi/local/php/5.0/Zend/zend_execute.c:1400
execute_data = {opline = 0x86ee780, function_state = {
function_symbol_table = 0x870e404, function = 0x872a444, reserved =
{0x100f260,
0x86e3364, 0xbff36970, 0x0}}, fbc = 0x872a444, fbc_constructor =
0x0,
op_array = 0x86e306c, object = 0x86efb2c, Ts = 0xbff33430,
original_in_execution = 0 '\0', calling_scope = 0x86f0a54,
prev_execute_data = 0x0}
#15 0x01018b25 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /net/jedi/local/php/5.0/Zend/zend.c:1069
files = 0xbff34764 ""
i = 1
file_handle = (zend_file_handle *) 0xbff36970
orig_op_array = (zend_op_array *) 0x0
local_retval = (zval *) 0x0
[2004-11-16 12:23:16] php_bug at cklowe dot com
This bug looks to be the same as bug 26286:
http://bugs.php.net/bug.php?id=26286
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/29681
--
Edit this bug report at http://bugs.php.net/?id=29681&edit=1
#33530 [NEW]: str_replace replaces nulls with empty strings
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.0.4
PHP Bug Type: PCRE related
Bug description: str_replace replaces nulls with empty strings
Description:
When I use str_replace on an associative array to replace '' with "\n"
I find that values that were null have been replaced with empty strings.
This affects subsequent processing as an empty string is not the same as
null.
Reproduce code:
---
$pattern[] = "";
$pattern[] = "";
$pattern[] = "";
$replacement = "\n";
$array = array('field1' => '', 'field2' => '', 'field3' => null)
$array = str_replace($pattern, $replacement, $array);
Expected result:
Null values should be left as null values, and not replaced with empty
strings.
Actual result:
--
Values in the array that were null are being replaced with empty strings.
--
Edit bug report at http://bugs.php.net/?id=33530&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33530&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33530&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33530&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33530&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33530&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33530&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33530&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33530&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33530&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33530&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33530&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33530&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33530&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33530&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33530&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33530&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33530&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33530&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33530&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33530&r=mysqlcfg
#33635 [NEW]: Get "couldn't fetch mysqli" error when attempting to write session data to data
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5CVS-2005-07-10 (dev)
PHP Bug Type: MySQLi related
Bug description: Get "couldn't fetch mysqli" error when attempting to write
session data to data
Description:
In my script I use a custom session handler to write all session data to
the database. Through versions 5.0.0 to 5.0.4 this worked as expected, but
with 5.0.5dev I am now getting an error. It only ever failos at the end of
the script when writing out the session data. It always fails at the same
place by generating a "Couldn't fetch mysqli" error.
Reproduce code:
---
function connect ($dbname)
// establish a connection to the database
{
global $dbhost, $dbusername, $dbuserpass;
static $dbconn;
if (!$dbconn) {
$dbconn = mysqli_connect($dbhost, $dbusername, $dbuserpass);
if ($dbconn) {
// use UTF8 for this connection
$this->query = "SET names 'UTF8'";
$result = mysqli_query($dbconn, $this->query) or
trigger_error($this, E_USER_ERROR);
} // if
} // if
if (!$dbconn) {<== FAILS HERE *
return false;
} elseif (!mysqli_select_db($dbconn, $dbname)) {
return false;
} else {
$this->dbconnect = $dbconn;
return true;
} // if
} // connect
The full code is available from http://www.tonymarston.net/text.zip. The
script to run is "test.php".
Expected result:
At that point $dbconn is shown to be "object of mysqli", so it should not
error.
Actual result:
--
At the line "if (!$dbconn)" the program jumps immediately to my error
handler with the error "Couldn't fetch mysqli".
--
Edit bug report at http://bugs.php.net/?id=33635&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33635&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33635&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33635&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33635&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33635&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33635&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33635&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33635&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33635&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33635&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33635&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33635&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33635&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33635&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33635&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33635&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33635&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33635&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33635&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33635&r=mysqlcfg
#33635 [Opn]: Get "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635
User updated by: tony at marston-home dot demon dot co dot uk
-Summary: Get "couldn't fetch mysqli" error when attempting to
write session data to data
Reported By: tony at marston-home dot demon dot co dot uk
Status: Open
Bug Type: MySQLi related
Operating System: Windows XP
PHP Version: 5CVS-2005-07-10 (dev)
New Comment:
Title should read "when attempting to write session data to database"
Previous Comments:
----
[2005-07-10 21:54:00] tony at marston-home dot demon dot co dot uk
Description:
In my script I use a custom session handler to write all session data
to the database. Through versions 5.0.0 to 5.0.4 this worked as
expected, but with 5.0.5dev I am now getting an error. It only ever
failos at the end of the script when writing out the session data. It
always fails at the same place by generating a "Couldn't fetch mysqli"
error.
Reproduce code:
---
function connect ($dbname)
// establish a connection to the database
{
global $dbhost, $dbusername, $dbuserpass;
static $dbconn;
if (!$dbconn) {
$dbconn = mysqli_connect($dbhost, $dbusername, $dbuserpass);
if ($dbconn) {
// use UTF8 for this connection
$this->query = "SET names 'UTF8'";
$result = mysqli_query($dbconn, $this->query) or
trigger_error($this, E_USER_ERROR);
} // if
} // if
if (!$dbconn) {<== FAILS HERE *
return false;
} elseif (!mysqli_select_db($dbconn, $dbname)) {
return false;
} else {
$this->dbconnect = $dbconn;
return true;
} // if
} // connect
The full code is available from http://www.tonymarston.net/text.zip.
The script to run is "test.php".
Expected result:
At that point $dbconn is shown to be "object of mysqli", so it should
not error.
Actual result:
--
At the line "if (!$dbconn)" the program jumps immediately to my error
handler with the error "Couldn't fetch mysqli".
--
Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33635 [Fbk->Opn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows XP
PHP Version: 5CVS-2005-07-10 (dev)
New Comment:
The full test set can be downloaded from
http://www.tonymarston.net/test.zip
Previous Comments:
[2005-07-10 21:56:10] [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-07-10 21:54:00] tony at marston-home dot demon dot co dot uk
Description:
In my script I use a custom session handler to write all session data
to the database. Through versions 5.0.0 to 5.0.4 this worked as
expected, but with 5.0.5dev I am now getting an error. It only ever
failos at the end of the script when writing out the session data. It
always fails at the same place by generating a "Couldn't fetch mysqli"
error.
Reproduce code:
---
function connect ($dbname)
// establish a connection to the database
{
global $dbhost, $dbusername, $dbuserpass;
static $dbconn;
if (!$dbconn) {
$dbconn = mysqli_connect($dbhost, $dbusername, $dbuserpass);
if ($dbconn) {
// use UTF8 for this connection
$this->query = "SET names 'UTF8'";
$result = mysqli_query($dbconn, $this->query) or
trigger_error($this, E_USER_ERROR);
} // if
} // if
if (!$dbconn) {<== FAILS HERE *
return false;
} elseif (!mysqli_select_db($dbconn, $dbname)) {
return false;
} else {
$this->dbconnect = $dbconn;
return true;
} // if
} // connect
The full code is available from http://www.tonymarston.net/text.zip.
The script to run is "test.php".
Expected result:
At that point $dbconn is shown to be "object of mysqli", so it should
not error.
Actual result:
--
At the line "if (!$dbconn)" the program jumps immediately to my error
handler with the error "Couldn't fetch mysqli".
--
Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33635 [Fbk->Opn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows XP
PHP Version: 5CVS-2005-07-10 (dev)
New Comment:
It simply does not fail when I remove all those classes. That is the
smallest I can possibly make it, and I have been working on it all
afternoon.
Previous Comments:
[2005-07-10 22:23:14] [EMAIL PROTECTED]
Please, provide a *short* but *complete* reproduce case without all
those numerous classes, includes etc. Thanks.
[2005-07-10 22:11:19] tony at marston-home dot demon dot co dot uk
The full test set can be downloaded from
http://www.tonymarston.net/test.zip
[2005-07-10 21:56:10] [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-07-10 21:54:00] tony at marston-home dot demon dot co dot uk
Description:
In my script I use a custom session handler to write all session data
to the database. Through versions 5.0.0 to 5.0.4 this worked as
expected, but with 5.0.5dev I am now getting an error. It only ever
failos at the end of the script when writing out the session data. It
always fails at the same place by generating a "Couldn't fetch mysqli"
error.
Reproduce code:
---
function connect ($dbname)
// establish a connection to the database
{
global $dbhost, $dbusername, $dbuserpass;
static $dbconn;
if (!$dbconn) {
$dbconn = mysqli_connect($dbhost, $dbusername, $dbuserpass);
if ($dbconn) {
// use UTF8 for this connection
$this->query = "SET names 'UTF8'";
$result = mysqli_query($dbconn, $this->query) or
trigger_error($this, E_USER_ERROR);
} // if
} // if
if (!$dbconn) {<== FAILS HERE *
return false;
} elseif (!mysqli_select_db($dbconn, $dbname)) {
return false;
} else {
$this->dbconnect = $dbconn;
return true;
} // if
} // connect
The full code is available from http://www.tonymarston.net/text.zip.
The script to run is "test.php".
Expected result:
At that point $dbconn is shown to be "object of mysqli", so it should
not error.
Actual result:
--
At the line "if (!$dbconn)" the program jumps immediately to my error
handler with the error "Couldn't fetch mysqli".
--
Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33635 [Fbk->Opn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) New Comment: php_session class is a subclass of std.table class, so i suppose they could be combined, but it still wouldn't reduce the total code. It is the interaction between the table class and the mysql class which appears to be causing the problem. The point is that the line where it fails is executed without error several times before the failure occurs. If I remove the custom session handler the code never fails. It does not fail when reading the session data, only when writing. Previous Comments: [2005-07-10 23:59:04] [EMAIL PROTECTED] "Smallest possible" doesn't mean that you remove everything. Or does it stop failing when you remove just ONE class? [2005-07-10 23:44:45] tony at marston-home dot demon dot co dot uk It simply does not fail when I remove all those classes. That is the smallest I can possibly make it, and I have been working on it all afternoon. [2005-07-10 22:23:14] [EMAIL PROTECTED] Please, provide a *short* but *complete* reproduce case without all those numerous classes, includes etc. Thanks. [2005-07-10 22:11:19] tony at marston-home dot demon dot co dot uk The full test set can be downloaded from http://www.tonymarston.net/test.zip [2005-07-10 21:56:10] [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. 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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33635 [Fbk->Opn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) New Comment: I have changed the test set as follows: (a) Everything is in a single file (test.php) (b) I have removed the PHP 4 code (=& with objects) (c) I have removed redundant methods. New test set is available at http://www.tonymarston.net/text.zip Previous Comments: [2005-07-11 09:09:47] [EMAIL PROTECTED] 1. Put everything in single file 2. Remove the PHP4 stuff (in PHP5, you don't need to do =& with objects, for example) 3. Remove all unused methods [2005-07-11 00:12:34] tony at marston-home dot demon dot co dot uk php_session class is a subclass of std.table class, so i suppose they could be combined, but it still wouldn't reduce the total code. It is the interaction between the table class and the mysql class which appears to be causing the problem. The point is that the line where it fails is executed without error several times before the failure occurs. If I remove the custom session handler the code never fails. It does not fail when reading the session data, only when writing. [2005-07-10 23:59:04] [EMAIL PROTECTED] "Smallest possible" doesn't mean that you remove everything. Or does it stop failing when you remove just ONE class? ---- [2005-07-10 23:44:45] tony at marston-home dot demon dot co dot uk It simply does not fail when I remove all those classes. That is the smallest I can possibly make it, and I have been working on it all afternoon. [2005-07-10 22:23:14] [EMAIL PROTECTED] Please, provide a *short* but *complete* reproduce case without all those numerous classes, includes etc. Thanks. 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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33635 [Fbk->Opn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) New Comment: Whoops. That URL should be http://www.tonymarston.net/test.zip Previous Comments: [2005-07-11 12:18:12] [EMAIL PROTECTED] Not Found The requested URL /text.zip was not found on this server. [2005-07-11 11:59:48] tony at marston-home dot demon dot co dot uk I have changed the test set as follows: (a) Everything is in a single file (test.php) (b) I have removed the PHP 4 code (=& with objects) (c) I have removed redundant methods. New test set is available at http://www.tonymarston.net/text.zip [2005-07-11 09:09:47] [EMAIL PROTECTED] 1. Put everything in single file 2. Remove the PHP4 stuff (in PHP5, you don't need to do =& with objects, for example) 3. Remove all unused methods [2005-07-11 00:12:34] tony at marston-home dot demon dot co dot uk php_session class is a subclass of std.table class, so i suppose they could be combined, but it still wouldn't reduce the total code. It is the interaction between the table class and the mysql class which appears to be causing the problem. The point is that the line where it fails is executed without error several times before the failure occurs. If I remove the custom session handler the code never fails. It does not fail when reading the session data, only when writing. [2005-07-10 23:59:04] [EMAIL PROTECTED] "Smallest possible" doesn't mean that you remove everything. Or does it stop failing when you remove just ONE class? 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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33635 [Bgs->Opn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Bogus +Status: Open Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) New Comment: You are completely mistaken. I am not mixing both OO and procedural ways of accessing the DB - all my calls to the mysqli_* functions are in the procedural style. The fact that I am making these calls inside my own OO class should be totally irrelevant. The same code has worked perfectly through php 5.0.0 to 5.0.4, and with 5.0.5-dev only fails when I try to write my session data to the database. SOMETHING HAS BEEN INTRODUCED IN 5.0.5-dev THAT CAUSES THIS FAILURE. My use of static variables follows the documentation for the singleton pattern at http://www.php.net/manual/en/language.oop5.patterns.php. It allows to to call mysqli_connect() only once for a request. Previous Comments: [2005-07-11 22:48:09] [EMAIL PROTECTED] Please read the friendly manual about Mysqli. You're trying to mix both OO and procedural way of accessing the DB. Choose one and stick to that. (And I don't get the idea of making the connection 'static' either..especially if you deal with OOP) [2005-07-11 12:33:45] tony at marston-home dot demon dot co dot uk Whoops. That URL should be http://www.tonymarston.net/test.zip [2005-07-11 11:59:48] tony at marston-home dot demon dot co dot uk I have changed the test set as follows: (a) Everything is in a single file (test.php) (b) I have removed the PHP 4 code (=& with objects) (c) I have removed redundant methods. New test set is available at http://www.tonymarston.net/text.zip [2005-07-11 09:09:47] [EMAIL PROTECTED] 1. Put everything in single file 2. Remove the PHP4 stuff (in PHP5, you don't need to do =& with objects, for example) 3. Remove all unused methods ---- [2005-07-11 00:12:34] tony at marston-home dot demon dot co dot uk php_session class is a subclass of std.table class, so i suppose they could be combined, but it still wouldn't reduce the total code. It is the interaction between the table class and the mysql class which appears to be causing the problem. The point is that the line where it fails is executed without error several times before the failure occurs. If I remove the custom session handler the code never fails. It does not fail when reading the session data, only when writing. 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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33695 [NEW]: localconv() returning invalid thousands_sep for France
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 5.0.4 PHP Bug Type: *Languages/Translation Bug description: localconv() returning invalid thousands_sep for France Description: I am using the following code: $locale = setlocale(LC_ALL, 'FRA'); $data = localeconv(); $thousands_sep = $data['thousands_sep']; $ascii = ord($thousands_sep); The value in $ascii is 160 (?) when it should be 32 (space). When I use this with number_format() the result is written to an XML file then transformed into HTML using XSL. The XSL transformation process fails because it is not valid UTF-8. Reproduce code: --- $locale = setlocale(LC_ALL, 'FRA'); $data = localeconv(); $thousands_sep = $data['thousands_sep']; $ascii = ord($thousands_sep); Expected result: ord($thousands_sep) should be 32 (space), not 160 Actual result: -- ord($thousands_sep) is 160 -- Edit bug report at http://bugs.php.net/?id=33695&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33695&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33695&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33695&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33695&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33695&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33695&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33695&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33695&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33695&r=support Expected behavior: http://bugs.php.net/fix.php?id=33695&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33695&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33695&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33695&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33695&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33695&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33695&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33695&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33695&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33695&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33695&r=mysqlcfg
#33635 [Asn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Assigned Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) Assigned To: georg New Comment: This problem only occurs when writing out session data to a database when the script terminates, and also because I am using a shared database connection (the one created when the session data was forst read in). I conducted a little experiment by replacing the exit function with session_write_close(), and this did not produce the error. I therefore strongly suspect that the order of events at script termination has been altered to: (a) close all resources (b) write session data (to database) This will fail if (b) uses a resource closed in (a) Previous Comments: [2005-07-12 01:08:12] [EMAIL PROTECTED] Assigned to the author of the extension, who can propably explain this better.. [2005-07-11 23:55:55] tony at marston-home dot demon dot co dot uk You are completely mistaken. I am not mixing both OO and procedural ways of accessing the DB - all my calls to the mysqli_* functions are in the procedural style. The fact that I am making these calls inside my own OO class should be totally irrelevant. The same code has worked perfectly through php 5.0.0 to 5.0.4, and with 5.0.5-dev only fails when I try to write my session data to the database. SOMETHING HAS BEEN INTRODUCED IN 5.0.5-dev THAT CAUSES THIS FAILURE. My use of static variables follows the documentation for the singleton pattern at http://www.php.net/manual/en/language.oop5.patterns.php. It allows to to call mysqli_connect() only once for a request. [2005-07-11 22:48:09] [EMAIL PROTECTED] Please read the friendly manual about Mysqli. You're trying to mix both OO and procedural way of accessing the DB. Choose one and stick to that. (And I don't get the idea of making the connection 'static' either..especially if you deal with OOP) [2005-07-11 12:33:45] tony at marston-home dot demon dot co dot uk Whoops. That URL should be http://www.tonymarston.net/test.zip [2005-07-11 11:59:48] tony at marston-home dot demon dot co dot uk I have changed the test set as follows: (a) Everything is in a single file (test.php) (b) I have removed the PHP 4 code (=& with objects) (c) I have removed redundant methods. New test set is available at http://www.tonymarston.net/text.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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#29681 [NEW]: Parent: child process exited with status 3221225477
From: tony at marston-home dot demon dot co dot uk Operating system: WindowsXP PHP version: 5.0.1 PHP Bug Type: Apache2 related Bug description: Parent: child process exited with status 3221225477 Description: I am using the Windows binaries for 5.0.1 with MySQL 4.1.3b and Apache 2.0.50 as my development PC. I have a script which runs OK the first time, but if I repeat it straight away it causes Apache to crash and restart. I have stepped through with debug and found the place where it crashes (it is always the same place) but all it is doing is accessing the properties within an object, properties which I have set in a previous call to the same object. I found it impossible to reproduce the bug in 20 lines of code, but what I have done is to isolate the single script and its included modules and gradually removed code until the error disappeared. I have put this code into a zip file for convenience. You can download this zip file at http://www.tonymarston.co.uk/error.zip Reproduce code: --- http://www.tonymarston.co.uk/error.zip -- Edit bug report at http://bugs.php.net/?id=29681&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29681&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29681&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29681&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29681&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29681&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29681&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29681&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29681&r=support Expected behavior: http://bugs.php.net/fix.php?id=29681&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29681&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29681&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29681&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29681&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29681&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29681&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29681&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29681&r=float
#29494 [Opn]: Need format option in DOMDocument->saveXML()
ID: 29494 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0 New Comment: This option would also be nice on DOMDocument->save() when writing the XML document to a disk file. Previous Comments: [2004-08-02 18:10:13] tony at marston-home dot demon dot co dot uk Description: When creating an XML file from DOMDocument->saveXML() it would be very nice to have a format option just like the one in DomDocument->dump_mem(). In this way the XML file can be viewable in my text editor instead of existing on just a single line. There should be a linebreak after every closing tag, and child elements should be indented. -- Edit this bug report at http://bugs.php.net/?id=29494&edit=1
#29494 [Bgs]: Need format option in DOMDocument->saveXML()
ID: 29494 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Bogus Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0 New Comment: You are correct. Pity it was not documented. Previous Comments: [2004-08-22 23:18:53] [EMAIL PROTECTED] The option is already there: $domDocument->formatOutput = true; [2004-08-22 19:39:52] tony at marston-home dot demon dot co dot uk This option would also be nice on DOMDocument->save() when writing the XML document to a disk file. [2004-08-02 18:10:13] tony at marston-home dot demon dot co dot uk Description: When creating an XML file from DOMDocument->saveXML() it would be very nice to have a format option just like the one in DomDocument->dump_mem(). In this way the XML file can be viewable in my text editor instead of existing on just a single line. There should be a linebreak after every closing tag, and child elements should be indented. -- Edit this bug report at http://bugs.php.net/?id=29494&edit=1
#28209 [Com]: strtotime("now")
ID: 28209
Comment by: tony at marston-home dot demon dot co dot uk
Reported By: gamin at centras dot lt
Status: Assigned
Bug Type: Date/time related
Operating System: WinXP HE SP1
PHP Version: 5.0.0RC2
Assigned To: derick
New Comment:
Until this behaviour is fixed so that now() means 'real now' and not
'GNU now' here is a workaround that works in both PHP 4 and PHP 5:
$real_now = date('Y-m-d H:i:s');
$dt1 = strtotime("$real_now -1 day");
$dt2 = date('Y-m-d H:i:s', $dt1);
Previous Comments:
[2004-07-15 09:21:31] kilnight at hotmail dot com
I've been using strtotime() to calculate relative shifts in time, ie.
$real_now = strtotime("2004-07-15 00:16:35");
$exactly_one_day_ago = strtotime("-1 day", $real_now);
echo date('Y-m-d H:i:s', $exactly_one_day_ago)
Expecting "2004-07-14 00:16:35"
but getting: "2004-07-14 00:00:00"
I'm sure there's a way around this, but I'm really not that bright...
so I had to jump back to php4 for the time being.
So I also think that the "now" parameter should be real now, not GNU
"now".
[2004-07-12 21:50:07] patchwork14 at hotmail dot com
Will this bug be fixed before the final php5 release?
A lot of code will need rewriting before php5 is released if "now" is
going to changed.
Wouldn't it be better to have
today = Monday 12th of July 2004 12:00:00 AM
now = Monday 12th of July 2004 08:49:23 PM
[2004-07-05 11:13:44] niels dot hansen at pola dot dk
The functionality is maintained in RC3.
I needs the realtime for logging of process. My workaround is to do
this:
$str=date('d F Y h:i:s A');
$timestamp = strtotime("$str");
[2004-06-15 12:42:47] wb at pro-net dot co dot uk
So how would one, for example, use strtotime() to get the current time
+ 10 mins?
[2004-05-19 12:33:35] [EMAIL PROTECTED]
That's feasible for the rewrite, but for the current parser.
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/28209
--
Edit this bug report at http://bugs.php.net/?id=28209&edit=1
#29681 [Fbk->Opn]: Parent: child process exited with status 3221225477
ID: 29681 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: WindowsXP PHP Version: 5.0.1 New Comment: I have reinstated my sample code at http://www.tonymarston.co.uk/error.zip There are instructions inside on how to reproduce the error. Previous Comments: [2004-10-21 11:34:10] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. There is nothing at that URL any more, please include a minimal reproduction script. [2004-10-11 19:07:26] joel at preacherboy dot net I'm seeing this occur with Apache 2.0.52, PHP 5.0.2, and Windows 2003. I'm not doing anything particularly special in the PHP. Most of the hosted files are 100% HTML going through PHP. [2004-08-14 18:36:27] tony at marston-home dot demon dot co dot uk Description: I am using the Windows binaries for 5.0.1 with MySQL 4.1.3b and Apache 2.0.50 as my development PC. I have a script which runs OK the first time, but if I repeat it straight away it causes Apache to crash and restart. I have stepped through with debug and found the place where it crashes (it is always the same place) but all it is doing is accessing the properties within an object, properties which I have set in a previous call to the same object. I found it impossible to reproduce the bug in 20 lines of code, but what I have done is to isolate the single script and its included modules and gradually removed code until the error disappeared. I have put this code into a zip file for convenience. You can download this zip file at http://www.tonymarston.co.uk/error.zip Reproduce code: --- http://www.tonymarston.co.uk/error.zip -- Edit this bug report at http://bugs.php.net/?id=29681&edit=1
#29588 [Fbk->Opn]: $errcontext no longer shows object reference
ID: 29588
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: WindowsXP
PHP Version: 5.0.0
New Comment:
Yes, that works now.
Previous Comments:
[2005-02-28 21:23:52] [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-08-09 17:24:10] tony at marston-home dot demon dot co dot uk
Description:
I have a class called 'mysql' which deals with all MySQL function
calls. It contains the following code:
$result = mysqli_query($link, $query) or trigger_error("SQL",
E_USER_ERROR);
In the event of a fatal error it calls my custom error handler which
accesses all 5 arguments ($errno, $errstr, $errfile, $errline,
$errcontext).
With PHP 4 $errcontext contains the following:
Array
(
[this] => mysql Object
(
... class variables appear here ...
)
[dbname] => sample
[tablename] => pers_opt_xref
[where] => ...
[result] =>
)
With PHP 5 the same error produces the following:
Array
(
[dbname] => sample
[tablename] => pers_opt_xref
[where] => ...
[result] =>
)
You will note that the object references are completely missing. This
is preventing me from determining that the error came from my 'mysql'
object and therefore obtaining the current values for mysql_errno() and
mysql_error().
Expected result:
If the error is triggered from within an object I expect $errcontext to
contain an object reference as stated in the manual at
http://www.php.net/manual/en/function.set-error-handler.php
Actual result:
--
If triggered from within an object $errcontext does not contain any
object references.
--
Edit this bug report at http://bugs.php.net/?id=29588&edit=1
#24934 [NEW]: create_text_node() does not handle special characters
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 4.3.2 PHP Bug Type: DOM XML related Bug description: create_text_node() does not handle special characters Description: I have a field with the value "Cote d'Ivoire" (where the letter 'o' is actually 'o circumflex') which is not being deal with correctly by $doc->create_text_node(). If I pass the text through htmlentities() beforehand what appears in the XML output is "Côte d'Ivoire" instead of "Côte d'Ivoire". If I do not use htmlentities() on the value the output is "C�'Ivoire" (which is totally corrupt) instead of "Côte d'Ivoire" (which is what I expect). A similar fault exists with all the other special charcters I have tried, such as 'c cedila' etc. Expected result: If my input is "Co(circumflex)te d'Ivoire" I expect the output to be "Côte d'Ivoire" Actual result: -- Instead of "Côte d'Ivoire" I am getting "C�'Ivoire" -- Edit bug report at http://bugs.php.net/?id=24934&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24934&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24934&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24934&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24934&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24934&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24934&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24934&r=support Expected behavior: http://bugs.php.net/fix.php?id=24934&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24934&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24934&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24934&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24934&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24934&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24934&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24934&r=gnused
#24934 [Fbk->Opn]: create_text_node() does not handle special characters
ID: 24934
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.3.2
New Comment:
Here is a test script which demonstrates this bug:
create_element('root');
$root = $doc->append_child($root);
// create record node
$occ = $doc->create_element('record');
$occ = $root->append_child($occ);
// insert each field as a child node
foreach ($fieldarray as $fieldname => $fieldvalue) {
$child = $doc->create_element($fieldname);
$child = $occ->append_child($child);
$value = $doc->create_text_node($fieldvalue);
$value = $child->append_child($value);
} // foreach
unset($fieldarray);
// get completed xml document
$xml_string = $doc->dump_mem(true);
unset($xml_doc);
// dump to a disk file with '.xml' extension
$fname = basename($_SERVER['PHP_SELF']) .'.xml' ;
$fp = fopen($fname, 'w');
$result = fwrite($fp, $xml_string);
fclose($fp);
exit;
?>
If you try to load the XML file into your browser you will see that it
contains corrupt characters. For example where is should have 'ô'
for ô (letter o with circumflex) it has '�' instead. Basically
the $doc->create_text_node() method is not translating special
characters into the right hex code according to the HTML specification.
Previous Comments:
[2003-08-08 17:45:51] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
can you provide a small script as I cant reproduce the corruption you
are getting
[2003-08-04 08:47:14] tony at marston-home dot demon dot co dot uk
Description:
I have a field with the value "Cote d'Ivoire" (where the letter 'o' is
actually 'o circumflex') which is not being deal with correctly by
$doc->create_text_node().
If I pass the text through htmlentities() beforehand what appears in
the XML output is "Côte d'Ivoire" instead of "Côte
d'Ivoire".
If I do not use htmlentities() on the value the output is
"C�'Ivoire" (which is totally corrupt) instead of "Côte
d'Ivoire" (which is what I expect).
A similar fault exists with all the other special charcters I have
tried, such as 'c cedila' etc.
Expected result:
If my input is "Co(circumflex)te d'Ivoire" I expect the output to be
"Côte d'Ivoire"
Actual result:
--
Instead of "Côte d'Ivoire" I am getting "C�'Ivoire"
--
Edit this bug report at http://bugs.php.net/?id=24934&edit=1
#29494 [NEW]: Need format option in DOMDocument->saveXML()
From: tony at marston-home dot demon dot co dot uk Operating system: * PHP version: 5.0.0 PHP Bug Type: Feature/Change Request Bug description: Need format option in DOMDocument->saveXML() Description: When creating an XML file from DOMDocument->saveXML() it would be very nice to have a format option just like the one in DomDocument->dump_mem(). In this way the XML file can be viewable in my text editor instead of existing on just a single line. There should be a linebreak after every closing tag, and child elements should be indented. -- Edit bug report at http://bugs.php.net/?id=29494&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29494&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29494&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29494&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29494&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29494&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29494&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29494&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29494&r=support Expected behavior: http://bugs.php.net/fix.php?id=29494&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29494&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29494&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29494&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29494&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29494&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29494&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29494&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29494&r=float
#29495 [NEW]: New DOM and XSL classes should throw exceptions.
From: tony at marston-home dot demon dot co dot uk Operating system: * PHP version: 5.0.0 PHP Bug Type: Feature/Change Request Bug description: New DOM and XSL classes should throw exceptions. Description: I have just started using the new DOM and XSL classes in PHP5, and one thing I really find annoying is the difficulty in trapping errors. I tried to use the new try... catch... syntax but this does not work. I have worked out another way of detecting errors from these two classes, but it is very messy. Can they be changed to use the new try...cath... syntax? -- Edit bug report at http://bugs.php.net/?id=29495&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29495&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29495&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29495&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29495&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29495&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29495&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29495&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29495&r=support Expected behavior: http://bugs.php.net/fix.php?id=29495&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29495&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29495&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29495&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29495&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29495&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29495&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29495&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29495&r=float
#29496 [NEW]: Output from XSL transformation should not contain xmlns=""
From: tony at marston-home dot demon dot co dot uk Operating system: * PHP version: 5.0.0 PHP Bug Type: Feature/Change Request Bug description: Output from XSL transformation should not contain xmlns="" Description: I produce all my HTML output from XSL transformations and I do not bother with any namespaces, yet my output is clutterred with a lot of xmlns="" statements. If the namespace is null this statement should not be included in the output. -- Edit bug report at http://bugs.php.net/?id=29496&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29496&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29496&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29496&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29496&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29496&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29496&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29496&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29496&r=support Expected behavior: http://bugs.php.net/fix.php?id=29496&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29496&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29496&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29496&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29496&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29496&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29496&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29496&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29496&r=float
#29497 [NEW]: xsltprocessor->setParameter() to accept an array
From: tony at marston-home dot demon dot co dot uk Operating system: * PHP version: 5.0.0 PHP Bug Type: Feature/Change Request Bug description: xsltprocessor->setParameter() to accept an array Description: The xsltprocessor->setParameter() method currently only accepts one parameter at a time. It would be more convenient if this could also accept an array of parameters in one go just like the xslt_process() function in PHP4. -- Edit bug report at http://bugs.php.net/?id=29497&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29497&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29497&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29497&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29497&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29497&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29497&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29497&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29497&r=support Expected behavior: http://bugs.php.net/fix.php?id=29497&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29497&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29497&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29497&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29497&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29497&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29497&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29497&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29497&r=float
#29497 [Csd]: xsltprocessor->setParameter() to accept an array
ID: 29497 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Closed Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0 New Comment: I downloaded that snapshot and tried $xp->setParameter($namespace, $array) instead of $xp->setParameter($namespace, 'name', $value) and it worked. However, several times something caused Apache to abort and restart. I reverted to my old code and it still caused Apache to fail now and then. There appears to be a bug somewhere else in this snapshot. Previous Comments: [2004-08-05 16:50: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-08-02 19:17:20] tony at marston-home dot demon dot co dot uk Description: The xsltprocessor->setParameter() method currently only accepts one parameter at a time. It would be more convenient if this could also accept an array of parameters in one go just like the xslt_process() function in PHP4. -- Edit this bug report at http://bugs.php.net/?id=29497&edit=1
#29497 [Fbk->Opn]: xsltprocessor->setParameter() to accept an array
ID: 29497 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0 New Comment: I am unable to produce a sample script of such a small size as (a) all my scripts are much larger, (b) the error happens at random so I do not know which command is causing it. All I can tell you is that while running the system on my Windows XP box the pages would display OK except for every 3rd or 4th iteration. Previous Comments: [2004-08-06 08:34:34] [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 avoid embedding huge scripts into the report. [2004-08-05 21:23:45] tony at marston-home dot demon dot co dot uk I downloaded that snapshot and tried $xp->setParameter($namespace, $array) instead of $xp->setParameter($namespace, 'name', $value) and it worked. However, several times something caused Apache to abort and restart. I reverted to my old code and it still caused Apache to fail now and then. There appears to be a bug somewhere else in this snapshot. [2004-08-05 16:50: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-08-02 19:17:20] tony at marston-home dot demon dot co dot uk Description: The xsltprocessor->setParameter() method currently only accepts one parameter at a time. It would be more convenient if this could also accept an array of parameters in one go just like the xslt_process() function in PHP4. -- Edit this bug report at http://bugs.php.net/?id=29497&edit=1
#29588 [NEW]: $errcontext no longer shows object reference
From: tony at marston-home dot demon dot co dot uk
Operating system: WindowsXP
PHP version: 5.0.0
PHP Bug Type: Unknown/Other Function
Bug description: $errcontext no longer shows object reference
Description:
I have a class called 'mysql' which deals with all MySQL function calls.
It contains the following code:
$result = mysqli_query($link, $query) or trigger_error("SQL",
E_USER_ERROR);
In the event of a fatal error it calls my custom error handler which
accesses all 5 arguments ($errno, $errstr, $errfile, $errline,
$errcontext).
With PHP 4 $errcontext contains the following:
Array
(
[this] => mysql Object
(
... class variables appear here ...
)
[dbname] => sample
[tablename] => pers_opt_xref
[where] => ...
[result] =>
)
With PHP 5 the same error produces the following:
Array
(
[dbname] => sample
[tablename] => pers_opt_xref
[where] => ...
[result] =>
)
You will note that the object references are completely missing. This is
preventing me from determining that the error came from my 'mysql' object
and therefore obtaining the current values for mysql_errno() and
mysql_error().
Expected result:
If the error is triggered from within an object I expect $errcontext to
contain an object reference as stated in the manual at
http://www.php.net/manual/en/function.set-error-handler.php
Actual result:
--
If triggered from within an object $errcontext does not contain any object
references.
--
Edit bug report at http://bugs.php.net/?id=29588&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29588&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29588&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29588&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29588&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29588&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29588&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29588&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29588&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29588&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29588&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29588&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29588&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29588&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29588&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29588&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29588&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29588&r=float
#49235 [NEW]: mbstring.func_overload cannot be set via ini_set() or in htaccess
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.2.10
PHP Bug Type: mbstring related
Bug description: mbstring.func_overload cannot be set via ini_set() or in
htaccess
Description:
Cannot set mbstring.func_overload via ini_set(), nor in htaccess
Reproduce code:
---
$result1 = ini_set('mbstring.func_overload', 2); // false
$result2 = ini_get('mbstring.func_overload'); // 0 (should be 2)
Expected result:
$result2 should be 2 as a result of the previous ini_set().
Actual result:
--
ini_get() returns a result of 0 when it should be 2.
--
Edit bug report at http://bugs.php.net/?id=49235&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49235&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49235&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49235&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49235&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49235&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49235&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49235&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49235&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49235&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49235&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49235&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49235&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49235&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49235&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49235&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49235&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49235&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49235&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49235&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49235&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49235&r=mysqlcfg
#49238 [NEW]: mbstring.func_overload cannot be set in htaccess
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.2.10
PHP Bug Type: mbstring related
Bug description: mbstring.func_overload cannot be set in htaccess
Description:
My PHP.INI file contains the following:
;mbstring.internal_encoding EUC-JP
;mbstring.func_overload = 0
My htaccess file contains the following:
php_value mbstring.internal_encoding "UTF-8"
php_value mbstring.func_overload 2
When I run phpinfo() it shows that the value for
mbstring.internal_encoding has been changed, but the value for
mbstring.func_overload is still 0. When I try to run strtoupper() on a
string which contains a multibyte character the result is incorrect.
Reproduce code:
---
$upper = strtoupper('würzburg');
if ($upper != 'WÃœRZBURG') {
echo 'test failed!';
} // if
Expected result:
I expect the above code to work without the 'test failed!' message.
Actual result:
--
$upper contains 'WÃŒRZBURG'
--
Edit bug report at http://bugs.php.net/?id=49238&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49238&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49238&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49238&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49238&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49238&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49238&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49238&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49238&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49238&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49238&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49238&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49238&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49238&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49238&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49238&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49238&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49238&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49238&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49238&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49238&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49238&r=mysqlcfg
#49235 [Bgs]: mbstring.func_overload cannot be set via ini_set() or in htaccess
ID: 49235
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
mbstring.func_overload cannot be set in htaccess. See bug #49238
Previous Comments:
[2009-08-12 13:16:31] scott...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The setting is PHP_INI_PERDIR which means in .htaccess or in php.ini,
the .htaccess method works for me.
ini_set() will not work
[2009-08-12 13:03:17] tony at marston-home dot demon dot co dot uk
Description:
Cannot set mbstring.func_overload via ini_set(), nor in htaccess
Reproduce code:
---
$result1 = ini_set('mbstring.func_overload', 2); // false
$result2 = ini_get('mbstring.func_overload'); // 0 (should be 2)
Expected result:
$result2 should be 2 as a result of the previous ini_set().
Actual result:
--
ini_get() returns a result of 0 when it should be 2.
--
Edit this bug report at http://bugs.php.net/?id=49235&edit=1
#49238 [Bgs]: mbstring.func_overload cannot be set in htaccess
ID: 49238
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
I DID search first on 'MBstring issues', but bug #49189 was catalogued
as a documentation issue, so how was I to spot it?
Bug #49189 refers to bug #43227 as "proof" (supposedly) that
mbstring.func_overload was changed from PHP_INI_PERDIR to
PHP_INI_SYSTEM, but it says no such thing. It simply says "try
mbstring.func_overload = 0 in your php.ini as a workaround"
Previous Comments:
[2009-08-12 18:22:39] j...@php.net
It can only be set in php.ini. Not a bug. See also bug #49189 and next
time: SEARCH first before submitting another bug about same issue.
----
[2009-08-12 17:14:58] tony at marston-home dot demon dot co dot uk
Description:
My PHP.INI file contains the following:
;mbstring.internal_encoding EUC-JP
;mbstring.func_overload = 0
My htaccess file contains the following:
php_value mbstring.internal_encoding "UTF-8"
php_value mbstring.func_overload 2
When I run phpinfo() it shows that the value for
mbstring.internal_encoding has been changed, but the value for
mbstring.func_overload is still 0. When I try to run strtoupper() on a
string which contains a multibyte character the result is incorrect.
Reproduce code:
---
$upper = strtoupper('würzburg');
if ($upper != 'WÃœRZBURG') {
echo 'test failed!';
} // if
Expected result:
I expect the above code to work without the 'test failed!' message.
Actual result:
--
$upper contains 'WÃŒRZBURG'
--
Edit this bug report at http://bugs.php.net/?id=49238&edit=1
#49238 [Bgs]: mbstring.func_overload cannot be set in htaccess
ID: 49238
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
There was nothing about this in the contents of the patch as it still
shows that 'func_overload' is linked to PHP_INI_PERDIR, so it would
appear that the decision was made "behind the scenes", in secret,
without telling anyone. There was no mention of this in the release
notes, and the documentation has NEVER been updated to reflect this
decision even after 6 months has passed.
This feature has been available since version 4.2.0, now suddenly it
does not work. If my site is on a shared server, meaning that I cannot
change the contents of either php.ini or httpd.conf, and func_overload
is set to 0, then how on earth can I turn it on?
Previous Comments:
[2009-08-13 09:00:04] j...@php.net
Yes, the bug report itself is vague, but it was also mentioned in the
commit message that changes this.. :)
[2009-08-12 18:42:08] tony at marston-home dot demon dot co dot uk
I DID search first on 'MBstring issues', but bug #49189 was catalogued
as a documentation issue, so how was I to spot it?
Bug #49189 refers to bug #43227 as "proof" (supposedly) that
mbstring.func_overload was changed from PHP_INI_PERDIR to
PHP_INI_SYSTEM, but it says no such thing. It simply says "try
mbstring.func_overload = 0 in your php.ini as a workaround"
[2009-08-12 18:22:39] j...@php.net
It can only be set in php.ini. Not a bug. See also bug #49189 and next
time: SEARCH first before submitting another bug about same issue.
----
[2009-08-12 17:14:58] tony at marston-home dot demon dot co dot uk
Description:
My PHP.INI file contains the following:
;mbstring.internal_encoding EUC-JP
;mbstring.func_overload = 0
My htaccess file contains the following:
php_value mbstring.internal_encoding "UTF-8"
php_value mbstring.func_overload 2
When I run phpinfo() it shows that the value for
mbstring.internal_encoding has been changed, but the value for
mbstring.func_overload is still 0. When I try to run strtoupper() on a
string which contains a multibyte character the result is incorrect.
Reproduce code:
---
$upper = strtoupper('würzburg');
if ($upper != 'WÃœRZBURG') {
echo 'test failed!';
} // if
Expected result:
I expect the above code to work without the 'test failed!' message.
Actual result:
--
$upper contains 'WÃŒRZBURG'
--
Edit this bug report at http://bugs.php.net/?id=49238&edit=1
#49238 [Bgs]: mbstring.func_overload cannot be set in htaccess
ID: 49238
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
It should also be pointed out that if func_overload is turned ON
globally then phpMyAdmin, the most widely used administration program
for MySQL databases, will issue a message warning about possible data
corruption. That is why the decision to remove the PHP_INI_PERDIR option
is a bad one and should be reversed.
Previous Comments:
[2009-08-13 09:19:19] tony at marston-home dot demon dot co dot uk
There was nothing about this in the contents of the patch as it still
shows that 'func_overload' is linked to PHP_INI_PERDIR, so it would
appear that the decision was made "behind the scenes", in secret,
without telling anyone. There was no mention of this in the release
notes, and the documentation has NEVER been updated to reflect this
decision even after 6 months has passed.
This feature has been available since version 4.2.0, now suddenly it
does not work. If my site is on a shared server, meaning that I cannot
change the contents of either php.ini or httpd.conf, and func_overload
is set to 0, then how on earth can I turn it on?
[2009-08-13 09:00:04] j...@php.net
Yes, the bug report itself is vague, but it was also mentioned in the
commit message that changes this.. :)
[2009-08-12 18:42:08] tony at marston-home dot demon dot co dot uk
I DID search first on 'MBstring issues', but bug #49189 was catalogued
as a documentation issue, so how was I to spot it?
Bug #49189 refers to bug #43227 as "proof" (supposedly) that
mbstring.func_overload was changed from PHP_INI_PERDIR to
PHP_INI_SYSTEM, but it says no such thing. It simply says "try
mbstring.func_overload = 0 in your php.ini as a workaround"
[2009-08-12 18:22:39] j...@php.net
It can only be set in php.ini. Not a bug. See also bug #49189 and next
time: SEARCH first before submitting another bug about same issue.
----
[2009-08-12 17:14:58] tony at marston-home dot demon dot co dot uk
Description:
My PHP.INI file contains the following:
;mbstring.internal_encoding EUC-JP
;mbstring.func_overload = 0
My htaccess file contains the following:
php_value mbstring.internal_encoding "UTF-8"
php_value mbstring.func_overload 2
When I run phpinfo() it shows that the value for
mbstring.internal_encoding has been changed, but the value for
mbstring.func_overload is still 0. When I try to run strtoupper() on a
string which contains a multibyte character the result is incorrect.
Reproduce code:
---
$upper = strtoupper('würzburg');
if ($upper != 'WÃœRZBURG') {
echo 'test failed!';
} // if
Expected result:
I expect the above code to work without the 'test failed!' message.
Actual result:
--
$upper contains 'WÃŒRZBURG'
--
Edit this bug report at http://bugs.php.net/?id=49238&edit=1
#50285 [NEW]: xmlrpc_server_call_method does not preserve keys in indexed arrays
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.3.1
PHP Bug Type: *General Issues
Bug description: xmlrpc_server_call_method does not preserve keys in indexed
arrays
Description:
When the method called in xmlrpc_server_call_method() returns an array
where the keys are numeric but non-sequential it does not include the keys
in the xml response, so when that response is decoded by the client all the
keys are resequenced from zero. This means that all the original keys are
lost.
Reproduce code:
---
function indexedArray ( $func, $params) {
return array(1=>'One', 3=>'Three', 5=>'Five');
} // indexedArray
$server = xmlrpc_server_create();
$result = xmlrpc_server_register_method($server, 'indexedArray',
'indexedArray');
$HTTP_RAW_POST_DATA = <<
indexedArray
EOD;
$response = xmlrpc_server_call_method($server, $HTTP_RAW_POST_DATA,
null);
$array = xmlrpc_decode($response);
Expected result:
The contents of $array should read (1=>'One', 3=>'Three', 5=>'Five'). This
is because the xml document does not contain any elements for each
.
Actual result:
--
The contents of $array is (0=>'One', 1=>'Three', 2=>'Five')
--
Edit bug report at http://bugs.php.net/?id=50285&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50285&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50285&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50285&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50285&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50285&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50285&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50285&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50285&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50285&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50285&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50285&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50285&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50285&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50285&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50285&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50285&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50285&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50285&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50285&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50285&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50285&r=mysqlcfg
#50285 [Opn]: xmlrpc_server_call_method does not preserve keys in indexed arrays
ID: 50285
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Open
-Bug Type: *General Issues
+Bug Type: XMLRPC-EPI related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
This is not 'general', it is XMLRPC related.
Previous Comments:
[2009-11-24 14:55:34] tony at marston-home dot demon dot co dot uk
Description:
When the method called in xmlrpc_server_call_method() returns an array
where the keys are numeric but non-sequential it does not include the
keys in the xml response, so when that response is decoded by the client
all the keys are resequenced from zero. This means that all the original
keys are lost.
Reproduce code:
---
function indexedArray ( $func, $params) {
return array(1=>'One', 3=>'Three', 5=>'Five');
} // indexedArray
$server = xmlrpc_server_create();
$result = xmlrpc_server_register_method($server, 'indexedArray',
'indexedArray');
$HTTP_RAW_POST_DATA = <<
indexedArray
EOD;
$response = xmlrpc_server_call_method($server, $HTTP_RAW_POST_DATA,
null);
$array = xmlrpc_decode($response);
Expected result:
The contents of $array should read (1=>'One', 3=>'Three', 5=>'Five').
This is because the xml document does not contain any elements
for each .
Actual result:
--
The contents of $array is (0=>'One', 1=>'Three', 2=>'Five')
--
Edit this bug report at http://bugs.php.net/?id=50285&edit=1
#45771 [NEW]: Cannot load php_pgsql.dll
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 5.3.0alpha1 PHP Bug Type: PostgreSQL related Bug description: Cannot load php_pgsql.dll Description: Your stupid system won't allow me to report this bug under version 4.4.9 After upgrading from 4.4.8 to 4.4.9 the PostgresSQL database is unusable. When I start Apache (version 2.0.63) I get the following message: Unknown(): Unable to load dynamic library 'F:/php4/extensions/php_pgsql.dll' - The specified module could not be found. -- Edit bug report at http://bugs.php.net/?id=45771&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45771&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45771&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45771&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45771&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45771&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45771&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45771&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45771&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45771&r=support Expected behavior:http://bugs.php.net/fix.php?id=45771&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45771&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45771&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45771&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45771&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45771&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45771&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45771&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45771&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45771&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45771&r=mysqlcfg
#45771 [WFx]: Cannot load php_pgsql.dll
ID: 45771 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Wont fix Bug Type: PostgreSQL related Operating System: Windows XP PHP Version: 4.4.9 Assigned To: pajoye New Comment: Whether PHP 4 is still supported or not is irrelevant - that is no excuse for issuing a release that has bugs. Previous Comments: [2008-08-09 11:32:35] [EMAIL PROTECTED] "Your stupid system won't allow me to report this bug under version 4.4.9" If something is stupid is the fact to (still) use php4. What do you need to understand that we do not support php 4.x anymore? That we will not fix anybug, we will not release it anymore, never. However, if you still want to use php4, take the pgsql extension from 4.4.8 or fetch the libpq.dll from here and put it in your usual place: http://downloads.php.net/pierre/libpq-php-4.4.9-5.2.6.zip [2008-08-09 11:00:57] tony at marston-home dot demon dot co dot uk Description: Your stupid system won't allow me to report this bug under version 4.4.9 After upgrading from 4.4.8 to 4.4.9 the PostgresSQL database is unusable. When I start Apache (version 2.0.63) I get the following message: Unknown(): Unable to load dynamic library 'F:/php4/extensions/php_pgsql.dll' - The specified module could not be found. -- Edit this bug report at http://bugs.php.net/?id=45771&edit=1
#40186 [Fbk->Opn]: ORA-00932: inconsistent datatypes: expected CHAR got ARRAY
ID: 40186
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: Windows XP
PHP Version: 5.2.0
Assigned To: tony2001
New Comment:
I have tried loading that snapshot, but I am still getting the same
error. The call to oci_fetch_array() fails with "ORA-00932: inconsistent
datatypes: expected CHAR got ARRAY"
Previous Comments:
[2008-11-10 11:25:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2007-01-31 10:37:03] tony at marston-home dot demon dot co dot uk
When I try the following:
$stmt = ociParse($dbconn, "SELECT favourite_food FROM x_person");
oci_bind_array_by_name($stmt, 'favourite_food', $foods, 10, -1,
SQLT_NUM);
oci_execute($stmt);
while(oci_fetch($stmt)) {
print_r($foods);
}
it fails with ORA-01036: illegal variable name/number.
When I try the following:
$stmt = ociParse($dbconn, "SELECT :favourite_food FROM x_person");
oci_bind_array_by_name($stmt, ':favourite_food', $foods, 10, -1,
SQLT_NUM);
oci_execute($stmt);
while(oci_fetch($stmt)) {
print_r($foods);
}
it fails with ORA-01484: arrays can only be bound to PL/SQL statements.
[2007-01-30 19:38:25] [EMAIL PROTECTED]
You can and I've already pointed you out how to do it, but you don't
want even to try.
[2007-01-30 19:21:43] tony at marston-home dot demon dot co dot uk
MySQL's SET datatype and PostgreSQL's ARRAY datatype are identical in
functionality to Oracle's VARRAY datatype in that they can hold arrays
of values instead of single values.
It is not unreasonable of me to expect to be able to write to a
SET/ARRAY/VARRAY column and read that data back again. I can do this
with the TOAD admin tool and Oracle SQL Developer, so why can't I do it
with the OCI8 extension?
[2007-01-30 18:53:53] [EMAIL PROTECTED]
>So just because I want to do something with Oracle that I
>can already do with MySQL and PostgreSQL you call me
>obstinate and pedantic?
Oracle does not have SET or ENUM datatypes.
Oracle does not support LIMIT clause.
Oracle does not convert dates to strings and vice versa automatically.
Oracle's SQL dialect is different from the dialects used in MySQL &
PostgreSQL.
There are much more things you CAN do in MySQL and/or Postgres, but
CAN'T do in Oracle.
Do you think they are PHP bugs too?
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/40186
--
Edit this bug report at http://bugs.php.net/?id=40186&edit=1
#50459 [NEW]: CURLINFO_HEADER_OUT does not work
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 5.3.1 PHP Bug Type: cURL related Bug description: CURLINFO_HEADER_OUT does not work Description: The following line always returns FALSE: $info = curl_getinfo($ch, CURLINFO_HEADER_OUT); Reproduce code: --- $request = << menu.getAnswer EOD; $header[] = "Content-type: text/xml"; $header[] = "User-Agent: foobar"; $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HTTPHEADER, $header); curl_setopt($ch, CURLOPT_HEADER, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $request); $response = curl_exec($ch); $info = curl_getinfo($ch, CURLINFO_HEADER_OUT); Expected result: According to the documentation this option has been available since version 5.1.3, so I expect to see the request headers which were sent out. Actual result: -- The result is always FALSE. -- Edit bug report at http://bugs.php.net/?id=50459&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50459&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50459&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50459&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50459&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50459&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50459&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50459&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50459&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50459&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50459&r=support Expected behavior: http://bugs.php.net/fix.php?id=50459&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50459&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50459&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50459&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50459&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50459&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50459&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50459&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50459&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50459&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50459&r=mysqlcfg
#50953 [NEW]: fsockopen will not work on 'localhost'
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.2.12
PHP Bug Type: Sockets related
Bug description: fsockopen will not work on 'localhost'
Description:
If I use fsockopen with host 'localhost' it fails, but it works with
'127.0.0.1' or any other host name.
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring ."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit bug report at http://bugs.php.net/?id=50953&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50953&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50953&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50953&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50953&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50953&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50953&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50953&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50953&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50953&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50953&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50953&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50953&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50953&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50953&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50953&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50953&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50953&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50953&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50953&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50953&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50953&r=mysqlcfg
#50953 [Fbk->Opn]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
Yes, but why should this make a difference? I have another Windows XP
PC running PHP 5.3.0 and that works OK. I have just upgraded this PC
from PHP 4.4.9 to 5.2.12, and it worked OK in PHP 4.
Is it something to do with the fact that IPV6 support is enabled in PHP
5.2.12 but disabled in PHP 5.3.0? Is this a PHP problem and not an OS
problem?
FYI my hosts file contains the following:
127.0.0.1 localhost
::1 localhost
127.0.0.1 laptop
192.168.1.64desktop
Previous Comments:
[2010-02-07 16:07:01] paj...@php.net
Did you install IPv6 support for XP?
[2010-02-07 13:31:42] tony at marston-home dot demon dot co dot uk
Description:
If I use fsockopen with host 'localhost' it fails, but it works with
'127.0.0.1' or any other host name.
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
I have tried that, but it still doesn't work.
Previous Comments:
[2010-02-07 17:15:21] paj...@php.net
Comment out the IPv6 entries for localhost (see the other bogus reports
for detailed explanations).
[2010-02-07 16:28:31] tony at marston-home dot demon dot co dot uk
Yes, but why should this make a difference? I have another Windows XP
PC running PHP 5.3.0 and that works OK. I have just upgraded this PC
from PHP 4.4.9 to 5.2.12, and it worked OK in PHP 4.
Is it something to do with the fact that IPV6 support is enabled in PHP
5.2.12 but disabled in PHP 5.3.0? Is this a PHP problem and not an OS
problem?
FYI my hosts file contains the following:
127.0.0.1 localhost
::1 localhost
127.0.0.1 laptop
192.168.1.64desktop
[2010-02-07 16:07:01] paj...@php.net
Did you install IPv6 support for XP?
[2010-02-07 13:31:42] tony at marston-home dot demon dot co dot uk
Description:
If I use fsockopen with host 'localhost' it fails, but it works with
'127.0.0.1' or any other host name.
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50956 [NEW]: SOAP-ERROR: parsing schema
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 5.2.12 PHP Bug Type: SOAP related Bug description: SOAP-ERROR: parsing schema Description: I am calling a soap service using the WSDL supplied by the service provider, but it is failing when I try to create the soap client. The error message is: SOAP-ERROR: Parsing Schema: unexpected in element Reproduce code: --- The wsdl file contains entries such as: blah blah blah If I put '' around the element the error disappears. Expected result: As the element is merely there for documentation purposes it should be ignored instead of causing an error. -- Edit bug report at http://bugs.php.net/?id=50956&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50956&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50956&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50956&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50956&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50956&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50956&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50956&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50956&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50956&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50956&r=support Expected behavior: http://bugs.php.net/fix.php?id=50956&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50956&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50956&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50956&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50956&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50956&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50956&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50956&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50956&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50956&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50956&r=mysqlcfg
#50965 [NEW]: fsockopen will not work on 'localhost'
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.2.12
PHP Bug Type: Sockets related
Bug description: fsockopen will not work on 'localhost'
Description:
When are you going to provide a proper answer for post
http://bugs.php.net/bug.php?id=50953 ? I have removed the IPv6 entries in
my hosts file, but the problem is still there.
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit bug report at http://bugs.php.net/?id=50965&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50965&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50965&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50965&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50965&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50965&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50965&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50965&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50965&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50965&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50965&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50965&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50965&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50965&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50965&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50965&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50965&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50965&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50965&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50965&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50965&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50965&r=mysqlcfg
#50965 [Bgs]: fsockopen will not work on 'localhost'
ID: 50965
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
That is because he closed the bug without waiting to see if his
suggestion about removing the IV6 entries from the hosts file actually
worked.
He he hasn't provided a solution then the bug is not closed.
Previous Comments:
[2010-02-08 11:18:19] ahar...@php.net
Correction: bug #50953 isn't open. That still doesn't merit opening a
new one, IMO.
[2010-02-08 11:16:33] ahar...@php.net
Please don't open duplicate bugs in an attempt to "bump" existing open
bugs. It's been less than 19 hours since your last post in bug #50953;
I'm quite sure Pierre will respond when he's able.
Closing.
----
[2010-02-08 11:06:37] tony at marston-home dot demon dot co dot uk
Description:
When are you going to provide a proper answer for post
http://bugs.php.net/bug.php?id=50953 ? I have removed the IPv6 entries
in my hosts file, but the problem is still there.
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit this bug report at http://bugs.php.net/?id=50965&edit=1
#50965 [Bgs]: fsockopen will not work on 'localhost'
ID: 50965
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
I did respond in the original bug, but you closed it before finding out
if your suggestion about removing the IPV6 entries from my hosts file
actually worked. I put in a reply saying that it hadn't worked, but you
never re-opened the bug. I assumed that as you had closed it that you
were refusing to answer any more queries about it.
Previous Comments:
[2010-02-08 11:40:47] ahar...@php.net
OK, bug #50953 has been reopened. In future, please post in the
original bug.
[2010-02-08 11:35:00] tony at marston-home dot demon dot co dot uk
That is because he closed the bug without waiting to see if his
suggestion about removing the IV6 entries from the hosts file actually
worked.
He he hasn't provided a solution then the bug is not closed.
[2010-02-08 11:18:19] ahar...@php.net
Correction: bug #50953 isn't open. That still doesn't merit opening a
new one, IMO.
[2010-02-08 11:16:33] ahar...@php.net
Please don't open duplicate bugs in an attempt to "bump" existing open
bugs. It's been less than 19 hours since your last post in bug #50953;
I'm quite sure Pierre will respond when he's able.
Closing.
----
[2010-02-08 11:06:37] tony at marston-home dot demon dot co dot uk
Description:
When are you going to provide a proper answer for post
http://bugs.php.net/bug.php?id=50953 ? I have removed the IPv6 entries
in my hosts file, but the problem is still there.
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit this bug report at http://bugs.php.net/?id=50965&edit=1
#50965 [Bgs]: fsockopen will not work on 'localhost'
ID: 50965 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Bogus Bug Type: Sockets related Operating System: Windows XP PHP Version: 5.2.12 New Comment: I have checked my hosts file, and it only contains the following entry for 'localhost': 127.0.0.1 localhost I have rebooted my PC to clear any cache, but the error is still there. The name 'localhost' works in all the browsers that I use - IE, Firefox, Opera and Safari - so it should work with fsockopen. It works with names I use for other PCs in my home network. I have another PC running Windows XP with IPV6 enabled and PHP 5.3.0, and fsockopen doesn't have a problem using 'localhost' there. Previous Comments: [2010-02-08 17:07:40] ras...@php.net If 127.0.0.1 works and your name lookup system correctly returns 127.0.0.1 for localhost, then localhost has to work. If it isn't working it is because the lookup isn't returning the correct ipv4 ip. You may have removed it from your hosts file, but perhaps the old answer is cached somewhere. Try restarting things after changing your hosts file. ---- [2010-02-08 11:57:49] tony at marston-home dot demon dot co dot uk I did respond in the original bug, but you closed it before finding out if your suggestion about removing the IPV6 entries from my hosts file actually worked. I put in a reply saying that it hadn't worked, but you never re-opened the bug. I assumed that as you had closed it that you were refusing to answer any more queries about it. [2010-02-08 11:40:47] ahar...@php.net OK, bug #50953 has been reopened. In future, please post in the original bug. ---- [2010-02-08 11:35:00] tony at marston-home dot demon dot co dot uk That is because he closed the bug without waiting to see if his suggestion about removing the IV6 entries from the hosts file actually worked. He he hasn't provided a solution then the bug is not closed. [2010-02-08 11:18:19] ahar...@php.net Correction: bug #50953 isn't open. That still doesn't merit opening a new one, IMO. 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/50965 -- Edit this bug report at http://bugs.php.net/?id=50965&edit=1
#50965 [Bgs]: fsockopen will not work on 'localhost'
ID: 50965
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
Previous Comments:
[2010-02-08 17:39:14] ras...@php.net
There is no special-case code in PHP for localhost.
Try: print_r(gethostbynamel('localhost'));
[2010-02-08 17:32:36] tony at marston-home dot demon dot co dot uk
I have checked my hosts file, and it only contains the following entry
for 'localhost':
127.0.0.1 localhost
I have rebooted my PC to clear any cache, but the error is still
there.
The name 'localhost' works in all the browsers that I use - IE,
Firefox, Opera and Safari - so it should work with fsockopen. It works
with names I use for other PCs in my home network.
I have another PC running Windows XP with IPV6 enabled and PHP 5.3.0,
and fsockopen doesn't have a problem using 'localhost' there.
[2010-02-08 17:07:40] ras...@php.net
If 127.0.0.1 works and your name lookup system correctly returns
127.0.0.1 for localhost, then localhost has to work. If it isn't
working it is because the lookup isn't returning the correct ipv4 ip.
You may have removed it from your hosts file, but perhaps the old
answer is cached somewhere. Try restarting things after changing your
hosts file.
[2010-02-08 11:57:49] tony at marston-home dot demon dot co dot uk
I did respond in the original bug, but you closed it before finding out
if your suggestion about removing the IPV6 entries from my hosts file
actually worked. I put in a reply saying that it hadn't worked, but you
never re-opened the bug. I assumed that as you had closed it that you
were refusing to answer any more queries about it.
[2010-02-08 11:40:47] ahar...@php.net
OK, bug #50953 has been reopened. In future, please post in the
original bug.
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/50965
--
Edit this bug report at http://bugs.php.net/?id=50965&edit=1
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
Previous Comments:
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
[2010-02-10 08:17:49] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?
Yes.
> Comment out the IPv6 entries for localhost
Of course not! (PHP is not the center of the universe and i need a
working IPv6)
> (see the other bogus reports for detailed explanations
Don't you think it's better to fix the bug in the streams code?
(Already explained in an other bug report about mysqlnd)
BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4
in the HOSTS file (or just deinstall IPv6)
- and that's not working for e.g. Windows 7.
Regards,
Carsten
[2010-02-08 11:39:51] ahar...@php.net
Reopening per discussion in bug #50965.
----
[2010-02-07 17:27:30] tony at marston-home dot demon dot co dot uk
I have tried that, but it still doesn't work.
[2010-02-07 17:15:21] paj...@php.net
Comment out the IPv6 entries for localhost (see the other bogus reports
for detailed explanations).
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/50953
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
This has got nothing to do with IPV6 addresses as my hosts file does
not contain anf IPV6 addresses. All it has is as follows:
127.0.0.1 localhost
Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.
I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2
Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.
If gethostbyname() can work with 'localhost' then why can't
fsockopen()?
Previous Comments:
[2010-02-10 11:06:08] paj...@php.net
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
----
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
[2010-02-10 08:17:49] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?
Yes.
> Comment out the IPv6 entries for localhost
Of course not! (PHP is not the center of the universe and i need a
working IPv6)
> (see the other bogus reports for detailed explanations
Don't you think it's better to fix the bug in the streams code?
(Already explained in an other bug report about mysqlnd)
BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4
in the HOSTS file (or just deinstall IPv6)
- and that's not working for e.g. Windows 7.
Regards,
Carsten
[2010-02-08 11:39:51] ahar...@php.net
Reopening per discussion in bug #50965.
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/50953
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
Previous Comments:
[2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk
This has got nothing to do with IPV6 addresses as my hosts file does
not contain anf IPV6 addresses. All it has is as follows:
127.0.0.1 localhost
Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.
I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2
Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.
If gethostbyname() can work with 'localhost' then why can't
fsockopen()?
[2010-02-10 11:06:08] paj...@php.net
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
[2010-02-10 08:17:49] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?
Yes.
> Comment out the IPv6 entries for localhost
Of course not! (PHP is not the center of the universe and i need a
working IPv6)
> (see the other bogus reports for detailed explanations
Don't you think it's better to fix the bug in the streams code?
(Already explained in an other bug report about mysqlnd)
BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4
in the HOSTS file (or just deinstall IPv6)
- and that's not working for e.g. Windows 7.
Regards,
Carsten
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/50953
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#51079 [NEW]: fsockopen will not work on 'localhost'
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version: 5.2.12
PHP Bug Type: Sockets related
Bug description: fsockopen will not work on 'localhost'
Description:
When are you going to provide a satisfactory answer to bugs
http://bugs.php.net/bug.php?id=50953 and
http://bugs.php.net/bug.php?id=50965? Your only suggestion has been to
disable IPv^ support in the operating system, but this is a total red
herring.
If IPv6 support is enabled in the operating system it does NOT mean that
only IPv6 addresses are allowed, it means that both IPv5 and IPv6 addresses
are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit bug report at http://bugs.php.net/?id=51079&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51079&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51079&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51079&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51079&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51079&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51079&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51079&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51079&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51079&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51079&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51079&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51079&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51079&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51079&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51079&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51079&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51079&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51079&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51079&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51079&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51079&r=mysqlcfg
#51079 [Bgs]: fsockopen will not work on 'localhost'
ID: 51079
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say "disable IPv6 support in your
operating system" as the problem CLEARLY lies within the code for
fsockopen.
If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
Previous Comments:
[2010-02-18 11:04:43] j...@php.net
-Status: Open
+Status: Bogus
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.
----
[2010-02-18 10:31:19] tony at marston-home dot demon dot co dot uk
Description:
When are you going to provide a satisfactory answer to bugs
http://bugs.php.net/bug.php?id=50953 and
http://bugs.php.net/bug.php?id=50965? Your only suggestion has been to
disable IPv^ support in the operating system, but this is a total red
herring.
If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');
Expected result:
I expect to see the message "Connected to OK" for all values of
host.
Actual result:
--
Warning: fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK
--
Edit this bug report at http://bugs.php.net/?id=51079&edit=1
#51079 [Bgs]: fsockopen will not work on 'localhost'
ID: 51079
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested "fix" was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.
This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.
None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1
gethostbyname('localhost') returns '127.0.0.1' without any problem.
The CURL extension can send requests to 'localhost' without a problem.
I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.
So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?
Do NOT tell me that this is a Windows XP issue and that I should
disable IPv6 support. IPv4 and IPv6 are designed to run alongside each
other and are NOT mutually exclusive. The only function on my PC that
has a problem with that is fsockopen(), so stop procrastinating and FIX
IT!
Previous Comments:
[2010-02-18 17:44:10] ras...@php.net
You are going to have to debug it yourself. Nobody has been able to
reproduce your problem and you are the only one who has reported it.
We can't fix something we can't see.
----
[2010-02-18 11:20:44] tony at marston-home dot demon dot co dot uk
The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say "disable IPv6 support in your
operating system" as the problem CLEARLY lies within the code for
fsockopen.
If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
[2010-02-18 11:04:43] j...@php.net
-Status: Open
+Status: Bogus
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.
[2010-02-18 10:31:19] tony at marston-home dot demon dot co dot uk
Description:
When are you going to provide a satisfactory answer to bugs
http://bugs.php.net/bug.php?id=50953 and
http://bugs.php.net/bug.php?id=50965? Your only suggestion has been to
disable IPv^ support in the operating system, but this is a total red
herring.
If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
Reproduce code:
---
function connect($host) {
$faultcode = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function
$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.to
#51079 [Fbk->Opn]: fsockopen will not work on 'localhost'
ID: 51079
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
I have tried 5.2.13RC2, but it produces the same error. I have not
tried 5.3.2RC2 as I do not have an error with 5.3.0 (which may be
because my copy of 5.3.0 does not have IPv6 support enabled).
Previous Comments:
[2010-02-19 12:51:20] paj...@php.net
-Status: Bogus
+Status: Feedback
Have you tried with 5.2.13RC2 and 5.3.2RC2?
[2010-02-19 10:58:02] tony at marston-home dot demon dot co dot uk
Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested "fix" was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.
This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.
None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1
gethostbyname('localhost') returns '127.0.0.1' without any problem.
The CURL extension can send requests to 'localhost' without a problem.
I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.
So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?
Do NOT tell me that this is a Windows XP issue and that I should
disable IPv6 support. IPv4 and IPv6 are designed to run alongside each
other and are NOT mutually exclusive. The only function on my PC that
has a problem with that is fsockopen(), so stop procrastinating and FIX
IT!
[2010-02-18 17:44:10] ras...@php.net
You are going to have to debug it yourself. Nobody has been able to
reproduce your problem and you are the only one who has reported it.
We can't fix something we can't see.
----
[2010-02-18 11:20:44] tony at marston-home dot demon dot co dot uk
The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say "disable IPv6 support in your
operating system" as the problem CLEARLY lies within the code for
fsockopen.
If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
[2010-02-18 11:04:43] j...@php.net
-Status: Open
+Status: Bogus
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.
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/51079
--
Edit this bug report at http://bugs.php.net/?id=51079&edit=1
#51140 [NEW]: No php5apache2_2.dll provided in zip download
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 5.3.2RC3 PHP Bug Type: Apache2 related Bug description: No php5apache2_2.dll provided in zip download Description: I am trying to install the non thread safe version of PHP (to run as an apache module with Apache 2.2) as Zend only supply the nts version of their debugger as of version 5.3. When I unzip the download file I notice that it does not include a version of the php5apache2_2.dll. If I try to use the ts version it rejects all the PHP extensions as they were compiled with the nts option. -- Edit bug report at http://bugs.php.net/?id=51140&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51140&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51140&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51140&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51140&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51140&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51140&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51140&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51140&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51140&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51140&r=support Expected behavior: http://bugs.php.net/fix.php?id=51140&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51140&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51140&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51140&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51140&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51140&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51140&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51140&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51140&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51140&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51140&r=mysqlcfg
#51140 [Bgs]: No php5apache2_2.dll provided in zip download
ID: 51140 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.3.2RC3 New Comment: So why do the installation instructions in the nts zip file still say that it can be used with apache? Previous Comments: [2010-02-25 10:26:50] paj...@php.net Apache requires the thread safe version of PHP. [2010-02-25 10:20:35] tony at marston-home dot demon dot co dot uk Description: I am trying to install the non thread safe version of PHP (to run as an apache module with Apache 2.2) as Zend only supply the nts version of their debugger as of version 5.3. When I unzip the download file I notice that it does not include a version of the php5apache2_2.dll. If I try to use the ts version it rejects all the PHP extensions as they were compiled with the nts option. -- Edit this bug report at http://bugs.php.net/?id=51140&edit=1
