#26791 [Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Sniper: Don't be so dismissive. Most ini_set()'s work just fine regardless of when they're called. Sessions aren't a good example because all of the session stuff has to be processed before any output. If the team doesn't want to spend time fixing this, please turn this into a documentation bug for ref.mssql.php, where a note should be made about the need to set these before connecting to a db. Previous Comments: [2004-01-08 23:21:09] [EMAIL PROTECTED] Of course the ini_set() has to be called before anything else is what might be using the setting. (this is the case for ANY setting, not just these mssql.* settings, see e.g. session stuff for examples) [2004-01-08 13:51:48] danielc at analysisandsolutions dot com Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? 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/26791 -- Edit this bug report at http://bugs.php.net/?id=26791&edit=1
#26791 [Opn->Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 Updated by: [EMAIL PROTECTED] Reported By: danielc at analysisandsolutions dot com -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Of course the ini_set() has to be called before anything else is what might be using the setting. (this is the case for ANY setting, not just these mssql.* settings, see e.g. session stuff for examples) Previous Comments: [2004-01-08 13:51:48] danielc at analysisandsolutions dot com Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? [2004-01-05 01:34:58] danielc at analysisandsolutions dot com Description: The mssql.textlimit and mssql.textsize configuration options can't be set via ini_set(). Changing them in php.ini works. This is also the case in a recent PHP 5 snapshot (500rc1-dev--php5-win32-200401022330). This is the same issue as bug 20797 which was closed due to no feedback. SCRIPT CAN CHANGE LIMIT === php.ini mssql.textlimit = 2147483647 mssql.textsize = 2147483647 script SET TEXTSIZE 20 SCRIPT CAN'T CHANGE LIMIT = php.ini mssql.textlimit = 20 mssql.textsize = 20 script ini_set('mssql.textlimit', 2147483647); ini_set('mssql.textsize', 2147483647); php.ini mssql.textlimit = 2147483647 mssql.textsize = 2147483647 script ini_set('mssql.textlimit', 20); ini_set('mssql.textsize', 20); php.ini ; mssql.textlimit = 2147483647 ; mssql.textsize = 2147483647 script SET TEXTSIZE 2147483647 php.ini mssql.textlimit = 20 mssql.textsize = 20 script SET TEXTSIZE 2147483647 -- Edit this bug report at http://bugs.php.net/?id=26791&edit=1
#25803 [Opn->Csd]: xml_get_current_byte_index() always returns 0 on PHP 5.x
ID: 25803 Updated by: [EMAIL PROTECTED] Reported By: j dot spit at uptime dot nl -Status: Open +Status: Closed Bug Type: XML related Operating System: * PHP Version: 5CVS-2003-10-10 Assigned To: moriyoshi New Comment: current behaviour is the correct one as Moriyoshi said in his closing comment.. Previous Comments: [2004-01-08 11:25:00] j dot spit at uptime dot nl Hello, I am trying to find out what the current behaviour of xml_get_current_byte_index() is in PHP5 version beta3 and above. Is this documented somewhere ? I am developing software that is highly dependant on this function. Thanks ! [2003-11-26 16:07:41] j dot spit at uptime dot nl Hi, I noticed that in the latest CVS version it does not return zero anymore, which is good, but on the other hand it does return different values compared to php5.0.0b1. Can you enlighten me as to what value it currently returns ? Thanks. [2003-11-24 01:10:02] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Behaviour of xml_get_current_byte_index() is subject to change in php 5.0. It would probably return the end position of the portion that has just been parsed, by contrast to the old behaviour in 4.x, where it returns the start position of the portion being parsed. [2003-10-09 09:11:55] j dot spit at uptime dot nl Description: xml_get_current_byte_index always returns 0 on windows xp, it works fine on Linux systems. Using PHP5 beta 1 on both platforms. Reproduce code: --- "; } function endElement($parser,$name) { echo "End : ".xml_get_current_byte_index( $parser ).""; } $parser = xml_parser_create(); xml_set_element_handler($parser,'startElement','endElement'); xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,0); xml_parse($parser, "testblaat"); xml_parser_free($parser); ?> Expected result: Start : 0 Start : 13 End : 21 End : 25 This is the output on a Linux system. Actual result: -- Start : 0 Start : 0 End : 0 End : 0 This is the output on a Windows XP system. -- Edit this bug report at http://bugs.php.net/?id=25803&edit=1
#26835 [Fbk->Csd]: wrong data type returned by mssql_fetch_array
ID: 26835 User updated by: skissane at ics dot mq dot edu dot au Reported By: skissane at ics dot mq dot edu dot au -Status: Feedback +Status: Closed Bug Type: MSSQL related Operating System: Solaris 2.6 PHP Version: 4.3.4 New Comment: Upon closer investigation, the problem was not with Solaris at all, it was that the Solaris box was using the mssql_* functions with PHP configured with --with-sybase=, and the Linux box was using the mssql_* functions with --with-mssql=. Recompiling PHP on the Solaris box using --with-mssql solved the problem. This probably relates to the bugs with the sybase extension which have been reported in other bug reports. Sorry about wasting your time. (I would mark this bug as Bogus, not Closed, but it won't let me do that.) Previous Comments: [2004-01-08 01:07:35] [EMAIL PROTECTED] This seams to be a problem on Solaris or FreeTDS. I've tested the code on Linux and Win32 and can't reproduce the problem. The code is designed to return NULL if the db-api returns zero length data. For some reson NULL bust be translated into a non zero length value on Solaris. [2004-01-07 22:17:35] skissane at ics dot mq dot edu dot au Description: The following script returns an empty string on Solaris, when it should return a NULL (which it does, correctly, on Linux.) This is using FreeTDS 0.61.2 (same problem occurs with FreeTDS 0.52). This is talking to a SQL Server 2000 using TDS version 7.0 (switching to 8.0 made no difference). I've checked, and: mssql.compatability_mode = Off in php.ini. Reproduce code: --- ","",""); $q = mssql_query("SELECT NULL",$id); $f = mssql_fetch_array($q); echo gettype($f[0]); Expected result: NULL Actual result: -- string -- Edit this bug report at http://bugs.php.net/?id=26835&edit=1
#26797 [Opn]: 64 bit pointer again
ID: 26797 Updated by: [EMAIL PROTECTED] Reported By: yu at fstrf dot org Status: Open Bug Type: Compile Warning Operating System: solaris 8/sparcv9 PHP Version: 4.3.4 New Comment: SAPI.c warning has been fixed, thanks. Previous Comments: [2004-01-05 13:13:06] yu at fstrf dot org Description: I met more compiling warnings during the PHP compilation under solaris 8 /sparcv9 64-bit environment besides bug#26769. 1. ingres_ii warning messages: = php-4.3.4/ext/ingres_ii/ii.c: In function `php_ii_do_connect': php-4.3.4/ext/ingres_ii/ii.c:602: warning: cast from pointer to integer of different size php-4.3.4/ext/ingres_ii/ii.c:604: warning: cast from pointer to integer of different size php-4.3.4/ext/ingres_ii/ii.c:605: warning: cast from pointer to integer of different size php-4.3.4/ext/ingres_ii/ii.c:607: warning: cast from pointer to integer of different size code: = line# 601: link = (II_LINK *) index_ptr->ptr; line# 602: ptr = zend_list_find((int) link, &type);/* check if the link is still there */ line# 603: if (ptr && (type == le_ii_link || type == le_ii_plink)) { line# 604: zend_list_addref((int) link); line# 605: Z_LVAL_P(return_value) = (int) link; line# 606: line# 607: php_ii_set_default_link((int) link TSRMLS_CC); line# 608: line# 609: Z_TYPE_P(return_value) = IS_RESOURCE; line# 610:efree(hashed_details); line# 611:return; line# 612: } else { line# 613: zend_hash_del(&EG(regular_list), hashed_details, hashed_details_length + 1); line# 614: } 2. SAPI warning messages: = php-4.3.4/main/SAPI.c: In function `sapi_header_op': php-4.3.4/main/SAPI.c:510: warning: cast from pointer to integer of different size code: = line# 509: case SAPI_HEADER_SET_STATUS: line# 510: sapi_update_response_code((int) arg TSRMLS_CC); line# 511: return SUCCESS; In the 64-bit environment, pointers are defined in 64-bit. Would these assignments of 64-bit pointers to a 32-bit integer cause any memory problems? Thanks in advance for looking into these. Maggie -- Edit this bug report at http://bugs.php.net/?id=26797&edit=1
#26839 [Ver->Csd]: unexpected results from simple array routine
ID: 26839 Updated by: [EMAIL PROTECTED] Reported By: dweller at devonweller dot com -Status: Verified +Status: Closed Bug Type: Arrays related Operating System: Linux Intel (Redhat) PHP Version: 4CVS-2004-01-08 (dev) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This is fixed in PHP 5.0. This will not be fixed in PHP 4 as that would require an API change. The bug is the result of a refcount being defined as a short. Previous Comments: [2004-01-08 14:29:09] [EMAIL PROTECTED] Without the print_r() call no crash but this: --- /usr/src/web/php/php4/Zend/zend_execute.h(44) : Block 0x0864E478 status: Beginning: Overrun (magic=0x40847B54, expected=0x7312F8DC) End: Unknown --- [2004-01-08 14:28:14] [EMAIL PROTECTED] Works fine with PHP 5, crashes for me with PHP 4 (latest CVS): #0 0x407884ec in mempcpy () from /lib/i686/libc.so.6 #1 0x4077a850 in _IO_new_file_xsputn () from /lib/i686/libc.so.6 #2 0x4076ff9f in fwrite () from /lib/i686/libc.so.6 #3 0x082b0f75 in sapi_cli_single_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:190 #4 0x082afb2e in sapi_cli_ub_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:203 #5 0x082699fd in php_ub_body_write_no_header (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/output.c:689 #6 0x0826863a in php_body_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/output.c:121 #7 0x08254dc0 in php_body_write_wrapper (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/main.c:1022 #8 0x0828c2d8 in zend_print_zval_ex (write_func=0x8254d9f , expr=0xbfffd330, indent=0) at /usr/src/web/php/php4/Zend/zend.c:211 #9 0x0828c256 in zend_print_zval (expr=0x864e2cc, indent=0) at /usr/src/web/php/php4/Zend/zend.c:192 #10 0x0828bd0f in zend_print_variable (var=0x864e2cc) at /usr/src/web/php/php4/Zend/zend_variables.c:147 #11 0x0828c45a in zend_print_zval_r_ex (write_func=0x8254d9f , expr=0x864e2cc, indent=8) at /usr/src/web/php/php4/Zend/zend.c:253 #12 0x0828c335 in zend_print_zval_r (expr=0x864e2cc, indent=8) at /usr/src/web/php/php4/Zend/zend.c:221 #13 0x0828bf6f in print_hash (ht=0x865337c, indent=4) at /usr/src/web/php/php4/Zend/zend.c:130 #14 0x0828c3c8 in zend_print_zval_r_ex (write_func=0x8254d9f , expr=0x86534e4, indent=0) at /usr/src/web/php/php4/Zend/zend.c:235 #15 0x0828c335 in zend_print_zval_r (expr=0x86534e4, indent=0) at /usr/src/web/php/php4/Zend/zend.c:221 #16 0x081e082d in zif_print_r (ht=1, return_value=0x962c23c, this_ptr=0x0, return_value_used=0) at /usr/src/web/php/php4/ext/standard/basic_functions.c:2488 #17 0x0829ed0e in execute (op_array=0x864e9f4) at /usr/src/web/php/php4/Zend/zend_execute.c:1616 #18 0x0828d76a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php/php4/Zend/zend.c:884 #19 0x08256573 in php_execute_script (primary_file=0xbbc0) at /usr/src/web/php/php4/main/main.c:1727 #20 0x082b0da3 in main (argc=2, argv=0xbc54) at /usr/src/web/php/php4/sapi/cli/php_cli.c:820 [2004-01-08 10:04:42] [EMAIL PROTECTED] $i < 32768 results in array(2) { ["var1"]=> UNKNOWN:0 ["var2"]=> UNKNOWN:0 } $i < 32767 results in array(2) { ["var1"]=> int(1) ["var2"]=> int(1) } [2004-01-08 07:01:49] dweller at devonweller dot com Description: The attached simple array routine produces unexpected results when the loop count is greater than approx. 33000. Perhaps this is some kind of reference counting bug. Reproduce code: --- // causes unexpected *RECURSION* references $var1 = 1; $array = array(); for($i=0;$i<33000;++$i) { $var2 = $var1; $array[] = array( 'var1' => $var1, 'var2' => $var2, ); } print_r($array[0]); Expected result: Array ( [var1] => 1 [var2] => 1 ) Actual result: -- Array ( [var1] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) [var2] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) ) -- Edit this bug report at http://bugs.php.net/?id=26839&edit=1
#26846 [Opn->Fbk]: fpassthru() segfaults on certain files
ID: 26846 Updated by: [EMAIL PROTECTED] Reported By: djones at xtreme-eda dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE PHP Version: 4.3.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot verify crash with latest CVS. Previous Comments: [2004-01-08 16:09:36] djones at xtreme-eda dot com Backtrace and autopsy: Program received signal SIGSEGV, Segmentation fault. 0x282d0261 in memcpy () from /usr/lib/libc.so.4 (gdb) bt #0 0x282d0261 in memcpy () from /usr/lib/libc.so.4 #1 0x41001 in ?? () #2 0x284705d0 in php_apache_sapi_ub_write (str=0x285f5000 "ÐÏ\021ࡱ\032á", str_length=266240) at /usr/ports/lang/php4/work/php-4.3.4/sapi/ apache2handler/sapi_apache2.c:84 #3 0x28438404 in php_ub_body_write_no_header (str=0x285f5000 "ÐÏ\021ࡱ\032á", str_length=266240) at /usr/ports/lang/php4/work/ php-4.3.4/main/output.c:689 #4 0x284384c3 in php_ub_body_write (str=0x285f5000 "ÐÏ \021ࡱ\032á", str_length=266240) at /usr/ports/lang/php4/work/ php-4.3.4/main/output.c:719 #5 0x284372b6 in php_body_write (str=0x285f5000 "ÐÏ\021à¡ ±\032á", str_length=266240) at /usr/ports/lang/php4/work/ php-4.3.4/main/output.c:121 #6 0x28432ecc in _php_stream_passthru (stream=0x818a624, __php_stream_call_depth=0, __zend_filename=0x2847c180 "/usr/ports/lang/php4/work/ php-4.3.4/ext/standard/file.c", __zend_lineno=1867, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php4/work/php-4.3.4/main/ streams.c:1088 #7 0x283d752f in zif_fpassthru (ht=1, return_value=0x81a2ca4, this_ptr=0x0, return_value_used=0) at /usr/ports/lang/php4/work/php-4.3.4/ext/standard/ file.c:1867 #8 0x28469298 in execute (op_array=0x81a3d24) at /usr/ports/lang/php4/work/php-4.3.4/Zend/ zend_execute.c:1618 #9 0x284550b2 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/lang/php4/work/php-4.3.4/Zend/zend.c:884 #10 0x28428ce9 in php_execute_script (primary_file=0xbfbff648) at /usr/ports/lang/php4/work/php-4.3.4/main/ main.c:1729 #11 0x2847119a in php_handler (r=0x8197050) at /usr/ports/lang/php4/work/php-4.3.4/sapi/ apache2handler/sapi_apache2.c:537 #12 0x806379c in ap_run_handler () #13 0x8063cc9 in ap_invoke_handler () #14 0x8060fca in ap_process_request () #15 0x805cd66 in ap_process_http_connection () #16 0x806bc78 in ap_run_process_connection () #17 0x806bf0c in ap_process_connection () #18 0x8062443 in child_main () #19 0x8062500 in make_child () #20 0x80625f2 in startup_children () #21 0x8062927 in ap_mpm_run () #22 0x8067e36 in main () #23 0x805c99e in _start () (gdb) f 6 #6 0x28432ecc in _php_stream_passthru (stream=0x80d9924, __php_stream_call_depth=0, __zend_filename=0x2847c180 "/usr/ports/lang/php4/work/ php-4.3.4/ext/standard/file.c", __zend_lineno=1867, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php4/work/php-4.3.4/main/ streams.c:1088 1088PHPWRITE(p, len); (gdb) p p $1 = (void *) 0x285cd000 (gdb) p len $2 = 266240 (gdb) p fd $3 = 15 (gdb) p off $4 = 4430856216 (gdb) p/x off $5 = 0x108198018 (gdb) p *stream $8 = {ops = 0x284a9a00, abstract = 0x8190a64, filterhead = 0x0, filtertail = 0x0, wrapper = 0x284a9a9c, wrapperthis = 0x0, wrapperdata = 0x0, fgetss_state = 0, is_persistent = 0, mode = "rb", '\000' , rsrc_id = 2, in_free = 0, fclose_stdiocast = 0, stdiocast = 0x0, __exposed = 1, __orig_path = 0x8191b24 "/usr/local/www/data/ RECORD_OF_DECISIONS_TEMPLATE_20030812.24.doc", context = 0x0, flags = 0, position = 0, readbuf = 0x0, readbuflen = 0, readpos = 0, writepos = 0, chunk_size = 8192, eof = 0} (gdb) p *$8.ops $9 = {write = 0x2843385c , read = 0x284338f4 , close = 0x284339cc , flush = 0x28433b00 , label = 0x2848ad45 "STDIO", seek = 0x28433b5c , cast = 0x28433c1c , stat = 0x28433d14 , set_option = 0x28433d78 } (gdb) p {php_stdio_stream_data}0x8190a64 $11 = {file = 0x0, fd = 15, is_process_pipe = 0, is_pipe = 0, temp_file_name = 0x0, last_op = 0 '\000'} "off" looks, well, a little off. :-) [2004-01-08 14:34:59] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. ---
#26838 [Opn->Bgs]: signals make STDIN become EOF
ID: 26838 Updated by: [EMAIL PROTECTED] Reported By: xuefer at 21cn dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: linux PHP Version: 4.3.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php signals can and will interrupt readings from files & sockets. Previous Comments: [2004-01-08 05:50:30] xuefer at 21cn dot com Description: code shell> ./test.php don't press CTRL+D to end input. but program exists in 3 seconds because feof() return true uncomment line 7 will works ok, exit only when i press CTRL+D Reproduce code: --- file ./test.php: #!/usr/bin/php -- Edit this bug report at http://bugs.php.net/?id=26838&edit=1
#26847 [Opn->Csd]: memory leak with to_r and subject_r in mail() function
ID: 26847 Updated by: [EMAIL PROTECTED] Reported By: nutbar at innocent dot com -Status: Open +Status: Closed Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. The bug was real, you were right. The reason you did not see the leak is because Zend's memory manager automatically handles such leaks. If you were to compile a debug build of PHP you'd see some leak messages printed. Previous Comments: [2004-01-08 17:14:34] nutbar at innocent dot com Ok, maybe I am wrong? I wrote a PHP script which *should* leak memory if this is indeed not efree()'ing stuff, but it doesn't seem to. I noticed it would only potentially (if I was right!) leak ram if say, the subject was entirely space characters, so I made a script that called mail() 1000 times roughly, and made a subject that was all spaces that was 1k long - it should have set me off by 1mb, but instead I see nothing of the sort. I'm running the script from the command line (CGI, not CLI though!) if it makes any difference (I don't believe it does). Either way, I can't seem to leak the ram, so I guess I was wrong - but can someone explain to me why it wouldn't? What am I missing here that wouldn't allow it to leak ram? [2004-01-08 16:17:25] nutbar at innocent dot com Here, maybe this will help a bit... Here it assigns values to to_len and subject_len (among others): if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sss|ss", &to, &to_len, &subject, &subject_len, &message, &message_len, &headers, &headers_len, &extra_cmd, &extra_cmd_len ) == FAILURE) { return; } Then, they check to_len and do stuff if it's greater than 0: if (to_len > 0) { to_r = estrndup(to, to_len); for (; to_len; to_len--) { if (!isspace((unsigned char) to_r[to_len - 1])) { break; } to_r[to_len - 1] = '\0'; } ... Do you see the for loop in there... this one: for (; to_len; to_len--) {...} It is modifying to_len itself, which means that to_len, although was NOT 0 to begin with (and thus, to_r was estrndup()'d and we have to efree() it later), but IS 0 in the end once the for loop is finished. Either the for loop must be changed to not modify to_len, or the efree() statement must be changed to test to_r, not to_len. Or am I just really out of my mind? I'm not anywhere near as good as you programmers, but this seems to be sticking out for me quite a bit (I'm not trying to come off rude! I just think I found something here and it's not bogus). [2004-01-08 16:07:29] nutbar at innocent dot com I know they check to_len and subject_len - that's not really the problem. The problem is that the for loops above that decrement to_len and subject_len - thus modifying them from their original values. to_len and subject_len will always be 0, even if they weren't 0 to begin with. Do you see what I'm referring to? [2004-01-08 15:38:41] [EMAIL PROTECTED] Impossible leak. if (to_len > 0) { efree(to_r); } if (subject_len > 0) { efree(subject_r); } Is what the code in CVS does. If to_len or subject_len are < 1 then no allocation happens in the 1st place. [2004-01-08 15:34:23] nutbar at innocent dot com I guess an alternate fix would also be when the efree()'s are called. If you init all your char *'s to NULL, then you can simply do: if (to_r != NULL) { efree(to_r); } if (subject_r != NULL) { efree(subject_r); } 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/26847 -- Edit this bug report at http://bugs.php.net/?id=26847&edit=1
#26847 [Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847 User updated by: nutbar at innocent dot com Reported By: nutbar at innocent dot com Status: Open Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: Ok, maybe I am wrong? I wrote a PHP script which *should* leak memory if this is indeed not efree()'ing stuff, but it doesn't seem to. I noticed it would only potentially (if I was right!) leak ram if say, the subject was entirely space characters, so I made a script that called mail() 1000 times roughly, and made a subject that was all spaces that was 1k long - it should have set me off by 1mb, but instead I see nothing of the sort. I'm running the script from the command line (CGI, not CLI though!) if it makes any difference (I don't believe it does). Either way, I can't seem to leak the ram, so I guess I was wrong - but can someone explain to me why it wouldn't? What am I missing here that wouldn't allow it to leak ram? Previous Comments: [2004-01-08 16:17:25] nutbar at innocent dot com Here, maybe this will help a bit... Here it assigns values to to_len and subject_len (among others): if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sss|ss", &to, &to_len, &subject, &subject_len, &message, &message_len, &headers, &headers_len, &extra_cmd, &extra_cmd_len ) == FAILURE) { return; } Then, they check to_len and do stuff if it's greater than 0: if (to_len > 0) { to_r = estrndup(to, to_len); for (; to_len; to_len--) { if (!isspace((unsigned char) to_r[to_len - 1])) { break; } to_r[to_len - 1] = '\0'; } ... Do you see the for loop in there... this one: for (; to_len; to_len--) {...} It is modifying to_len itself, which means that to_len, although was NOT 0 to begin with (and thus, to_r was estrndup()'d and we have to efree() it later), but IS 0 in the end once the for loop is finished. Either the for loop must be changed to not modify to_len, or the efree() statement must be changed to test to_r, not to_len. Or am I just really out of my mind? I'm not anywhere near as good as you programmers, but this seems to be sticking out for me quite a bit (I'm not trying to come off rude! I just think I found something here and it's not bogus). [2004-01-08 16:07:29] nutbar at innocent dot com I know they check to_len and subject_len - that's not really the problem. The problem is that the for loops above that decrement to_len and subject_len - thus modifying them from their original values. to_len and subject_len will always be 0, even if they weren't 0 to begin with. Do you see what I'm referring to? [2004-01-08 15:38:41] [EMAIL PROTECTED] Impossible leak. if (to_len > 0) { efree(to_r); } if (subject_len > 0) { efree(subject_r); } Is what the code in CVS does. If to_len or subject_len are < 1 then no allocation happens in the 1st place. [2004-01-08 15:34:23] nutbar at innocent dot com I guess an alternate fix would also be when the efree()'s are called. If you init all your char *'s to NULL, then you can simply do: if (to_r != NULL) { efree(to_r); } if (subject_r != NULL) { efree(subject_r); } [2004-01-08 15:31:12] nutbar at innocent dot com By the way, very simple fix: Add this to the variable declarations: int j = 0; Then the lines of code as mentioned before, but fixed: if (to_len > 0) { to_r = estrndup(to, to_len); for (j = to_len; j > 0; j--) { if (!isspace((unsigned char) to_r[j - 1])) { break; } to_r[j - 1] = '\0'; } and: if (subject_len > 0) { subject_r = estrndup(subject, subject_len); for (j = subject_len; j > 0; j--) { if (!isspace((unsigned char) subject_r[j - 1])) { break; } subject_r[j - 1] = '\0'; }
#26849 [Opn]: domXPath object returns array instead of nodeList
ID: 26849 User updated by: adam at trachtenberg dot com Reported By: adam at trachtenberg dot com Status: Open Bug Type: DOM XML related Operating System: * PHP Version: 5CVS-2004-01-08 (dev) New Comment: That should be domXpath::query(), but you get the point. :) Previous Comments: [2004-01-08 16:18:28] adam at trachtenberg dot com Description: The domXPath object still returns nodes in an array instead of as a nodeList object. Reproduce code: --- $dom = new domDocument::load($xml); $xpath = new domXPath($dom); $results = $xpath->query('/'); var_dump($results); Expected result: object(domnodelist)#14 (0) { ... } Actual result: -- array(1) { ... } -- Edit this bug report at http://bugs.php.net/?id=26849&edit=1
#26849 [NEW]: domXPath object returns array instead of nodeList
From: adam at trachtenberg dot com Operating system: * PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: DOM XML related Bug description: domXPath object returns array instead of nodeList Description: The domXPath object still returns nodes in an array instead of as a nodeList object. Reproduce code: --- $dom = new domDocument::load($xml); $xpath = new domXPath($dom); $results = $xpath->query('/'); var_dump($results); Expected result: object(domnodelist)#14 (0) { ... } Actual result: -- array(1) { ... } -- Edit bug report at http://bugs.php.net/?id=26849&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26849&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26849&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26849&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26849&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26849&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26849&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26849&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26849&r=support Expected behavior: http://bugs.php.net/fix.php?id=26849&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26849&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26849&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26849&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26849&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26849&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26849&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26849&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26849&r=float
#26847 [Bgs->Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847 User updated by: nutbar at innocent dot com Reported By: nutbar at innocent dot com -Status: Bogus +Status: Open Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: Here, maybe this will help a bit... Here it assigns values to to_len and subject_len (among others): if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sss|ss", &to, &to_len, &subject, &subject_len, &message, &message_len, &headers, &headers_len, &extra_cmd, &extra_cmd_len ) == FAILURE) { return; } Then, they check to_len and do stuff if it's greater than 0: if (to_len > 0) { to_r = estrndup(to, to_len); for (; to_len; to_len--) { if (!isspace((unsigned char) to_r[to_len - 1])) { break; } to_r[to_len - 1] = '\0'; } ... Do you see the for loop in there... this one: for (; to_len; to_len--) {...} It is modifying to_len itself, which means that to_len, although was NOT 0 to begin with (and thus, to_r was estrndup()'d and we have to efree() it later), but IS 0 in the end once the for loop is finished. Either the for loop must be changed to not modify to_len, or the efree() statement must be changed to test to_r, not to_len. Or am I just really out of my mind? I'm not anywhere near as good as you programmers, but this seems to be sticking out for me quite a bit (I'm not trying to come off rude! I just think I found something here and it's not bogus). Previous Comments: [2004-01-08 16:07:29] nutbar at innocent dot com I know they check to_len and subject_len - that's not really the problem. The problem is that the for loops above that decrement to_len and subject_len - thus modifying them from their original values. to_len and subject_len will always be 0, even if they weren't 0 to begin with. Do you see what I'm referring to? [2004-01-08 15:38:41] [EMAIL PROTECTED] Impossible leak. if (to_len > 0) { efree(to_r); } if (subject_len > 0) { efree(subject_r); } Is what the code in CVS does. If to_len or subject_len are < 1 then no allocation happens in the 1st place. [2004-01-08 15:34:23] nutbar at innocent dot com I guess an alternate fix would also be when the efree()'s are called. If you init all your char *'s to NULL, then you can simply do: if (to_r != NULL) { efree(to_r); } if (subject_r != NULL) { efree(subject_r); } [2004-01-08 15:31:12] nutbar at innocent dot com By the way, very simple fix: Add this to the variable declarations: int j = 0; Then the lines of code as mentioned before, but fixed: if (to_len > 0) { to_r = estrndup(to, to_len); for (j = to_len; j > 0; j--) { if (!isspace((unsigned char) to_r[j - 1])) { break; } to_r[j - 1] = '\0'; } and: if (subject_len > 0) { subject_r = estrndup(subject, subject_len); for (j = subject_len; j > 0; j--) { if (!isspace((unsigned char) subject_r[j - 1])) { break; } subject_r[j - 1] = '\0'; } I just initialized j in the for loop to be the value of to_len and subject_len, then I use j everywhere rather than to_len or subject_len so that they stay unmodified. [2004-01-08 13:22:55] nutbar at innocent dot com Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the "to_len" count is greater than 0, it duplicates the "to" string to "to_r" and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it doe
#26846 [Fbk->Opn]: fpassthru() segfaults on certain files
ID: 26846 User updated by: djones at xtreme-eda dot com Reported By: djones at xtreme-eda dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE PHP Version: 4.3.4 New Comment: Backtrace and autopsy: Program received signal SIGSEGV, Segmentation fault. 0x282d0261 in memcpy () from /usr/lib/libc.so.4 (gdb) bt #0 0x282d0261 in memcpy () from /usr/lib/libc.so.4 #1 0x41001 in ?? () #2 0x284705d0 in php_apache_sapi_ub_write (str=0x285f5000 "ÐÏ\021ࡱ\032á", str_length=266240) at /usr/ports/lang/php4/work/php-4.3.4/sapi/ apache2handler/sapi_apache2.c:84 #3 0x28438404 in php_ub_body_write_no_header (str=0x285f5000 "ÐÏ\021ࡱ\032á", str_length=266240) at /usr/ports/lang/php4/work/ php-4.3.4/main/output.c:689 #4 0x284384c3 in php_ub_body_write (str=0x285f5000 "ÐÏ \021ࡱ\032á", str_length=266240) at /usr/ports/lang/php4/work/ php-4.3.4/main/output.c:719 #5 0x284372b6 in php_body_write (str=0x285f5000 "ÐÏ\021à¡ ±\032á", str_length=266240) at /usr/ports/lang/php4/work/ php-4.3.4/main/output.c:121 #6 0x28432ecc in _php_stream_passthru (stream=0x818a624, __php_stream_call_depth=0, __zend_filename=0x2847c180 "/usr/ports/lang/php4/work/ php-4.3.4/ext/standard/file.c", __zend_lineno=1867, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php4/work/php-4.3.4/main/ streams.c:1088 #7 0x283d752f in zif_fpassthru (ht=1, return_value=0x81a2ca4, this_ptr=0x0, return_value_used=0) at /usr/ports/lang/php4/work/php-4.3.4/ext/standard/ file.c:1867 #8 0x28469298 in execute (op_array=0x81a3d24) at /usr/ports/lang/php4/work/php-4.3.4/Zend/ zend_execute.c:1618 #9 0x284550b2 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/lang/php4/work/php-4.3.4/Zend/zend.c:884 #10 0x28428ce9 in php_execute_script (primary_file=0xbfbff648) at /usr/ports/lang/php4/work/php-4.3.4/main/ main.c:1729 #11 0x2847119a in php_handler (r=0x8197050) at /usr/ports/lang/php4/work/php-4.3.4/sapi/ apache2handler/sapi_apache2.c:537 #12 0x806379c in ap_run_handler () #13 0x8063cc9 in ap_invoke_handler () #14 0x8060fca in ap_process_request () #15 0x805cd66 in ap_process_http_connection () #16 0x806bc78 in ap_run_process_connection () #17 0x806bf0c in ap_process_connection () #18 0x8062443 in child_main () #19 0x8062500 in make_child () #20 0x80625f2 in startup_children () #21 0x8062927 in ap_mpm_run () #22 0x8067e36 in main () #23 0x805c99e in _start () (gdb) f 6 #6 0x28432ecc in _php_stream_passthru (stream=0x80d9924, __php_stream_call_depth=0, __zend_filename=0x2847c180 "/usr/ports/lang/php4/work/ php-4.3.4/ext/standard/file.c", __zend_lineno=1867, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php4/work/php-4.3.4/main/ streams.c:1088 1088PHPWRITE(p, len); (gdb) p p $1 = (void *) 0x285cd000 (gdb) p len $2 = 266240 (gdb) p fd $3 = 15 (gdb) p off $4 = 4430856216 (gdb) p/x off $5 = 0x108198018 (gdb) p *stream $8 = {ops = 0x284a9a00, abstract = 0x8190a64, filterhead = 0x0, filtertail = 0x0, wrapper = 0x284a9a9c, wrapperthis = 0x0, wrapperdata = 0x0, fgetss_state = 0, is_persistent = 0, mode = "rb", '\000' , rsrc_id = 2, in_free = 0, fclose_stdiocast = 0, stdiocast = 0x0, __exposed = 1, __orig_path = 0x8191b24 "/usr/local/www/data/ RECORD_OF_DECISIONS_TEMPLATE_20030812.24.doc", context = 0x0, flags = 0, position = 0, readbuf = 0x0, readbuflen = 0, readpos = 0, writepos = 0, chunk_size = 8192, eof = 0} (gdb) p *$8.ops $9 = {write = 0x2843385c , read = 0x284338f4 , close = 0x284339cc , flush = 0x28433b00 , label = 0x2848ad45 "STDIO", seek = 0x28433b5c , cast = 0x28433c1c , stat = 0x28433d14 , set_option = 0x28433d78 } (gdb) p {php_stdio_stream_data}0x8190a64 $11 = {file = 0x0, fd = 15, is_process_pipe = 0, is_pipe = 0, temp_file_name = 0x0, last_op = 0 '\000'} "off" looks, well, a little off. :-) Previous Comments: [2004-01-08 14:34:59] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2004-01-08 13:16:54] djones at xtreme-eda dot com Description: PHP configuration: http://www.inode.org/test.php I am running an application that sends files to the user using fpassthru(). With certain files, Apache exits with signal 11. There does not seem to be
#26847 [Bgs]: memory leak with to_r and subject_r in mail() function
ID: 26847 User updated by: nutbar at innocent dot com Reported By: nutbar at innocent dot com Status: Bogus Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: I know they check to_len and subject_len - that's not really the problem. The problem is that the for loops above that decrement to_len and subject_len - thus modifying them from their original values. to_len and subject_len will always be 0, even if they weren't 0 to begin with. Do you see what I'm referring to? Previous Comments: [2004-01-08 15:38:41] [EMAIL PROTECTED] Impossible leak. if (to_len > 0) { efree(to_r); } if (subject_len > 0) { efree(subject_r); } Is what the code in CVS does. If to_len or subject_len are < 1 then no allocation happens in the 1st place. [2004-01-08 15:34:23] nutbar at innocent dot com I guess an alternate fix would also be when the efree()'s are called. If you init all your char *'s to NULL, then you can simply do: if (to_r != NULL) { efree(to_r); } if (subject_r != NULL) { efree(subject_r); } [2004-01-08 15:31:12] nutbar at innocent dot com By the way, very simple fix: Add this to the variable declarations: int j = 0; Then the lines of code as mentioned before, but fixed: if (to_len > 0) { to_r = estrndup(to, to_len); for (j = to_len; j > 0; j--) { if (!isspace((unsigned char) to_r[j - 1])) { break; } to_r[j - 1] = '\0'; } and: if (subject_len > 0) { subject_r = estrndup(subject, subject_len); for (j = subject_len; j > 0; j--) { if (!isspace((unsigned char) subject_r[j - 1])) { break; } subject_r[j - 1] = '\0'; } I just initialized j in the for loop to be the value of to_len and subject_len, then I use j everywhere rather than to_len or subject_len so that they stay unmodified. [2004-01-08 13:22:55] nutbar at innocent dot com Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the "to_len" count is greater than 0, it duplicates the "to" string to "to_r" and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it does an if () test to see if it should or not - the if test compares to_len and subject_len to see if they are greater than 0 and if so, efree()'s them. The problem is that in the code that does stuff with to_r and subject_r, there are for loops which decrement to_len and subject_len so it can walk the strings. By doing this, you bring the to_len and subject_len variables to 0, thus nothing is ever efree()'d in the end, and you've got a memory leak. The leak is small and not noticable typically, but with mass mailing scripts that loop using mail(), it could be huge. Reproduce code: --- See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165. Actual result: -- I have not tested for an actual memory leak by calling mail() in a loop - I was just going to write my own mail() function and was using the code in mail.c to do it with, and came across this. If this is a false report, I am sorry, but I do believe it's real. -- Edit this bug report at http://bugs.php.net/?id=26847&edit=1
#25640 [Bgs]: simplexml element object properties return empty objects
ID: 25640 Updated by: [EMAIL PROTECTED] Reported By: tater at potatoe dot com Status: Bogus Bug Type: XML related Operating System: * PHP Version: 5* Assigned To: sterling New Comment: The objects are empty because they only use dynamic properties and do not declare any objects. Those properties can be seen as if they were handled by __get() and __set() in user defined classes. Previous Comments: [2004-01-08 15:41:23] [EMAIL PROTECTED] The word bogus may be bogus but hey that's an automatic reply - sorry if you get pissed of by an autoreply. [2004-01-08 15:33:49] tater at potatoe dot com This bug was not "bogus" - assignments did not work, nor did printing. There now seems to be some implicit string conversions that fix that. Which is fine, I guess. It's still very odd, at the least, that a property access returns an empty object. Nothing else works like this. If it's intentional, it's a very peculiar and questionable intention. Run this code: s1s2s3'; $t = simplexml_load_string($xml); $x = new stdClass; $x->foo = 's1'; $x->bar = array('s2','s3'); var_dump($t,$t->foo,$t->bar); var_dump($x,$x->foo,$x->bar); ?> and you really think the results are "fine"?? Whatever. That word, "bogus", is like pissing on the people entering bugs. (Ask a native English speaker what they would think you meant if you called something they did "bogus".) If you'd rather just have a broken product, then why allow bug entries at all? [2004-01-08 14:55:40] [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 A property access returns the element (as an object). Using __tostring() or conversion by (string) returns the text content. If an element contains multiple elements of the same name then accessing those by proeprty returns an array of eleemnt objects. So all is fine. [2003-12-16 08:52:10] tim at timcrider dot com I have been able to produce a similar problem, but I'm not sure if it's exactly the same bug or a variant of this one. -[ XML Field ]- a b c -[ Script ]- #!/usr/local/bin/php -q fields->myField); $i++) { $v = $sx->fields->myField[$i]; print "True Value: {$v}\n"; $tmp[] = $v; $tmp2[] = "$v"; } print "Trying to view 'tmp' array:\n\n"; print_r($tmp); print "Trying to view 'tmp2' array:\n\n"; print_r($tmp2); ?> -[ Output ]- simplexml_element Object ( [fields] => simplexml_element Object ( [myField] => Array ( [0] => a [1] => b [2] => c ) ) ) True Value: a True Value: b True Value: c Trying to view 'tmp' array: Array ( [0] => simplexml_element Object ( ) [1] => simplexml_element Object ( ) [2] => simplexml_element Object ( ) ) Trying to view 'tmp2' array: Array ( [0] => a [1] => b [2] => c ) -[ PHP Version Info ]- PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov I tried the latest CVS, at the time of this posting, and it would not build because of a mysqli compile problem. [2003-09-23 21:25:25] tater at potatoe dot com Description: I guess this is related to the recent toString() stuff - simplexml_element object properties can't be printed or assigned, they all come out as 'Object #x'. the string values turn into empty simplexml_element objects. Reproduce code: --- s1s2s3'; $t = simplexml_load_string($xml); var_dump($t,$t->foo,$t->bar); ?> Expected result: object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } string(2) "s1" array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } Actual result: -- object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } object(simplexml_element)#2 (0) { } array(2) { [0]=> object(simplexml_element)#3 (0) { } [1]=> object(simplexml_element)#4 (0) { } } -
#25640 [Bgs]: simplexml element object properties return empty objects
ID: 25640 Updated by: [EMAIL PROTECTED] Reported By: tater at potatoe dot com Status: Bogus Bug Type: XML related Operating System: * PHP Version: 5* Assigned To: sterling New Comment: The word bogus may be bogus but hey that's an automatic reply - sorry if you get pissed of by an autoreply. Previous Comments: [2004-01-08 15:33:49] tater at potatoe dot com This bug was not "bogus" - assignments did not work, nor did printing. There now seems to be some implicit string conversions that fix that. Which is fine, I guess. It's still very odd, at the least, that a property access returns an empty object. Nothing else works like this. If it's intentional, it's a very peculiar and questionable intention. Run this code: s1s2s3'; $t = simplexml_load_string($xml); $x = new stdClass; $x->foo = 's1'; $x->bar = array('s2','s3'); var_dump($t,$t->foo,$t->bar); var_dump($x,$x->foo,$x->bar); ?> and you really think the results are "fine"?? Whatever. That word, "bogus", is like pissing on the people entering bugs. (Ask a native English speaker what they would think you meant if you called something they did "bogus".) If you'd rather just have a broken product, then why allow bug entries at all? [2004-01-08 14:55:40] [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 A property access returns the element (as an object). Using __tostring() or conversion by (string) returns the text content. If an element contains multiple elements of the same name then accessing those by proeprty returns an array of eleemnt objects. So all is fine. [2003-12-16 08:52:10] tim at timcrider dot com I have been able to produce a similar problem, but I'm not sure if it's exactly the same bug or a variant of this one. -[ XML Field ]- a b c -[ Script ]- #!/usr/local/bin/php -q fields->myField); $i++) { $v = $sx->fields->myField[$i]; print "True Value: {$v}\n"; $tmp[] = $v; $tmp2[] = "$v"; } print "Trying to view 'tmp' array:\n\n"; print_r($tmp); print "Trying to view 'tmp2' array:\n\n"; print_r($tmp2); ?> -[ Output ]- simplexml_element Object ( [fields] => simplexml_element Object ( [myField] => Array ( [0] => a [1] => b [2] => c ) ) ) True Value: a True Value: b True Value: c Trying to view 'tmp' array: Array ( [0] => simplexml_element Object ( ) [1] => simplexml_element Object ( ) [2] => simplexml_element Object ( ) ) Trying to view 'tmp2' array: Array ( [0] => a [1] => b [2] => c ) -[ PHP Version Info ]- PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov I tried the latest CVS, at the time of this posting, and it would not build because of a mysqli compile problem. [2003-09-23 21:25:25] tater at potatoe dot com Description: I guess this is related to the recent toString() stuff - simplexml_element object properties can't be printed or assigned, they all come out as 'Object #x'. the string values turn into empty simplexml_element objects. Reproduce code: --- s1s2s3'; $t = simplexml_load_string($xml); var_dump($t,$t->foo,$t->bar); ?> Expected result: object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } string(2) "s1" array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } Actual result: -- object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } object(simplexml_element)#2 (0) { } array(2) { [0]=> object(simplexml_element)#3 (0) { } [1]=> object(simplexml_element)#4 (0) { } } -- Edit this bug report at http://bugs.php.net/?id=25640&edit=1
#26847 [Opn->Bgs]: memory leak with to_r and subject_r in mail() function
ID: 26847 Updated by: [EMAIL PROTECTED] Reported By: nutbar at innocent dot com -Status: Open +Status: Bogus Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: Impossible leak. if (to_len > 0) { efree(to_r); } if (subject_len > 0) { efree(subject_r); } Is what the code in CVS does. If to_len or subject_len are < 1 then no allocation happens in the 1st place. Previous Comments: [2004-01-08 15:34:23] nutbar at innocent dot com I guess an alternate fix would also be when the efree()'s are called. If you init all your char *'s to NULL, then you can simply do: if (to_r != NULL) { efree(to_r); } if (subject_r != NULL) { efree(subject_r); } [2004-01-08 15:31:12] nutbar at innocent dot com By the way, very simple fix: Add this to the variable declarations: int j = 0; Then the lines of code as mentioned before, but fixed: if (to_len > 0) { to_r = estrndup(to, to_len); for (j = to_len; j > 0; j--) { if (!isspace((unsigned char) to_r[j - 1])) { break; } to_r[j - 1] = '\0'; } and: if (subject_len > 0) { subject_r = estrndup(subject, subject_len); for (j = subject_len; j > 0; j--) { if (!isspace((unsigned char) subject_r[j - 1])) { break; } subject_r[j - 1] = '\0'; } I just initialized j in the for loop to be the value of to_len and subject_len, then I use j everywhere rather than to_len or subject_len so that they stay unmodified. [2004-01-08 13:22:55] nutbar at innocent dot com Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the "to_len" count is greater than 0, it duplicates the "to" string to "to_r" and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it does an if () test to see if it should or not - the if test compares to_len and subject_len to see if they are greater than 0 and if so, efree()'s them. The problem is that in the code that does stuff with to_r and subject_r, there are for loops which decrement to_len and subject_len so it can walk the strings. By doing this, you bring the to_len and subject_len variables to 0, thus nothing is ever efree()'d in the end, and you've got a memory leak. The leak is small and not noticable typically, but with mass mailing scripts that loop using mail(), it could be huge. Reproduce code: --- See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165. Actual result: -- I have not tested for an actual memory leak by calling mail() in a loop - I was just going to write my own mail() function and was using the code in mail.c to do it with, and came across this. If this is a false report, I am sorry, but I do believe it's real. -- Edit this bug report at http://bugs.php.net/?id=26847&edit=1
#26847 [Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847 User updated by: nutbar at innocent dot com Reported By: nutbar at innocent dot com Status: Open Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: I guess an alternate fix would also be when the efree()'s are called. If you init all your char *'s to NULL, then you can simply do: if (to_r != NULL) { efree(to_r); } if (subject_r != NULL) { efree(subject_r); } Previous Comments: [2004-01-08 15:31:12] nutbar at innocent dot com By the way, very simple fix: Add this to the variable declarations: int j = 0; Then the lines of code as mentioned before, but fixed: if (to_len > 0) { to_r = estrndup(to, to_len); for (j = to_len; j > 0; j--) { if (!isspace((unsigned char) to_r[j - 1])) { break; } to_r[j - 1] = '\0'; } and: if (subject_len > 0) { subject_r = estrndup(subject, subject_len); for (j = subject_len; j > 0; j--) { if (!isspace((unsigned char) subject_r[j - 1])) { break; } subject_r[j - 1] = '\0'; } I just initialized j in the for loop to be the value of to_len and subject_len, then I use j everywhere rather than to_len or subject_len so that they stay unmodified. [2004-01-08 13:22:55] nutbar at innocent dot com Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the "to_len" count is greater than 0, it duplicates the "to" string to "to_r" and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it does an if () test to see if it should or not - the if test compares to_len and subject_len to see if they are greater than 0 and if so, efree()'s them. The problem is that in the code that does stuff with to_r and subject_r, there are for loops which decrement to_len and subject_len so it can walk the strings. By doing this, you bring the to_len and subject_len variables to 0, thus nothing is ever efree()'d in the end, and you've got a memory leak. The leak is small and not noticable typically, but with mass mailing scripts that loop using mail(), it could be huge. Reproduce code: --- See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165. Actual result: -- I have not tested for an actual memory leak by calling mail() in a loop - I was just going to write my own mail() function and was using the code in mail.c to do it with, and came across this. If this is a false report, I am sorry, but I do believe it's real. -- Edit this bug report at http://bugs.php.net/?id=26847&edit=1
#25640 [Bgs]: simplexml element object properties return empty objects
ID: 25640 User updated by: tater at potatoe dot com Reported By: tater at potatoe dot com Status: Bogus Bug Type: XML related Operating System: * PHP Version: 5* Assigned To: sterling New Comment: This bug was not "bogus" - assignments did not work, nor did printing. There now seems to be some implicit string conversions that fix that. Which is fine, I guess. It's still very odd, at the least, that a property access returns an empty object. Nothing else works like this. If it's intentional, it's a very peculiar and questionable intention. Run this code: s1s2s3'; $t = simplexml_load_string($xml); $x = new stdClass; $x->foo = 's1'; $x->bar = array('s2','s3'); var_dump($t,$t->foo,$t->bar); var_dump($x,$x->foo,$x->bar); ?> and you really think the results are "fine"?? Whatever. That word, "bogus", is like pissing on the people entering bugs. (Ask a native English speaker what they would think you meant if you called something they did "bogus".) If you'd rather just have a broken product, then why allow bug entries at all? Previous Comments: [2004-01-08 14:55:40] [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 A property access returns the element (as an object). Using __tostring() or conversion by (string) returns the text content. If an element contains multiple elements of the same name then accessing those by proeprty returns an array of eleemnt objects. So all is fine. [2003-12-16 08:52:10] tim at timcrider dot com I have been able to produce a similar problem, but I'm not sure if it's exactly the same bug or a variant of this one. -[ XML Field ]- a b c -[ Script ]- #!/usr/local/bin/php -q fields->myField); $i++) { $v = $sx->fields->myField[$i]; print "True Value: {$v}\n"; $tmp[] = $v; $tmp2[] = "$v"; } print "Trying to view 'tmp' array:\n\n"; print_r($tmp); print "Trying to view 'tmp2' array:\n\n"; print_r($tmp2); ?> -[ Output ]- simplexml_element Object ( [fields] => simplexml_element Object ( [myField] => Array ( [0] => a [1] => b [2] => c ) ) ) True Value: a True Value: b True Value: c Trying to view 'tmp' array: Array ( [0] => simplexml_element Object ( ) [1] => simplexml_element Object ( ) [2] => simplexml_element Object ( ) ) Trying to view 'tmp2' array: Array ( [0] => a [1] => b [2] => c ) -[ PHP Version Info ]- PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov I tried the latest CVS, at the time of this posting, and it would not build because of a mysqli compile problem. [2003-09-23 21:25:25] tater at potatoe dot com Description: I guess this is related to the recent toString() stuff - simplexml_element object properties can't be printed or assigned, they all come out as 'Object #x'. the string values turn into empty simplexml_element objects. Reproduce code: --- s1s2s3'; $t = simplexml_load_string($xml); var_dump($t,$t->foo,$t->bar); ?> Expected result: object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } string(2) "s1" array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } Actual result: -- object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } object(simplexml_element)#2 (0) { } array(2) { [0]=> object(simplexml_element)#3 (0) { } [1]=> object(simplexml_element)#4 (0) { } } -- Edit this bug report at http://bugs.php.net/?id=25640&edit=1
#26847 [Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847 User updated by: nutbar at innocent dot com Reported By: nutbar at innocent dot com Status: Open Bug Type: Mail related Operating System: any - source code issue PHP Version: 4.3.4 New Comment: By the way, very simple fix: Add this to the variable declarations: int j = 0; Then the lines of code as mentioned before, but fixed: if (to_len > 0) { to_r = estrndup(to, to_len); for (j = to_len; j > 0; j--) { if (!isspace((unsigned char) to_r[j - 1])) { break; } to_r[j - 1] = '\0'; } and: if (subject_len > 0) { subject_r = estrndup(subject, subject_len); for (j = subject_len; j > 0; j--) { if (!isspace((unsigned char) subject_r[j - 1])) { break; } subject_r[j - 1] = '\0'; } I just initialized j in the for loop to be the value of to_len and subject_len, then I use j everywhere rather than to_len or subject_len so that they stay unmodified. Previous Comments: [2004-01-08 13:22:55] nutbar at innocent dot com Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the "to_len" count is greater than 0, it duplicates the "to" string to "to_r" and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it does an if () test to see if it should or not - the if test compares to_len and subject_len to see if they are greater than 0 and if so, efree()'s them. The problem is that in the code that does stuff with to_r and subject_r, there are for loops which decrement to_len and subject_len so it can walk the strings. By doing this, you bring the to_len and subject_len variables to 0, thus nothing is ever efree()'d in the end, and you've got a memory leak. The leak is small and not noticable typically, but with mass mailing scripts that loop using mail(), it could be huge. Reproduce code: --- See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165. Actual result: -- I have not tested for an actual memory leak by calling mail() in a loop - I was just going to write my own mail() function and was using the code in mail.c to do it with, and came across this. If this is a false report, I am sorry, but I do believe it's real. -- Edit this bug report at http://bugs.php.net/?id=26847&edit=1
#25640 [Asn->Bgs]: simplexml element object properties return empty objects
ID: 25640 Updated by: [EMAIL PROTECTED] Reported By: tater at potatoe dot com -Status: Assigned +Status: Bogus Bug Type: XML related Operating System: * -PHP Version: 5CVS-2003-09-23 (dev) +PHP Version: 5* Assigned To: sterling New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php A property access returns the element (as an object). Using __tostring() or conversion by (string) returns the text content. If an element contains multiple elements of the same name then accessing those by proeprty returns an array of eleemnt objects. So all is fine. Previous Comments: [2003-12-16 08:52:10] tim at timcrider dot com I have been able to produce a similar problem, but I'm not sure if it's exactly the same bug or a variant of this one. -[ XML Field ]- a b c -[ Script ]- #!/usr/local/bin/php -q fields->myField); $i++) { $v = $sx->fields->myField[$i]; print "True Value: {$v}\n"; $tmp[] = $v; $tmp2[] = "$v"; } print "Trying to view 'tmp' array:\n\n"; print_r($tmp); print "Trying to view 'tmp2' array:\n\n"; print_r($tmp2); ?> -[ Output ]- simplexml_element Object ( [fields] => simplexml_element Object ( [myField] => Array ( [0] => a [1] => b [2] => c ) ) ) True Value: a True Value: b True Value: c Trying to view 'tmp' array: Array ( [0] => simplexml_element Object ( ) [1] => simplexml_element Object ( ) [2] => simplexml_element Object ( ) ) Trying to view 'tmp2' array: Array ( [0] => a [1] => b [2] => c ) -[ PHP Version Info ]- PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov I tried the latest CVS, at the time of this posting, and it would not build because of a mysqli compile problem. [2003-09-23 21:25:25] tater at potatoe dot com Description: I guess this is related to the recent toString() stuff - simplexml_element object properties can't be printed or assigned, they all come out as 'Object #x'. the string values turn into empty simplexml_element objects. Reproduce code: --- s1s2s3'; $t = simplexml_load_string($xml); var_dump($t,$t->foo,$t->bar); ?> Expected result: object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } string(2) "s1" array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } Actual result: -- object(simplexml_element)#1 (2) { ["foo"]=> string(2) "s1" ["bar"]=> array(2) { [0]=> string(2) "s2" [1]=> string(2) "s3" } } object(simplexml_element)#2 (0) { } array(2) { [0]=> object(simplexml_element)#3 (0) { } [1]=> object(simplexml_element)#4 (0) { } } -- Edit this bug report at http://bugs.php.net/?id=25640&edit=1
#26848 [NEW]: Make highlight functions XHTML 1.0 Strict compliant
From: phpman at fosketts dot co dot uk Operating system: Win XP PHP version: 4.3.4 PHP Bug Type: Feature/Change Request Bug description: Make highlight functions XHTML 1.0 Strict compliant Description: Will the highlight functions (highlight_string() and highlight_file()) be modified to produce valid XHTML 1.0 Strict output? This has already been done in other functions, e.g. nl2br(). A simple solution would be to edit zend_highlight.c as follows: 1) Replace with on lines 106 and 155 2) Replace with on lines 151, 191 and 193 Thanks Sean :) -- Edit bug report at http://bugs.php.net/?id=26848&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26848&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26848&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26848&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26848&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26848&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26848&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26848&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26848&r=support Expected behavior: http://bugs.php.net/fix.php?id=26848&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26848&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26848&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26848&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26848&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26848&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26848&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26848&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26848&r=float
#26846 [Opn->Fbk]: fpassthru() segfaults on certain files
ID: 26846 Updated by: [EMAIL PROTECTED] Reported By: djones at xtreme-eda dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE PHP Version: 4.3.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2004-01-08 13:16:54] djones at xtreme-eda dot com Description: PHP configuration: http://www.inode.org/test.php I am running an application that sends files to the user using fpassthru(). With certain files, Apache exits with signal 11. There does not seem to be any distinguishing characteristic between files that are sent OK and files that are not. Reproduce code: --- See http://www.inode.org/passthru.php_ The trailing underscore prevents execution so you can view the source. The code contains paths to two files; one of which can be transferred and one that cannot. You may transfer these files to your system to attempt reproduction. (Instructions for said transfer are provided in passthru.php) Running the BAD file from the PHP command line appears to work correctly so this might be a PHP-Apache interaction issue. Expected result: With the GOOD file: you can save the document and view it. With the BAD file: I would expect to be able to save it too. Actual result: -- With the BAD file: Apache segfaults signal 11. I'm not sure how I can get a GDB backtrace from a running Apache instance. -- Edit this bug report at http://bugs.php.net/?id=26846&edit=1
#26839 [Ver]: unexpected results from simple array routine
ID: 26839 Updated by: [EMAIL PROTECTED] Reported By: dweller at devonweller dot com Status: Verified Bug Type: Arrays related Operating System: Linux Intel (Redhat) PHP Version: 4CVS-2004-01-08 (dev) New Comment: Without the print_r() call no crash but this: --- /usr/src/web/php/php4/Zend/zend_execute.h(44) : Block 0x0864E478 status: Beginning: Overrun (magic=0x40847B54, expected=0x7312F8DC) End: Unknown --- Previous Comments: [2004-01-08 14:28:14] [EMAIL PROTECTED] Works fine with PHP 5, crashes for me with PHP 4 (latest CVS): #0 0x407884ec in mempcpy () from /lib/i686/libc.so.6 #1 0x4077a850 in _IO_new_file_xsputn () from /lib/i686/libc.so.6 #2 0x4076ff9f in fwrite () from /lib/i686/libc.so.6 #3 0x082b0f75 in sapi_cli_single_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:190 #4 0x082afb2e in sapi_cli_ub_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:203 #5 0x082699fd in php_ub_body_write_no_header (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/output.c:689 #6 0x0826863a in php_body_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/output.c:121 #7 0x08254dc0 in php_body_write_wrapper (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/main.c:1022 #8 0x0828c2d8 in zend_print_zval_ex (write_func=0x8254d9f , expr=0xbfffd330, indent=0) at /usr/src/web/php/php4/Zend/zend.c:211 #9 0x0828c256 in zend_print_zval (expr=0x864e2cc, indent=0) at /usr/src/web/php/php4/Zend/zend.c:192 #10 0x0828bd0f in zend_print_variable (var=0x864e2cc) at /usr/src/web/php/php4/Zend/zend_variables.c:147 #11 0x0828c45a in zend_print_zval_r_ex (write_func=0x8254d9f , expr=0x864e2cc, indent=8) at /usr/src/web/php/php4/Zend/zend.c:253 #12 0x0828c335 in zend_print_zval_r (expr=0x864e2cc, indent=8) at /usr/src/web/php/php4/Zend/zend.c:221 #13 0x0828bf6f in print_hash (ht=0x865337c, indent=4) at /usr/src/web/php/php4/Zend/zend.c:130 #14 0x0828c3c8 in zend_print_zval_r_ex (write_func=0x8254d9f , expr=0x86534e4, indent=0) at /usr/src/web/php/php4/Zend/zend.c:235 #15 0x0828c335 in zend_print_zval_r (expr=0x86534e4, indent=0) at /usr/src/web/php/php4/Zend/zend.c:221 #16 0x081e082d in zif_print_r (ht=1, return_value=0x962c23c, this_ptr=0x0, return_value_used=0) at /usr/src/web/php/php4/ext/standard/basic_functions.c:2488 #17 0x0829ed0e in execute (op_array=0x864e9f4) at /usr/src/web/php/php4/Zend/zend_execute.c:1616 #18 0x0828d76a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php/php4/Zend/zend.c:884 #19 0x08256573 in php_execute_script (primary_file=0xbbc0) at /usr/src/web/php/php4/main/main.c:1727 #20 0x082b0da3 in main (argc=2, argv=0xbc54) at /usr/src/web/php/php4/sapi/cli/php_cli.c:820 [2004-01-08 10:04:42] [EMAIL PROTECTED] $i < 32768 results in array(2) { ["var1"]=> UNKNOWN:0 ["var2"]=> UNKNOWN:0 } $i < 32767 results in array(2) { ["var1"]=> int(1) ["var2"]=> int(1) } [2004-01-08 07:01:49] dweller at devonweller dot com Description: The attached simple array routine produces unexpected results when the loop count is greater than approx. 33000. Perhaps this is some kind of reference counting bug. Reproduce code: --- // causes unexpected *RECURSION* references $var1 = 1; $array = array(); for($i=0;$i<33000;++$i) { $var2 = $var1; $array[] = array( 'var1' => $var1, 'var2' => $var2, ); } print_r($array[0]); Expected result: Array ( [var1] => 1 [var2] => 1 ) Actual result: -- Array ( [var1] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) [var2] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) ) -- Edit this bug report at http://bugs.php.net/?id=26839&edit=1
#26839 [Ver]: unexpected results from simple array routine
ID: 26839 Updated by: [EMAIL PROTECTED] Reported By: dweller at devonweller dot com Status: Verified Bug Type: Arrays related Operating System: Linux Intel (Redhat) PHP Version: 4CVS-2004-01-08 (dev) New Comment: Works fine with PHP 5, crashes for me with PHP 4 (latest CVS): #0 0x407884ec in mempcpy () from /lib/i686/libc.so.6 #1 0x4077a850 in _IO_new_file_xsputn () from /lib/i686/libc.so.6 #2 0x4076ff9f in fwrite () from /lib/i686/libc.so.6 #3 0x082b0f75 in sapi_cli_single_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:190 #4 0x082afb2e in sapi_cli_ub_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:203 #5 0x082699fd in php_ub_body_write_no_header (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/output.c:689 #6 0x0826863a in php_body_write (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/output.c:121 #7 0x08254dc0 in php_body_write_wrapper (str=0x0, str_length=1515870810) at /usr/src/web/php/php4/main/main.c:1022 #8 0x0828c2d8 in zend_print_zval_ex (write_func=0x8254d9f , expr=0xbfffd330, indent=0) at /usr/src/web/php/php4/Zend/zend.c:211 #9 0x0828c256 in zend_print_zval (expr=0x864e2cc, indent=0) at /usr/src/web/php/php4/Zend/zend.c:192 #10 0x0828bd0f in zend_print_variable (var=0x864e2cc) at /usr/src/web/php/php4/Zend/zend_variables.c:147 #11 0x0828c45a in zend_print_zval_r_ex (write_func=0x8254d9f , expr=0x864e2cc, indent=8) at /usr/src/web/php/php4/Zend/zend.c:253 #12 0x0828c335 in zend_print_zval_r (expr=0x864e2cc, indent=8) at /usr/src/web/php/php4/Zend/zend.c:221 #13 0x0828bf6f in print_hash (ht=0x865337c, indent=4) at /usr/src/web/php/php4/Zend/zend.c:130 #14 0x0828c3c8 in zend_print_zval_r_ex (write_func=0x8254d9f , expr=0x86534e4, indent=0) at /usr/src/web/php/php4/Zend/zend.c:235 #15 0x0828c335 in zend_print_zval_r (expr=0x86534e4, indent=0) at /usr/src/web/php/php4/Zend/zend.c:221 #16 0x081e082d in zif_print_r (ht=1, return_value=0x962c23c, this_ptr=0x0, return_value_used=0) at /usr/src/web/php/php4/ext/standard/basic_functions.c:2488 #17 0x0829ed0e in execute (op_array=0x864e9f4) at /usr/src/web/php/php4/Zend/zend_execute.c:1616 #18 0x0828d76a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php/php4/Zend/zend.c:884 #19 0x08256573 in php_execute_script (primary_file=0xbbc0) at /usr/src/web/php/php4/main/main.c:1727 #20 0x082b0da3 in main (argc=2, argv=0xbc54) at /usr/src/web/php/php4/sapi/cli/php_cli.c:820 Previous Comments: [2004-01-08 10:04:42] [EMAIL PROTECTED] $i < 32768 results in array(2) { ["var1"]=> UNKNOWN:0 ["var2"]=> UNKNOWN:0 } $i < 32767 results in array(2) { ["var1"]=> int(1) ["var2"]=> int(1) } [2004-01-08 07:01:49] dweller at devonweller dot com Description: The attached simple array routine produces unexpected results when the loop count is greater than approx. 33000. Perhaps this is some kind of reference counting bug. Reproduce code: --- // causes unexpected *RECURSION* references $var1 = 1; $array = array(); for($i=0;$i<33000;++$i) { $var2 = $var1; $array[] = array( 'var1' => $var1, 'var2' => $var2, ); } print_r($array[0]); Expected result: Array ( [var1] => 1 [var2] => 1 ) Actual result: -- Array ( [var1] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) [var2] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) ) -- Edit this bug report at http://bugs.php.net/?id=26839&edit=1
#26791 [Opn]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot Previous Comments: [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? [2004-01-05 01:34:58] danielc at analysisandsolutions dot com Description: The mssql.textlimit and mssql.textsize configuration options can't be set via ini_set(). Changing them in php.ini works. This is also the case in a recent PHP 5 snapshot (500rc1-dev--php5-win32-200401022330). This is the same issue as bug 20797 which was closed due to no feedback. SCRIPT CAN CHANGE LIMIT === php.ini mssql.textlimit = 2147483647 mssql.textsize = 2147483647 script SET TEXTSIZE 20 SCRIPT CAN'T CHANGE LIMIT = php.ini mssql.textlimit = 20 mssql.textsize = 20 script ini_set('mssql.textlimit', 2147483647); ini_set('mssql.textsize', 2147483647); php.ini mssql.textlimit = 2147483647 mssql.textsize = 2147483647 script ini_set('mssql.textlimit', 20); ini_set('mssql.textsize', 20); php.ini ; mssql.textlimit = 2147483647 ; mssql.textsize = 2147483647 script SET TEXTSIZE 2147483647 php.ini mssql.textlimit = 20 mssql.textsize = 20 script SET TEXTSIZE 2147483647 -- Edit this bug report at http://bugs.php.net/?id=26791&edit=1
#26847 [NEW]: memory leak with to_r and subject_r in mail() function
From: nutbar at innocent dot com Operating system: any - source code issue PHP version: 4.3.4 PHP Bug Type: Mail related Bug description: memory leak with to_r and subject_r in mail() function Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the "to_len" count is greater than 0, it duplicates the "to" string to "to_r" and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it does an if () test to see if it should or not - the if test compares to_len and subject_len to see if they are greater than 0 and if so, efree()'s them. The problem is that in the code that does stuff with to_r and subject_r, there are for loops which decrement to_len and subject_len so it can walk the strings. By doing this, you bring the to_len and subject_len variables to 0, thus nothing is ever efree()'d in the end, and you've got a memory leak. The leak is small and not noticable typically, but with mass mailing scripts that loop using mail(), it could be huge. Reproduce code: --- See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165. Actual result: -- I have not tested for an actual memory leak by calling mail() in a loop - I was just going to write my own mail() function and was using the code in mail.c to do it with, and came across this. If this is a false report, I am sorry, but I do believe it's real. -- Edit bug report at http://bugs.php.net/?id=26847&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26847&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26847&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26847&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26847&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26847&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26847&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26847&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26847&r=support Expected behavior: http://bugs.php.net/fix.php?id=26847&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26847&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26847&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26847&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26847&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26847&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26847&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26847&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26847&r=float
#26846 [NEW]: fpassthru() segfaults on certain files
From: djones at xtreme-eda dot com Operating system: FreeBSD 4.8-RELEASE PHP version: 4.3.4 PHP Bug Type: Reproducible crash Bug description: fpassthru() segfaults on certain files Description: PHP configuration: http://www.inode.org/test.php I am running an application that sends files to the user using fpassthru(). With certain files, Apache exits with signal 11. There does not seem to be any distinguishing characteristic between files that are sent OK and files that are not. Reproduce code: --- See http://www.inode.org/passthru.php_ The trailing underscore prevents execution so you can view the source. The code contains paths to two files; one of which can be transferred and one that cannot. You may transfer these files to your system to attempt reproduction. (Instructions for said transfer are provided in passthru.php) Running the BAD file from the PHP command line appears to work correctly so this might be a PHP-Apache interaction issue. Expected result: With the GOOD file: you can save the document and view it. With the BAD file: I would expect to be able to save it too. Actual result: -- With the BAD file: Apache segfaults signal 11. I'm not sure how I can get a GDB backtrace from a running Apache instance. -- Edit bug report at http://bugs.php.net/?id=26846&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26846&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26846&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26846&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26846&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26846&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26846&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26846&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26846&r=support Expected behavior: http://bugs.php.net/fix.php?id=26846&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26846&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26846&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26846&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26846&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26846&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26846&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26846&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26846&r=float
#26206 [Fbk->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No dice using php5-win32-200401081130 Previous Comments: [2004-01-07 21:38: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 Please try the latest snapshot. [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which "C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls;" are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26845 [Opn->Bgs]: Very Seriously Bug!!!!
ID: 26845 Updated by: [EMAIL PROTECTED] Reported By: calmman dot yang at 163 dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Win2000Pro SP4 PHP Version: 4.3.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php $com->ComRType != $com->ComRTime Next time post a proper bugreport, screenshots are not an option. Previous Comments: [2004-01-08 11:35:44] calmman dot yang at 163 dot com Description: Please Look at the screen shot! http://www.ltclan.net/bug.jpg very import!!! PHP Version 4.3.4 you can also use the mail: [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=26845&edit=1
#26845 [NEW]: Very Seriously Bug!!!!
From: calmman dot yang at 163 dot com Operating system: Win2000Pro SP4 PHP version: 4.3.4 PHP Bug Type: Session related Bug description: Very Seriously Bug Description: Please Look at the screen shot! http://www.ltclan.net/bug.jpg very import!!! PHP Version 4.3.4 you can also use the mail: [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=26845&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26845&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26845&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26845&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26845&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26845&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26845&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26845&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26845&r=support Expected behavior: http://bugs.php.net/fix.php?id=26845&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26845&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26845&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26845&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26845&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26845&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26845&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26845&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26845&r=float
#25803 [Csd->Opn]: xml_get_current_byte_index() always returns 0 on PHP 5.x
ID: 25803 User updated by: j dot spit at uptime dot nl Reported By: j dot spit at uptime dot nl -Status: Closed +Status: Open Bug Type: XML related Operating System: Irrelevant PHP Version: 5CVS-2003-10-10 Assigned To: moriyoshi New Comment: Hello, I am trying to find out what the current behaviour of xml_get_current_byte_index() is in PHP5 version beta3 and above. Is this documented somewhere ? I am developing software that is highly dependant on this function. Thanks ! Previous Comments: [2003-11-26 16:07:41] j dot spit at uptime dot nl Hi, I noticed that in the latest CVS version it does not return zero anymore, which is good, but on the other hand it does return different values compared to php5.0.0b1. Can you enlighten me as to what value it currently returns ? Thanks. [2003-11-24 01:10:02] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Behaviour of xml_get_current_byte_index() is subject to change in php 5.0. It would probably return the end position of the portion that has just been parsed, by contrast to the old behaviour in 4.x, where it returns the start position of the portion being parsed. [2003-11-19 11:30:31] j dot spit at uptime dot nl Have the same problem on Linux as well now, when using PHP5.0.0b2. Any update yet ? [2003-10-09 09:11:55] j dot spit at uptime dot nl Description: xml_get_current_byte_index always returns 0 on windows xp, it works fine on Linux systems. Using PHP5 beta 1 on both platforms. Reproduce code: --- "; } function endElement($parser,$name) { echo "End : ".xml_get_current_byte_index( $parser ).""; } $parser = xml_parser_create(); xml_set_element_handler($parser,'startElement','endElement'); xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,0); xml_parse($parser, "testblaat"); xml_parser_free($parser); ?> Expected result: Start : 0 Start : 13 End : 21 End : 25 This is the output on a Linux system. Actual result: -- Start : 0 Start : 0 End : 0 End : 0 This is the output on a Windows XP system. -- Edit this bug report at http://bugs.php.net/?id=25803&edit=1
#26839 [Opn->Ver]: unexpected results from simple array routine
ID: 26839 Updated by: [EMAIL PROTECTED] Reported By: dweller at devonweller dot com -Status: Open +Status: Verified Bug Type: Arrays related Operating System: Linux Intel (Redhat) -PHP Version: 4.3.4 +PHP Version: 4CVS-2004-01-08 (dev) New Comment: $i < 32768 results in array(2) { ["var1"]=> UNKNOWN:0 ["var2"]=> UNKNOWN:0 } $i < 32767 results in array(2) { ["var1"]=> int(1) ["var2"]=> int(1) } Previous Comments: [2004-01-08 07:01:49] dweller at devonweller dot com Description: The attached simple array routine produces unexpected results when the loop count is greater than approx. 33000. Perhaps this is some kind of reference counting bug. Reproduce code: --- // causes unexpected *RECURSION* references $var1 = 1; $array = array(); for($i=0;$i<33000;++$i) { $var2 = $var1; $array[] = array( 'var1' => $var1, 'var2' => $var2, ); } print_r($array[0]); Expected result: Array ( [var1] => 1 [var2] => 1 ) Actual result: -- Array ( [var1] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) [var2] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) ) -- Edit this bug report at http://bugs.php.net/?id=26839&edit=1
#26842 [Opn->Bgs]: localeconv gives wrong decimal place values for locale it_IT
ID: 26842 Updated by: [EMAIL PROTECTED] Reported By: marko at oblo dot com -Status: Open +Status: Bogus Bug Type: *Languages/Translation Operating System: linux PHP Version: 4.3.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This is an issue with the locale installed on your computer. Please consult the support of your Linux distribution. Previous Comments: [2004-01-08 07:32:00] marko at oblo dot com Description: localeconv() function returns the wrong values for int_frac_digits and frac_digits. they should be "2" and not "0" (which was correct in the time of the Lira) Reproduce code: --- string(1) "." ["int_frac_digits"]=> int(2) ["frac_digits"]=> int(2) ["mon_grouping"]=> array(2) { [0]=> int(3) [1]=> int(3) } } Actual result: -- array(18) { ["decimal_point"]=> string(1) "." ["int_frac_digits"]=> int(0) ["frac_digits"]=> int(0) ["mon_grouping"]=> array(2) { [0]=> int(3) [1]=> int(3) } } -- Edit this bug report at http://bugs.php.net/?id=26842&edit=1
#26844 [NEW]: Problems with --with-mime-magic
From: php at humbapa dot ch Operating system: Linux 2.4.22 (Debian unstable) PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: PHP options/info functions Bug description: Problems with --with-mime-magic Description: When I start apache2 with php5cvs as SAPI module the error_log contains: PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:22) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:59) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:270) 'text/plain8bit' is not a valid mimetype, etry skipped in Unknown on line 0 I use the latest PHP5 from CVS and build with: --with-mime-magic=/usr/local/apache2/conf/magic (the magicfile that comes with apache2) - is it not possible to use the magicfile from apache2? - why do the startuperros show up when I set display_startup_errors = Off in php.ini? - Apache2 exit with segmentation fault when I call the function phpinfo() - etry should be entry :-) -- Edit bug report at http://bugs.php.net/?id=26844&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26844&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26844&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26844&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26844&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26844&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26844&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26844&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26844&r=support Expected behavior: http://bugs.php.net/fix.php?id=26844&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26844&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26844&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26844&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26844&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26844&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26844&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26844&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26844&r=float
#26843 [Opn->Bgs]: PHP doesn't work...
ID: 26843 Updated by: [EMAIL PROTECTED] Reported By: admin at wp dot pl -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: DOS PHP Version: 5CVS-2004-01-08 (dev) New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-01-08 08:35:37] admin at onet dot pl Yeah, it doesn't work also at my system... [2004-01-08 08:34:38] admin at wp dot pl Description: I installed PHP but it doesn't work... Reproduce code: --- (null) Expected result: null Actual result: -- (null) -- Edit this bug report at http://bugs.php.net/?id=26843&edit=1
#26843 [Com]: PHP doesn't work...
ID: 26843 Comment by: admin at onet dot pl Reported By: admin at wp dot pl Status: Open Bug Type: *General Issues Operating System: DOS PHP Version: 5CVS-2004-01-08 (dev) New Comment: Yeah, it doesn't work also at my system... Previous Comments: [2004-01-08 08:34:38] admin at wp dot pl Description: I installed PHP but it doesn't work... Reproduce code: --- (null) Expected result: null Actual result: -- (null) -- Edit this bug report at http://bugs.php.net/?id=26843&edit=1
#26843 [NEW]: PHP doesn't work...
From: admin at wp dot pl Operating system: DOS PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: *General Issues Bug description: PHP doesn't work... Description: I installed PHP but it doesn't work... Reproduce code: --- (null) Expected result: null Actual result: -- (null) -- Edit bug report at http://bugs.php.net/?id=26843&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26843&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26843&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26843&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26843&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26843&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26843&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26843&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26843&r=support Expected behavior: http://bugs.php.net/fix.php?id=26843&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26843&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26843&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26843&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26843&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26843&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26843&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26843&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26843&r=float
#26842 [NEW]: localeconv gives wrong decimal place values for locale it_IT
From: marko at oblo dot com Operating system: linux PHP version: 4.3.4 PHP Bug Type: *Languages/Translation Bug description: localeconv gives wrong decimal place values for locale it_IT Description: localeconv() function returns the wrong values for int_frac_digits and frac_digits. they should be "2" and not "0" (which was correct in the time of the Lira) Reproduce code: --- string(1) "." ["int_frac_digits"]=> int(2) ["frac_digits"]=> int(2) ["mon_grouping"]=> array(2) { [0]=> int(3) [1]=> int(3) } } Actual result: -- array(18) { ["decimal_point"]=> string(1) "." ["int_frac_digits"]=> int(0) ["frac_digits"]=> int(0) ["mon_grouping"]=> array(2) { [0]=> int(3) [1]=> int(3) } } -- Edit bug report at http://bugs.php.net/?id=26842&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26842&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26842&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26842&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26842&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26842&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26842&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26842&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26842&r=support Expected behavior: http://bugs.php.net/fix.php?id=26842&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26842&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26842&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26842&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26842&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26842&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26842&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26842&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26842&r=float
#26788 [Com]: Concurrent upload ignored when processing is synchronized
ID: 26788 Comment by: t at t dot org Reported By: d-alvarez at gmx dot de Status: Open Bug Type: *General Issues Operating System: GNU/Linux 2.4.21-144-default PHP Version: 4.3.4 New Comment: Ciao Previous Comments: [2004-01-07 14:37:00] d-alvarez at gmx dot de Apache is version 2.0.48 But I am not sure at all that this bug has to do with apache or php. It could as well be an issue with the internet explorer getting confused about which page the authorization dialog caused by the .htaccess file belongs to. Maybe it posts the file only once in consequence. But this idea would not explain why the second script also fails occassionally. [2004-01-06 17:51:51] [EMAIL PROTECTED] What apache version? [2004-01-04 18:18:40] d-alvarez at gmx dot de Description: Take any html page that uploads a file using HTTP post. It does not matter what the receiving script does, because this issue is only related to the interpreter. A page as simple as the following suffices to reproduce the problem: http://www.somesite.org/somescript.php";> Change the form's action to some script on a php server. I have placed an echo in it, so I can see more easily if the script is run. And, of course, it should use the file posted, so that we can get an error if it does not find it. You can use this: Now use the html page to upload a file sufficiently large enough for the upload to take several seconds to complete. While the data is being submitted, load the script a second time in another instance of your browser, and post the same file again (in parallel to the first post running in the background). I use a file 824 kb in size. Transmitted over ISDN, the two posts take like two minutes of time to complete. The file was a zip archive. Now, while the server is handling the two uploads concurrently, get a listing of the directory it uses to store the temporary files. You can watch the two uploading files growing until both uploads complete. [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 228 -rw---1 wwwrun www114688 2004-01-04 23:09 phpHh9HQ9 -rw---1 wwwrun www110592 2004-01-04 23:09 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 360 -rw---1 wwwrun www180224 2004-01-04 23:10 phpHh9HQ9 -rw---1 wwwrun www180224 2004-01-04 23:10 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 572 -rw---1 wwwrun www299008 2004-01-04 23:10 phpHh9HQ9 -rw---1 wwwrun www278528 2004-01-04 23:10 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 1528 -rw---1 wwwrun www790528 2004-01-04 23:12 phpHh9HQ9 -rw---1 wwwrun www765952 2004-01-04 23:12 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 1664 -rw---1 wwwrun www844067 2004-01-04 23:13 phpHh9HQ9 -rw---1 wwwrun www844067 2004-01-04 23:13 phpp9QIDj Now, with both files being uploaded, two scripts begin to execute, one for each file. Subsequent directory listings will show the temporary files being deleted as the php scripts complete. [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 832 -rw---1 wwwrun www844067 2004-01-04 23:13 phpp9QIDj (first file has been deleted automatically, because script started first has completed processing) [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 0 (second file has been deleted automatically, because script started last has completed processing) This is the situation as it should be. Now place an .htaccess file into a directoy above the directory containing your script. The .htaccess file should usually cause your browser to ask you for some realm and password, and then ask you to commit, e.g. by clicking an OK button. Again, start two posts in parallel, but do not yet commit the authorization dialogue shown to you in response to the .htaccess file. The files are uploaded, probably to some temporary location in memory. While the files get uploaded, get some listings of your temporary directory, as before. Neither the system-global /tmp directory, nor the location used to store temporary php files have any entries, but the line is busy for exactly as much time as during the post when there was no .htaccess file yet. Probably the upload is handled differently by Apache. [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l ~/phptmp insgesamt 0 [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> ls -l /tmp [EMAIL PROTECTED]:~/html/wcopy/datenaustausch> Now confirm the aut
#26841 [NEW]: Child class cannot see protected member var from parent
From: [EMAIL PROTECTED] Operating system: linux PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: Child class cannot see protected member var from parent Description: Hello,.. today I tried the code which I post as reproduce code. I expect in public_func2() the property which is declared as protected in the base class to be visible. However PHP bails out with message : PHP Fatal error: Cannot access protected property base::$a in /home/andrey/test/t.php on line 16 . Use of parent:: does not help also. AFAIK protected member vars should be visible in the generalization classes. As a side note please refer to bug #18024, for an additional effect which can be seen when using the reproduce code - shadowing of the variable declared in the base class. Method public_func1() of the base class uses the variable $a of "child" which is shadowing $a of "base". Is this an expected behaviour? Thanks Reproduce code: --- a); } } class child extends base { public $a = 2; public function public_func2() { var_dump($this->a); var_dump(parent::$a); } } $a = new child(); $a->public_func1(); $a->public_func2(); ?> Expected result: int(2) int(2) array(0) { } Actual result: -- int(2) int(2) PHP Fatal error: Cannot access protected property base::$a in /home/andrey/test/t.php on line 16 -- Edit bug report at http://bugs.php.net/?id=26841&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26841&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26841&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26841&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26841&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26841&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26841&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26841&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26841&r=support Expected behavior: http://bugs.php.net/fix.php?id=26841&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26841&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26841&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26841&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26841&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26841&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26841&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26841&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26841&r=float
#26840 [NEW]: ru.php.net gets row php pages!!!
From: apermyakov at soludium dot com Operating system: Your PHP version: 4.3.4 PHP Bug Type: Unknown/Other Function Bug description: ru.php.net gets row php pages!!! Description: ru.php.net gets row php pages!!! Please, check and fix it, otherwise you are at great risk! http://ru.php.net/FAQ.php section contains links like http://ru.php.net/manual/en/faq.html.php Try them and you will see what i mean. -- Edit bug report at http://bugs.php.net/?id=26840&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26840&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26840&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26840&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26840&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26840&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26840&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26840&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26840&r=support Expected behavior: http://bugs.php.net/fix.php?id=26840&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26840&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26840&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26840&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26840&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26840&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26840&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26840&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26840&r=float
#26839 [NEW]: unexpected results from simple array routine
From: dweller at devonweller dot com Operating system: Linux Intel (Redhat) PHP version: 4.3.4 PHP Bug Type: Arrays related Bug description: unexpected results from simple array routine Description: The attached simple array routine produces unexpected results when the loop count is greater than approx. 33000. Perhaps this is some kind of reference counting bug. Reproduce code: --- // causes unexpected *RECURSION* references $var1 = 1; $array = array(); for($i=0;$i<33000;++$i) { $var2 = $var1; $array[] = array( 'var1' => $var1, 'var2' => $var2, ); } print_r($array[0]); Expected result: Array ( [var1] => 1 [var2] => 1 ) Actual result: -- Array ( [var1] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) [var2] => Array ( [var1] => Array *RECURSION* [var2] => Array *RECURSION* ) ) -- Edit bug report at http://bugs.php.net/?id=26839&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26839&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26839&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26839&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26839&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26839&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26839&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26839&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26839&r=support Expected behavior: http://bugs.php.net/fix.php?id=26839&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26839&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26839&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26839&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26839&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26839&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26839&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26839&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26839&r=float
#26837 [Opn->Bgs]: mhash seems not loading on PHP as ISAPI
ID: 26837 Updated by: [EMAIL PROTECTED] Reported By: webmaster at sparovcek dot net -Status: Open +Status: Bogus Bug Type: mhash related Operating System: Win2k server/IIS5 PHP Version: 4.3.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You were just doing something wrong... Previous Comments: [2004-01-08 04:19:25] webmaster at sparovcek dot net Description: I was trying to install php_mhash.dll with bundled libmhash.dll library on my Windows 2000 server, but it simply did not start! Everytime I called mhash() function, I get error: "Call to undefined function mhash() ..." After some exercise with checking /extensions dir, and PHP.INI, and after I found 0 (ZERO) configuration mistakes (all other extensions and modules loaded with no problem), I did the following: I copied the PHP installation from server to my local machine, and installed it. And mhash() function WORKED WITH NO PROBLEM! Now, where are the diferences? MHASH is NOT WORKING on this machine: - Windows 2000 server - IIS 5 - PHP 4.3.4 loaded as ISAPI MHASH is WORKING on this machine: - Windows XP pro - Apache 1.3.23 - PHP 4.3.4 loaded as CGI/EXE My opinion is that running PHP as ISAPI module has something to do with it. But I did not experiment too much, because I have only *working* server, not for development purposes. -- Edit this bug report at http://bugs.php.net/?id=26837&edit=1
#23220 [Com]: fgets() causes warning while reading data via SSL channel (HTTPS)
ID: 23220 Comment by: a at anseljh dot com Reported By: storozhilov at mail dot ru Status: No Feedback Bug Type: Filesystem function related Operating System: FreeBSD 4.8 PHP Version: 4-STABLE-200307070330 Assigned To: wez New Comment: Red Hat 9 PHP 4.3.4, Apache 2.0.48, OpenSSL 0.9.7c (built from source) Also happens with either fread() or feof() on an SSL socket connection opened with fsockopen ($request): while (!feof($request)) $response .= fread($request, 4096); This code works flawlessly on a non-SSL socket connection. Previous Comments: [2003-12-29 14:31:32] Roger dot Schweppe at cbsks dot com I have been having the same problem with IIS 5. So if you ever find a solution I would be very happy to hear from you. Thanks, Roger [2003-12-23 14:02:46] pta at interkan dot net Forgot to include this info: PHP 4.3.4 (cli) (built: Dec 4 2003 11:17:45) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies [2003-12-23 14:01:39] pta at interkan dot net I've been experiencing the same problem with PHP 4.3.4 running on a Linux Slackware/Apache server. The problem did initially crop up inside the PEAR Socket class which I'm trying to use to connect to Authorize.Net's gateway. Here's the exact message returned (with path changes): Warning: fread(): SSL: fatal protocol error in /path/to/Net/Socket.php on line 243 [2003-12-12 20:59:12] tim at timcrider dot com oh by the way. I am trying this with https:// as wez requested and am reproducing the same error: PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov [2003-12-12 20:54:11] tim at timcrider dot com I am having the same problem on Red Hat 9.0 with PHP 5.0 B2. It's coming from Net/Socket.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/23220 -- Edit this bug report at http://bugs.php.net/?id=23220&edit=1
#26838 [NEW]: signals make STDIN become EOF
From: xuefer at 21cn dot com Operating system: linux PHP version: 4.3.4 PHP Bug Type: Filesystem function related Bug description: signals make STDIN become EOF Description: code shell> ./test.php don't press CTRL+D to end input. but program exists in 3 seconds because feof() return true uncomment line 7 will works ok, exit only when i press CTRL+D Reproduce code: --- file ./test.php: #!/usr/bin/php -- Edit bug report at http://bugs.php.net/?id=26838&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26838&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26838&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26838&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26838&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26838&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26838&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26838&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26838&r=support Expected behavior: http://bugs.php.net/fix.php?id=26838&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26838&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26838&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26838&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26838&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26838&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26838&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26838&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26838&r=float
#26836 [Opn->Fbk]: Unable to load modules / some missing
ID: 26836 Updated by: [EMAIL PROTECTED] Reported By: scottfurry at telusplanet dot net -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Windows NT4 SP6a PHP Version: 5CVS-2004-01-08 (dev) New Comment: Please be more specific; which extensions are you trying to load and which entry point cannot be found? php_gd2.dll is in the ext folder of the zip file. (fetch latest snapshot) Previous Comments: [2004-01-08 03:05:47] scottfurry at telusplanet dot net Description: Unable to load dynamic dll's. PHP.INI file will correctly identify path to php_*.dll. Error message returned by OS that entry point to dll cannot be found. Also, some DLL's appear to be missing? i.e. php_GD.dll / php_GD2.dll -- Edit this bug report at http://bugs.php.net/?id=26836&edit=1
#23508 [Com]: Segmentation fault with data type in mssql
ID: 23508 Comment by: sebastian dot wiehe at qmarketing dot de Reported By: alietss at yahoo dot com Status: No Feedback Bug Type: MSSQL related Operating System: RedHat 9.0 PHP Version: 4CVS-2003-05-06 (stable) New Comment: Anyone found a solution for that prob? I'm having exactly the same problems running mandrake 9.2, freeTDS 0.61, php 4.3.3. By now, I found no one who could deal with this strange behaviour. If you need further information concerning that possible bug, please contact me via email Thanks Previous Comments: [2003-05-14 11:02:54] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-05-06 12:11:02] [EMAIL PROTECTED] Can you provide me with a small code sample to reproduce this error. I think it is a bug in FreeTDS, and would like to trace it. [2003-05-06 11:14:30] alietss at yahoo dot com Hi PHP people: I have found a segmentation fault with httpd-2.0.45 php-4.3.2 freetds-0.62-dev on RedHat 9.0 TDS 7.0 against a Microsoft SQL Server 2000, the problem is when some of the queries field is of type datetime 8... I'm using freetds-0.62-dev with mssql native php extension Here the apache error log... httpd: read.c:365: tds_get_char_data: Assertion `in_left < 4' failed. [Tue May 06 11:05:27 2003] [notice] child pid 9064 exit signal Segmentation fault (11) [Tue May 06 11:05:27 2003] [notice] child pid 9065 exit signal Segmentation fault (11) I report this to freetds people too since I don't know who belongs the problem... Any Ideas, Regards Aliet -- Edit this bug report at http://bugs.php.net/?id=23508&edit=1
#26837 [NEW]: mhash seems not loading on PHP as ISAPI
From: webmaster at sparovcek dot net Operating system: Win2k server/IIS5 PHP version: 4.3.4 PHP Bug Type: mhash related Bug description: mhash seems not loading on PHP as ISAPI Description: I was trying to install php_mhash.dll with bundled libmhash.dll library on my Windows 2000 server, but it simply did not start! Everytime I called mhash() function, I get error: "Call to undefined function mhash() ..." After some exercise with checking /extensions dir, and PHP.INI, and after I found 0 (ZERO) configuration mistakes (all other extensions and modules loaded with no problem), I did the following: I copied the PHP installation from server to my local machine, and installed it. And mhash() function WORKED WITH NO PROBLEM! Now, where are the diferences? MHASH is NOT WORKING on this machine: - Windows 2000 server - IIS 5 - PHP 4.3.4 loaded as ISAPI MHASH is WORKING on this machine: - Windows XP pro - Apache 1.3.23 - PHP 4.3.4 loaded as CGI/EXE My opinion is that running PHP as ISAPI module has something to do with it. But I did not experiment too much, because I have only *working* server, not for development purposes. -- Edit bug report at http://bugs.php.net/?id=26837&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26837&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26837&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26837&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26837&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26837&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26837&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26837&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26837&r=support Expected behavior: http://bugs.php.net/fix.php?id=26837&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26837&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26837&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26837&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26837&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26837&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26837&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26837&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26837&r=float
#26834 [Fbk->Opn]: php-4.3.4-installer.exe fails because iisext.vbs not present
ID: 26834 User updated by: kim at sj dot co dot uk Reported By: kim at sj dot co dot uk -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows XP Professional PHP Version: 4.3.4 New Comment: Yes, PHP now working with IIS on my system after manual install. Bug is just with installer. Previous Comments: [2004-01-07 19:47:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-01-07 19:31:06] kim at sj dot co dot uk Description: Running php-4.3.4-installer.exe fails at a late hurdle, because (afaict) Windows XP Professional runs IIS 5.1, which release appears not to include iisext.vbs. At least, that file is not present anywhere on my system. -- Edit this bug report at http://bugs.php.net/?id=26834&edit=1
#26807 [Csd]: No entry point "GetLongPathNamesA" Kernel32.dll
ID: 26807 User updated by: scottfurry at telusplanet dot net Reported By: scottfurry at telusplanet dot net Status: Closed Bug Type: *Configuration Issues Operating System: Windows NT4 SP6a PHP Version: 5CVS-2004-01-06 (dev) Assigned To: wez New Comment: Apache 2.0.48 will now load PHP correctly. Process was extremely painless. Manual install of PHP similar to "install.txt" was almost exact (exception of path's and names of a couple of dll's). Kudo's on moving php*apache*.dll's to php folder and the file rename. PHP can now be configured on the fly from the PHP.ini file extremely well. Most appreciated, thank you. HOWEVER,... dynamic modules cannot be loaded. See bug #26836 Previous Comments: [2004-01-07 19:54:54] [EMAIL PROTECTED] Fixed about an hour ago when we moved to new win32 build on snaps.php.net. [2004-01-07 19:44:19] [EMAIL PROTECTED] Assigned to Wez who claimed this was fixed in snapshots in bug #26692 [2004-01-06 02:13:27] scottfurry at telusplanet dot net Description: Have tried file renames, latest CVS, moving dll's, etc. (Just about every suggestion I could find on PHP.net) Using Apache 2.0.48 and installing PHP using SAPI *.dll's, I continue to receive "No Entry point to GetLongPathNamesA in kernel32.dll" error message. The LoadModule directive with php5_module did not resolve the issue. Description of problem similar to bugs 26692/24749 but remains unresolved with new/latest CVS. Issue is either... a) problem with Win32 PHP5 build b) missing WinNT4 files not cited in installation instructions c) incompatibility with latest/greatest from Microsoft (note updated NT with MDAC 2.8 prior to install of PHP as directed in the Windows Install instructions) d) missing step in installation instructions (unlikely) but the instructions do not reflect PHP5 Please help!!! -- Edit this bug report at http://bugs.php.net/?id=26807&edit=1
#26836 [NEW]: Unable to load modules / some missing
From: scottfurry at telusplanet dot net Operating system: Windows NT4 SP6a PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: Dynamic loading Bug description: Unable to load modules / some missing Description: Unable to load dynamic dll's. PHP.INI file will correctly identify path to php_*.dll. Error message returned by OS that entry point to dll cannot be found. Also, some DLL's appear to be missing? i.e. php_GD.dll / php_GD2.dll -- Edit bug report at http://bugs.php.net/?id=26836&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26836&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26836&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26836&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26836&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26836&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26836&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26836&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26836&r=support Expected behavior: http://bugs.php.net/fix.php?id=26836&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26836&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26836&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26836&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26836&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26836&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26836&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26836&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26836&r=float