#30776 [NEW]: unreadable answer from parser
From: rob at alterlinks dot fr Operating system: Linux 2.6.3-7 PHP version: 5.0.2 PHP Bug Type: *General Issues Bug description: unreadable answer from parser Description: Please see bug #28243 I know, as reported, it is maybe *not* a bug, one has to use the correct syntax ! But, when using ? unset (variable) ? the parser result : expecting T_PAAMAYIM_NEKUDOTAYIM is not understandable, at least not to me. PHP4 returns an understandble code. Reproduce code: --- ? unset (variable); ? (indeed, the above code is *incorrect*, it's only to provoque de parser's return code) Expected result: Parse error: parse error, unexpected T_STRING, expecting T_VARIABLE or '$' in /var/www/sites/premiere/phpinfo.php on line 2 Actual result: -- Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/sites/bios/phpinfo.php on line 2 -- Edit bug report at http://bugs.php.net/?id=30776edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30776r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30776r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30776r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30776r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30776r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30776r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30776r=needscript Try newer version: http://bugs.php.net/fix.php?id=30776r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30776r=support Expected behavior: http://bugs.php.net/fix.php?id=30776r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30776r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30776r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30776r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30776r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30776r=dst IIS Stability: http://bugs.php.net/fix.php?id=30776r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30776r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30776r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30776r=mysqlcfg
#30776 [Fbk-Opn]: unreadable answer from parser
ID: 30776 User updated by: rob at alterlinks dot fr Reported By: rob at alterlinks dot fr -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.6.3-7 PHP Version: 5.0.2 New Comment: Thanks for your reply. However, can you explain why PHP4 reports a readable error, in relation to the misstake I'm maken, as where PHP5 reports me something in Hebrew while the error I'm making seems to have nothing to do with classes ?? What is the error it reports you for the code below ? ? unset (value); ? Previous Comments: [2004-11-13 21:16:21] [EMAIL PROTECTED] I can't reproduce it. But I'd advise you to read this: http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php [2004-11-13 20:53:32] rob at alterlinks dot fr Description: Please see bug #28243 I know, as reported, it is maybe *not* a bug, one has to use the correct syntax ! But, when using ? unset (variable) ? the parser result : expecting T_PAAMAYIM_NEKUDOTAYIM is not understandable, at least not to me. PHP4 returns an understandble code. Reproduce code: --- ? unset (variable); ? (indeed, the above code is *incorrect*, it's only to provoque de parser's return code) Expected result: Parse error: parse error, unexpected T_STRING, expecting T_VARIABLE or '$' in /var/www/sites/premiere/phpinfo.php on line 2 Actual result: -- Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/sites/bios/phpinfo.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30776edit=1
#30776 [Fbk-Opn]: unreadable answer from parser
ID: 30776 User updated by: rob at alterlinks dot fr Reported By: rob at alterlinks dot fr -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.6.3-7 PHP Version: 5.0.2 New Comment: I'm happy for you, for me it doesn't with PHP 5.0.2. It does with PHP4, not with PHP5.0.2 (the exact same code). Either it's fixed in whatever version you're using, either I can't conclude otherwise than that there is a difference in behaviour between my PHP4 and PHP5.0.2 Anyway, lets forget about it, it's not that big of a deal, I guess I'll just have to go learn Hebrew ;) Previous Comments: [2004-11-13 21:40:38] [EMAIL PROTECTED] It reports exactly what you have expected: Parse error: parse error, unexpected T_VAR, expecting T_STRING or T_VARIABLE or '$' in .. [2004-11-13 21:36:33] rob at alterlinks dot fr Thanks for your reply. However, can you explain why PHP4 reports a readable error, in relation to the misstake I'm maken, as where PHP5 reports me something in Hebrew while the error I'm making seems to have nothing to do with classes ?? What is the error it reports you for the code below ? ? unset (value); ? [2004-11-13 21:16:21] [EMAIL PROTECTED] I can't reproduce it. But I'd advise you to read this: http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php [2004-11-13 20:53:32] rob at alterlinks dot fr Description: Please see bug #28243 I know, as reported, it is maybe *not* a bug, one has to use the correct syntax ! But, when using ? unset (variable) ? the parser result : expecting T_PAAMAYIM_NEKUDOTAYIM is not understandable, at least not to me. PHP4 returns an understandble code. Reproduce code: --- ? unset (variable); ? (indeed, the above code is *incorrect*, it's only to provoque de parser's return code) Expected result: Parse error: parse error, unexpected T_STRING, expecting T_VARIABLE or '$' in /var/www/sites/premiere/phpinfo.php on line 2 Actual result: -- Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/sites/bios/phpinfo.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30776edit=1
#30776 [Bgs]: unreadable answer from parser
ID: 30776 User updated by: rob at alterlinks dot fr Reported By: rob at alterlinks dot fr Status: Bogus Bug Type: *General Issues Operating System: Linux 2.6.3-7 PHP Version: 5.0.2 New Comment: Good evening, I don't like the status bogus; It's maybe not a bug, at least nothing to be really worried about, but if I wouldn't see the result with my own eyes on my screen, I wonder how one can say that there is *no* bug. Would I be able to dream and come up with a word like that ? lol Please see : http://bios.alterlinks.fr/phpinfo.php http://bios.alterlinks.fr/phpinfo2.php and http://premiere.alterlinks.fr/phpinfo.php http://premiere.alterlinks.fr/phpinfo2.php between phpinfo and phpinfo2 the only difference is the line : unset (variable); which has been added. Anyway, just leave the incident closed as it's no big deal, just to show you that I'm not dreaming :) Best regards, Previous Comments: [2004-11-13 21:53:35] [EMAIL PROTECTED] No bug - bogus. [2004-11-13 21:50:56] rob at alterlinks dot fr I'm happy for you, for me it doesn't with PHP 5.0.2. It does with PHP4, not with PHP5.0.2 (the exact same code). Either it's fixed in whatever version you're using, either I can't conclude otherwise than that there is a difference in behaviour between my PHP4 and PHP5.0.2 Anyway, lets forget about it, it's not that big of a deal, I guess I'll just have to go learn Hebrew ;) [2004-11-13 21:40:38] [EMAIL PROTECTED] It reports exactly what you have expected: Parse error: parse error, unexpected T_VAR, expecting T_STRING or T_VARIABLE or '$' in .. [2004-11-13 21:36:33] rob at alterlinks dot fr Thanks for your reply. However, can you explain why PHP4 reports a readable error, in relation to the misstake I'm maken, as where PHP5 reports me something in Hebrew while the error I'm making seems to have nothing to do with classes ?? What is the error it reports you for the code below ? ? unset (value); ? [2004-11-13 21:16:21] [EMAIL PROTECTED] I can't reproduce it. But I'd advise you to read this: http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.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/30776 -- Edit this bug report at http://bugs.php.net/?id=30776edit=1
#29435 [NEW]: Segmentation Fault 11 in strlen()
From: rob at alterlinks dot fr Operating system: Linux Mandrake 2.4.19-16 PHP version: 5.0.0 PHP Bug Type: Reproducible crash Bug description: Segmentation Fault 11 in strlen() Description: Tested with PHP5.0.0 and later Snapshots with Apache 1.3.31 and 2.0.50, systematically a Segmentation Fault 11 (error_log Apache), blank page is shown. OK with PHP4.3.8. Result of debug : [EMAIL PROTECTED] logs]# gdb ../bin/httpd GNU gdb 5.2.1-2mdk (Mandrake Linux) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i586-mandrake-linux-gnu... (gdb) run -X Starting program: /usr/local/free_websites/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40186bc3 in strlen () from /lib/i686/libc.so.6 (gdb) Result of bt #0 0x40186bc3 in strlen () from /lib/i686/libc.so.6 #1 0x40473993 in add_property_string_ex (arg=0x1, key=0x82a4664 \001, key_len=0, str=0x1 Address 0x1 out of bounds, duplicate=135993744) at /download/php5-200407261830/Zend/zend_API.c:1132 #2 0x4032b406 in zif_mysql_fetch_field (ht=1, return_value=0x82a4664, this_ptr=0x0, return_value_used=1) at /download/php5-200407261830/ext/mysql/php_mysql.c:2250 #3 0x40497feb in zend_do_fcall_common_helper (execute_data=0xbfffd280, opline=0x820b7dc, op_array=0x824cd28) at /download/php5-200407261830/Zend/zend_execute.c:2699 #4 0x40498760 in zend_do_fcall_handler (execute_data=0xbfffd280, opline=0x820b7dc, op_array=0x824cd28) at /download/php5-200407261830/Zend/zend_execute.c:2831 #5 0x4049460c in execute (op_array=0x824cd28) at /download/php5-200407261830/Zend/zend_execute.c:1391 #6 0x40498184 in zend_do_fcall_common_helper (execute_data=0xbfffd350, opline=0x4088fb70, op_array=0x829207c) at /download/php5-200407261830/Zend/zend_execute.c:2728 #7 0x40498652 in zend_do_fcall_by_name_handler (execute_data=0xbfffd350, opline=0x4088fb70, op_array=0x829207c) at /download/php5-200407261830/Zend/zend_execute.c:2813 #8 0x4049460c in execute (op_array=0x829207c) at /download/php5-200407261830/Zend/zend_execute.c:1391 #9 0x40470841 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /download/php5-200407261830/Zend/zend.c:1068 #10 0x404295b2 in php_execute_script (primary_file=0xb600) at /download/php5-200407261830/main/main.c:1631 #11 0x404a149e in php_handler (r=0x842ab78) at /download/php5-200407261830/sapi/apache2handler/sapi_apache2.c:535 #12 0x0807e18b in ap_run_handler (r=0x842ab78) at config.c:152 #13 0x0807e72e in ap_invoke_handler (r=0x6) at config.c:358 #14 0x0806d1fb in ap_process_request (r=0x842ab78) at http_request.c:246 #15 0x08068fef in ap_process_http_connection (c=0x81f2058) at http_core.c:250 #16 0x08087e2b in ap_run_process_connection (c=0x81f2058) at connection.c:42 #17 0x0807cbf1 in child_main (child_num_arg=4) at prefork.c:609 #18 0x0807cdad in make_child (s=0x80bb120, slot=0) at prefork.c:649 #19 0x0807ce0e in startup_children (number_to_start=5) at prefork.c:721 #20 0x0807d553 in ap_mpm_run (_pconf=0x80b89f0, plog=0x80f0ad0, s=0x80b69e8) at prefork.c:940 #21 0x0808299a in main (argc=2, argv=0xb994) at main.c:617 #22 0x4012a082 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) Reproduce code: --- phpMyAdmin script, page sql.php Expected result: Display of contents of Database tables Actual result: -- Segmentation Fault 11 (no coredump), see gdb results (bt) -- Edit bug report at http://bugs.php.net/?id=29435edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29435r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29435r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29435r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29435r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29435r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29435r=needscript Try newer version: http://bugs.php.net/fix.php?id=29435r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29435r=support Expected behavior: http://bugs.php.net/fix.php?id=29435r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29435r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29435r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29435r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29435r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29435r=dst IIS Stability: http://bugs.php.net/fix.php?id=29435r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29435r=gnused
#23963 [NEW]: option --with-cybermut= in configure, but not taken into account
From: rob at alterlinks dot fr Operating system: Linux Mandrake 8.1 PHP version: 4.3.2 PHP Bug Type: *E-commerce functions Bug description: option --with-cybermut= in configure, but not taken into account As the previous version 4.2.3 (which worked), I've compiled 4.3.2 with the following options : ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --with-cybermut=/usr/local/bank --with-zlib-dir=/usr/local/lib --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/lib --with-zlib --with-gd --with-openssl --with-gdbm-dir=/usr/local/lib --with-dbm-dir=/usr/lib --with-gdbm --with-dbm --enable-ftp --enable-bcmath --enable-calendar --enable-shared --disable-static --with-freetype-dir=./freetype After restarting Apache : Fatal error: Call to undefined function: cybermut_creerformulairecm() in /var/www/awsales/french/tothebank.php on line 128 I've restored the backup of libphp4.so from the 4.2.3 version to get the function to work again. -- Edit bug report at http://bugs.php.net/?id=23963edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23963r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23963r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23963r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23963r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23963r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=23963r=support Expected behavior: http://bugs.php.net/fix.php?id=23963r=notwrong Not enough info:http://bugs.php.net/fix.php?id=23963r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=23963r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23963r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23963r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23963r=dst IIS Stability: http://bugs.php.net/fix.php?id=23963r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=23963r=gnused
