#20203 [Opn]: odbc_do() or odbc_exec() Always produces a segmentation fault core dump
ID: 20203 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: sparc solaris 2.8 and 2.6 PHP Version: 4.2.3 New Comment: at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1274 1274convert_to_string_ex(pv_query); (gdb) n 1277result = (odbc_result *)emalloc(sizeof(odbc_result)); (gdb) display result 1: result = (odbc_result *) 0x1b4a88 (gdb) display result.stmt 2: result.stmt = 0x1b9da8 (gdb) display /s result.stmt 3: x/s result.stmt 0x1b9da8:"select * from kan_keim" At this point the query statment is correct But just before producing the fault is the following : 1305if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TY PE, SQL_CURSOR_DYNAMIC) 5: /u rc = 16 4: rc = 16 3: x/s result.stmt 0x1c5148:"" 2: result.stmt = 0x1c5148 1: result = (odbc_result *) 0x1b9dd8 (gdb) s Program received signal SIGSEGV, Segmentation fault. 0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so I hope this helps you Best regards Christos Previous Comments: [2002-11-01 09:32:49] [EMAIL PROTECTED] display query display result->stmt [2002-11-01 06:16:39] [EMAIL PROTECTED] Please i am not too familiar with gdb can you tell me how I can print query and result->stmt variables in step #10 ? Bets regards Christos [2002-10-31 19:45:27] [EMAIL PROTECTED] Also can you please turn on SQL Logging so we can see which steps are being processed. From the looks of it the SQLExtendedFetch is catching an error condition or possibly a need to re-allocate data and refetch furth of data. I find it hard to believe that the odbc_exect (a very basic part of any DB layer) isn't working with MSSQL. What are the types of data you're trying to extract? [2002-10-31 19:31:52] [EMAIL PROTECTED] On step #10 could you print the values of: query and result->stmt [2002-10-31 17:32:40] [EMAIL PROTECTED] The result is the same after using the latest cvs and here is the output of gdb 5.0 (and the trace back) : ** gdb output * Program received signal SIGSEGV, Segmentation fault. 0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so (gdb) bt #0 0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #1 0xfeff6560 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #2 0xfefcc418 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #3 0xfefc76a0 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #4 0xfefc5af0 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #5 0xfefb3584 in SQLNumResultCols () from /usr/local/odbc/lib/sql_st_lt.so #6 0xfefac7d0 in SQLError () from /usr/local/odbc/lib/sql_st_lt.so #7 0xfef97d54 in SQLDriverConnect () from /usr/local/odbc/lib/sql_st_lt.so #8 0xfefac89c in SQLExecDirect () from /usr/local/odbc/lib/sql_st_lt.so #9 0xff35e72c in SQLExecDirect () from /usr/local/odbc/lib/libiodbc.so.2 #10 0x4c76c in zif_odbc_exec (ht=1811184, return_value=0x1b4760, this_ptr=0x0, return_value_used=1) at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1318 #11 0x10a9e0 in execute (op_array=0x1b6110) at /usr/pkg/php/php4-200210311500/Zend/zend_execute.c:1595 #12 0xfdb60 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/pkg/php/php4-200210311500/Zend/zend.c:839 #13 0xd699c in php_execute_script (primary_file=0xffbefaf0) at /usr/pkg/php/php4-200210311500/main/main.c:1541 #14 0x10ef8c in main (argc=2, argv=0xffbefb7c) at /usr/pkg/php/php4-200210311500/sapi/cli/php_cli.c:695 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/20203 -- Edit this bug report at http://bugs.php.net/?id=20203&edit=1
#20218 [NEW]: Apache segfaults when using horde/imp
From: [EMAIL PROTECTED] Operating system: Redhat Linux 7.3 kernel 2.4.18 PHP version: 4.3.0-pre2 PHP Bug Type: Apache2 related Bug description: Apache segfaults when using horde/imp I installed apache 2.0.43 and php 4.3.0-pre2 and i get segfaults after login in imp (horde 2.1 + imp 3.1). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 22742)] zend_hash_get_current_data_ex (ht=0x83fcf1c, pData=0xbffe8ec8, pos=0xbffe8ecc) at /usr/src/php-4.3.0pre2/Zend/zend_hash.c:1101 1101*pData = p->pData; (gdb) (gdb) bt #0 zend_hash_get_current_data_ex (ht=0x83fcf1c, pData=0xbffe8ec8, pos=0xbffe8ecc) at /usr/src/php-4.3.0pre2/Zend/zend_hash.c:1101 #1 0x40256730 in php_implode (delim=0x83ec6f4, arr=0x83ec6f4, return_value=0x83ed144) at /usr/src/php-4.3.0pre2/ext/standard/string.c:830 #2 0x40256a27 in zif_implode (ht=2, return_value=0x83ed144, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.0pre2/ext/standard/string.c:886 #3 0x402ce080 in execute (op_array=0x83f18ac) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1595 #4 0x402ce23e in execute (op_array=0x827ec74) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #5 0x402ce23e in execute (op_array=0x827f00c) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #6 0x402ce23e in execute (op_array=0x834215c) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #7 0x402bbbe4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-4.3.0pre2/Zend/zend.c:839 #8 0x40296111 in php_execute_script (primary_file=0xb7d0) at /usr/src/php-4.3.0pre2/main/main.c:1542 #9 0x402d5eae in php_output_filter (f=0x8267d08, bb=0x8268b78) at /usr/src/php-4.3.0pre2/sapi/apache2filter/sapi_apache2.c:458 #10 0x080acdd0 in ap_pass_brigade (next=0x8267d08, bb=0x8267e50) at util_filter.c:540 #11 0x080b3eec in default_handler (r=0x82660b0) at core.c:3320 #12 0x080a09fc in ap_run_handler (r=0x82660b0) at config.c:194 #13 0x080a0ffe in ap_invoke_handler (r=0x82660b0) at config.c:401 #14 0x0807794c in ap_process_request (r=0x82660b0) at http_request.c:288 #15 0x08073164 in ap_process_http_connection (c=0x8259eb8) at http_core.c:293 #16 0x080aa984 in ap_run_process_connection (c=0x8259eb8) at connection.c:85 #17 0x080aac6f in ap_process_connection (c=0x8259eb8, csd=0x8259de8) at connection.c:207 #18 0x0809f39b in child_main (child_num_arg=0) at prefork.c:696 #19 0x0809f45d in make_child (s=0x80e9878, slot=0) at prefork.c:736 #20 0x0809f56b in startup_children (number_to_start=5) at prefork.c:808 #21 0x0809f941 in ap_mpm_run (_pconf=0x80e5cd0, plog=0x812bde8, s=0x80e9878) at prefork.c:1024 #22 0x080a5698 in main (argc=4, argv=0xbb64) at main.c:643 #23 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 My configure line: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --enable-magic-quotes \ --enable-dbase \ --enable-ftp \ --with-gettext \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --enable-mime-magic \ --with-mysql \ --with-mm \ --enable-sockets \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm Thanks. -- Edit bug report at http://bugs.php.net/?id=20218&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20218&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20218&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20218&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20218&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20218&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20218&r=support Expected behavior: http://bugs.php.net/fix.php?id=20218&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20218&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20218&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20218&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20218&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20218&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20218&r=isapi
#20218 [Opn->Fbk]: Apache segfaults when using horde/imp
ID: 20218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Redhat Linux 7.3 kernel 2.4.18 PHP Version: 4.3.0-pre2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-11-02 07:30:34] [EMAIL PROTECTED] I installed apache 2.0.43 and php 4.3.0-pre2 and i get segfaults after login in imp (horde 2.1 + imp 3.1). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 22742)] zend_hash_get_current_data_ex (ht=0x83fcf1c, pData=0xbffe8ec8, pos=0xbffe8ecc) at /usr/src/php-4.3.0pre2/Zend/zend_hash.c:1101 1101*pData = p->pData; (gdb) (gdb) bt #0 zend_hash_get_current_data_ex (ht=0x83fcf1c, pData=0xbffe8ec8, pos=0xbffe8ecc) at /usr/src/php-4.3.0pre2/Zend/zend_hash.c:1101 #1 0x40256730 in php_implode (delim=0x83ec6f4, arr=0x83ec6f4, return_value=0x83ed144) at /usr/src/php-4.3.0pre2/ext/standard/string.c:830 #2 0x40256a27 in zif_implode (ht=2, return_value=0x83ed144, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.0pre2/ext/standard/string.c:886 #3 0x402ce080 in execute (op_array=0x83f18ac) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1595 #4 0x402ce23e in execute (op_array=0x827ec74) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #5 0x402ce23e in execute (op_array=0x827f00c) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #6 0x402ce23e in execute (op_array=0x834215c) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #7 0x402bbbe4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-4.3.0pre2/Zend/zend.c:839 #8 0x40296111 in php_execute_script (primary_file=0xb7d0) at /usr/src/php-4.3.0pre2/main/main.c:1542 #9 0x402d5eae in php_output_filter (f=0x8267d08, bb=0x8268b78) at /usr/src/php-4.3.0pre2/sapi/apache2filter/sapi_apache2.c:458 #10 0x080acdd0 in ap_pass_brigade (next=0x8267d08, bb=0x8267e50) at util_filter.c:540 #11 0x080b3eec in default_handler (r=0x82660b0) at core.c:3320 #12 0x080a09fc in ap_run_handler (r=0x82660b0) at config.c:194 #13 0x080a0ffe in ap_invoke_handler (r=0x82660b0) at config.c:401 #14 0x0807794c in ap_process_request (r=0x82660b0) at http_request.c:288 #15 0x08073164 in ap_process_http_connection (c=0x8259eb8) at http_core.c:293 #16 0x080aa984 in ap_run_process_connection (c=0x8259eb8) at connection.c:85 #17 0x080aac6f in ap_process_connection (c=0x8259eb8, csd=0x8259de8) at connection.c:207 #18 0x0809f39b in child_main (child_num_arg=0) at prefork.c:696 #19 0x0809f45d in make_child (s=0x80e9878, slot=0) at prefork.c:736 #20 0x0809f56b in startup_children (number_to_start=5) at prefork.c:808 #21 0x0809f941 in ap_mpm_run (_pconf=0x80e5cd0, plog=0x812bde8, s=0x80e9878) at prefork.c:1024 #22 0x080a5698 in main (argc=4, argv=0xbb64) at main.c:643 #23 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 My configure line: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --enable-magic-quotes \ --enable-dbase \ --enable-ftp \ --with-gettext \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --enable-mime-magic \ --with-mysql \ --with-mm \ --enable-sockets \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm Thanks. -- Edit this bug report at http://bugs.php.net/?id=20218&edit=1
#20218 [Fbk->Csd]: Apache segfaults when using horde/imp
ID: 20218 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: Redhat Linux 7.3 kernel 2.4.18 PHP Version: 4.3.0-pre2 New Comment: Works OK with the lastest CVS. Thanks. Previous Comments: [2002-11-02 07:36:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-02 07:30:34] [EMAIL PROTECTED] I installed apache 2.0.43 and php 4.3.0-pre2 and i get segfaults after login in imp (horde 2.1 + imp 3.1). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 22742)] zend_hash_get_current_data_ex (ht=0x83fcf1c, pData=0xbffe8ec8, pos=0xbffe8ecc) at /usr/src/php-4.3.0pre2/Zend/zend_hash.c:1101 1101*pData = p->pData; (gdb) (gdb) bt #0 zend_hash_get_current_data_ex (ht=0x83fcf1c, pData=0xbffe8ec8, pos=0xbffe8ecc) at /usr/src/php-4.3.0pre2/Zend/zend_hash.c:1101 #1 0x40256730 in php_implode (delim=0x83ec6f4, arr=0x83ec6f4, return_value=0x83ed144) at /usr/src/php-4.3.0pre2/ext/standard/string.c:830 #2 0x40256a27 in zif_implode (ht=2, return_value=0x83ed144, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.0pre2/ext/standard/string.c:886 #3 0x402ce080 in execute (op_array=0x83f18ac) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1595 #4 0x402ce23e in execute (op_array=0x827ec74) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #5 0x402ce23e in execute (op_array=0x827f00c) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #6 0x402ce23e in execute (op_array=0x834215c) at /usr/src/php-4.3.0pre2/Zend/zend_execute.c:1639 #7 0x402bbbe4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-4.3.0pre2/Zend/zend.c:839 #8 0x40296111 in php_execute_script (primary_file=0xb7d0) at /usr/src/php-4.3.0pre2/main/main.c:1542 #9 0x402d5eae in php_output_filter (f=0x8267d08, bb=0x8268b78) at /usr/src/php-4.3.0pre2/sapi/apache2filter/sapi_apache2.c:458 #10 0x080acdd0 in ap_pass_brigade (next=0x8267d08, bb=0x8267e50) at util_filter.c:540 #11 0x080b3eec in default_handler (r=0x82660b0) at core.c:3320 #12 0x080a09fc in ap_run_handler (r=0x82660b0) at config.c:194 #13 0x080a0ffe in ap_invoke_handler (r=0x82660b0) at config.c:401 #14 0x0807794c in ap_process_request (r=0x82660b0) at http_request.c:288 #15 0x08073164 in ap_process_http_connection (c=0x8259eb8) at http_core.c:293 #16 0x080aa984 in ap_run_process_connection (c=0x8259eb8) at connection.c:85 #17 0x080aac6f in ap_process_connection (c=0x8259eb8, csd=0x8259de8) at connection.c:207 #18 0x0809f39b in child_main (child_num_arg=0) at prefork.c:696 #19 0x0809f45d in make_child (s=0x80e9878, slot=0) at prefork.c:736 #20 0x0809f56b in startup_children (number_to_start=5) at prefork.c:808 #21 0x0809f941 in ap_mpm_run (_pconf=0x80e5cd0, plog=0x812bde8, s=0x80e9878) at prefork.c:1024 #22 0x080a5698 in main (argc=4, argv=0xbb64) at main.c:643 #23 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 My configure line: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --enable-magic-quotes \ --enable-dbase \ --enable-ftp \ --with-gettext \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --enable-mime-magic \ --with-mysql \ --with-mm \ --enable-sockets \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm Thanks. -- Edit this bug report at http://bugs.php.net/?id=20218&edit=1
#20219 [NEW]: Socket dies if there's too much incoming data
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.1 PHP Bug Type: Sockets related Bug description: Socket dies if there's too much incoming data I'm working on a script to administrate half-life servers. When I try to dump a rules list, which consists of more then approx. 80 rules ( 1 Rule = 2 strings of about 20 and 3 chars ), the PHP script dies and waits forever. The same problem when I do a players dump and there are more than 16 players on a server. The fsockopen() and socket-functions don't seem too reliable, is there any possibility that this will change in the next versions? -- Edit bug report at http://bugs.php.net/?id=20219&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20219&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20219&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20219&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20219&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20219&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20219&r=support Expected behavior: http://bugs.php.net/fix.php?id=20219&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20219&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20219&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20219&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20219&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20219&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20219&r=isapi
#20219 [Opn->Bgs]: Socket dies if there's too much incoming data
ID: 20219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: Linux PHP Version: 4.2.1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Please supply a complete snippet with which we can reproduce the bug. Previous Comments: [2002-11-02 10:20:37] [EMAIL PROTECTED] I'm working on a script to administrate half-life servers. When I try to dump a rules list, which consists of more then approx. 80 rules ( 1 Rule = 2 strings of about 20 and 3 chars ), the PHP script dies and waits forever. The same problem when I do a players dump and there are more than 16 players on a server. The fsockopen() and socket-functions don't seem too reliable, is there any possibility that this will change in the next versions? -- Edit this bug report at http://bugs.php.net/?id=20219&edit=1
#20219 [Bgs->Opn]: Socket dies if there's too much incoming data
ID: 20219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Sockets related Operating System: Linux PHP Version: 4.2.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Are your sockets using the sockets extension, or the native fsockopen calls? We can't really help unless you supply us with a self-contained script that illustrates the problem. Please try a snapshot (for the up and coming 4.3 release), and if you still experience problems, post a script that we can use to find out the cause. Previous Comments: [2002-11-02 10:29:13] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Please supply a complete snippet with which we can reproduce the bug. [2002-11-02 10:20:37] [EMAIL PROTECTED] I'm working on a script to administrate half-life servers. When I try to dump a rules list, which consists of more then approx. 80 rules ( 1 Rule = 2 strings of about 20 and 3 chars ), the PHP script dies and waits forever. The same problem when I do a players dump and there are more than 16 players on a server. The fsockopen() and socket-functions don't seem too reliable, is there any possibility that this will change in the next versions? -- Edit this bug report at http://bugs.php.net/?id=20219&edit=1
#20219 [Opn->Fbk]: Socket dies if there's too much incoming data
ID: 20219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Linux PHP Version: 4.2.1 Previous Comments: [2002-11-02 10:30:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Are your sockets using the sockets extension, or the native fsockopen calls? We can't really help unless you supply us with a self-contained script that illustrates the problem. Please try a snapshot (for the up and coming 4.3 release), and if you still experience problems, post a script that we can use to find out the cause. [2002-11-02 10:29:13] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Please supply a complete snippet with which we can reproduce the bug. [2002-11-02 10:20:37] [EMAIL PROTECTED] I'm working on a script to administrate half-life servers. When I try to dump a rules list, which consists of more then approx. 80 rules ( 1 Rule = 2 strings of about 20 and 3 chars ), the PHP script dies and waits forever. The same problem when I do a players dump and there are more than 16 players on a server. The fsockopen() and socket-functions don't seem too reliable, is there any possibility that this will change in the next versions? -- Edit this bug report at http://bugs.php.net/?id=20219&edit=1
#20018 [Opn->Fbk]: empty($this->property) always returns TRUE inside class method
ID: 20018
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: OS X 10.1
PHP Version: 4CVS-2002-10-21
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Previous Comments:
[2002-10-21 23:28:49] [EMAIL PROTECTED]
empty() seems to always return TRUE when testing an object
property from inside a method of the object. it works OK
on regular variables, or when testing the property externally.
test code:
x = NULL;
print "this->x={$this->x}\n";
print "is this->x empty? ".(empty($this->x) ? "yes" :
"no")."\n";
$this->x = 'i am not empty';
print "this->x={$this->x}\n";
print "is this->x empty? ".(empty($this->x) ? "yes" :
"no")."\n";
$x = NULL;
print "x={$x}\n";
print "is x empty? ".(empty($x) ? "yes" : "no")."\n";
$x = 'i am not empty';
print "x={$x}\n";
print "is x empty? ".(empty($x) ? "yes" : "no")."\n";
}
}
$x = new test;
?>
output:
this->x=
is this->x empty? yes
this->x=i am not empty
is this->x empty? yes
x=
is x empty? yes
x=i am not empty
is x empty? no
--
Edit this bug report at http://bugs.php.net/?id=20018&edit=1
#19092 [Com]: Cannot load php_xslt.dll
ID: 19092 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: XSLT related Operating System: Windows ME PHP Version: 4.2.2 New Comment: well i need the following *.dlls to reomve that error: SABLOT.DLL MPR.DLL Previous Comments: [2002-08-30 18:08:13] [EMAIL PROTECTED] That is not "exactly as documented" as the installation instructions for PHP 4.2.2 says that the loadable extensions can reside in a folder other than the system folder, and the example given (indeed the one created when in installation file is unzipped) is one called /php/extensions. That is what I used without error until I tried to enable the xslt module. [2002-08-30 17:37:53] [EMAIL PROTECTED] Exactly as documented. User error => Bogus [2002-08-30 17:33:17] [EMAIL PROTECTED] SOLVED!! I originally had all the PHP .dll files in the /php/extensions folder, and everything ran from there without a problem. It was when I tried to enable the php_xslt.dll that I started getting error messages about "unable to load dynamic library...". I checked it with Dependency Walker and this showed that two dll files were missing. It was suggested that I move all the dlls into the c:\windows\system folder, which I did, but when I checked with Dependency Walker the errors were still there. Because of the errors I did not try to run PHP with the xslt module enabled. But just today I enabled it so that I could check the error message again, but it did not appear! This seems strange because Dependency Walker will show the same errors whether the file is in the /php/extensions folder or the windows/system folder, but putting everything in the windows/system folder will NOT produce a runtime error. I can now access the xslt module, so this problem is now closed. Thanks for your efforts. [2002-08-28 17:33:14] [EMAIL PROTECTED] I have tried putting all the php*.dlls in the c:\windows\system folder as well as in the \php\extensions folder with exactly the same result. [2002-08-28 17:27:04] [EMAIL PROTECTED] You never answered my question wheather you have copied all the dlls from dlls folder of the php distro into your c:\windows\system folder? 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/19092 -- Edit this bug report at http://bugs.php.net/?id=19092&edit=1
#20220 [NEW]: Problem with apache 2.0.43
From: [EMAIL PROTECTED] Operating system: win2kserver PHP version: 4.3.0-pre2 PHP Bug Type: Apache2 related Bug description: Problem with apache 2.0.43 Because problem between apache 2.0.43 and PHP 4.2.3, i download the last version from CVS but i have some apache unpredictable restart. I install the same configuration with apache 1.3.27 and it works fine. -- Edit bug report at http://bugs.php.net/?id=20220&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20220&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20220&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20220&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20220&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20220&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20220&r=support Expected behavior: http://bugs.php.net/fix.php?id=20220&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20220&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20220&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20220&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20220&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20220&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20220&r=isapi
#20220 [Opn->Bgs]: Problem with apache 2.0.43
ID: 20220 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: win2kserver PHP Version: 4.3.0-pre2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2002-11-02 12:54:26] [EMAIL PROTECTED] Because problem between apache 2.0.43 and PHP 4.2.3, i download the last version from CVS but i have some apache unpredictable restart. I install the same configuration with apache 1.3.27 and it works fine. -- Edit this bug report at http://bugs.php.net/?id=20220&edit=1
#20221 [NEW]: str_replace
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Strings related Bug description: str_replace str_replace when used with with arrays, for every element in the search/replace arrays a simple replace in the source string (rather than using an external string) is performed. This causes an unexpected result like if one of the replace values includes a search value it will be replaced in a subsequent replacing action. If this is a feature rather than a bug (which I doubt) please state it in the documentation. An example: $vSearch[] = '@gill'; $vSearch[] = '@doubleyou'; $vReplace[] = '@doubleyou'; $vReplace[] = '@bates'; $sSubject = "@gill is my friend"; $sResult = str_replace($vSearch, $vReplace, $sSubject); echo $sResult; // will output "@bates is not my friend" instead // of "@doubleyou is not my friend" Best regards, Eugen Fernea IT Manager Panacode Software rue de la Station, 1/1 7090 Braine-Le-Comte Belgium E-mail: [EMAIL PROTECTED] Phone: +32 067/48 58 94 Mobile: +32 (0)472 95 15 48 Web: http://www.panacode.com -- Edit bug report at http://bugs.php.net/?id=20221&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20221&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20221&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20221&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20221&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20221&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20221&r=support Expected behavior: http://bugs.php.net/fix.php?id=20221&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20221&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20221&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20221&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20221&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20221&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20221&r=isapi
#20222 [NEW]: mssql_free_result():
From: [EMAIL PROTECTED] Operating system: win 2k server SBS PHP version: 4.2.3 PHP Bug Type: MSSQL related Bug description: mssql_free_result(): I 've got this warning for a query that works, I don't understand why. PHP Warning: mssql_free_result(): 18 is not a valid MS SQL-result resource in ... here the code: $strSQL = " SELECT REF_PRODUIT FROM PRODUITS WHERE ACTUEL = 1 AND REF_EDITEUR = '$pEditeur' AND REF_PRODUIT ='".$tabCol[0]."'"; $iQuery2 = dbQuery($iConnect, $strSQL) ; echo $iQuery2; dbFetch($iQuery2, $tabref); dbFreeResult($iQuery2); here the echo of iQuery2: Resource id #9 Resource id #12 Resource id #15 Resource id #18 -- Edit bug report at http://bugs.php.net/?id=20222&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20222&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20222&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20222&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20222&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20222&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20222&r=support Expected behavior: http://bugs.php.net/fix.php?id=20222&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20222&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20222&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20222&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20222&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20222&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20222&r=isapi
#20220 [Bgs->Opn]: Problem with apache 2.0.43
ID: 20220 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: win2kserver PHP Version: 4.3.0-pre2 New Comment: hum i can't explain more you can go to my own site http://manoo.dyndns.org and see that now it work fine when you choose any options in the menu. I use now apache 1.3.27. I used apache 2.0.39 for a few month and i have no problems too with the same PHP scripts. But when i want to use apache 2.0.43, i had problem with php4apache2.dll file. Like it was reported here, i download the latest version of PHP from CVS. It resolved my problem with this file but activate unpredictable restart of apache when i choose option menu on my site. it answered that the page did not exist, but if you update the page with the same URL just after the bug, it showed the page. in the error.log file from apache i have this trace : [Sat Nov 02 12:08:02 2002] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Nov 02 12:08:02 2002] [notice] Parent: Created child process 6200 [Sat Nov 02 12:08:03 2002] [notice] Child 6200: Child process is running [Sat Nov 02 12:08:04 2002] [notice] Child 6200: Acquired the start mutex. [Sat Nov 02 12:08:04 2002] [notice] Child 6200: Starting 250 worker threads. because i have no more the binaries of apache 2.0.39 and the php4apache2.dll which works with, i install apache 1.3.27 and all works fine now with no restart of apache when i choose option menu. Sorry for my poor english. Previous Comments: [2002-11-02 12:55:12] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-11-02 12:54:26] [EMAIL PROTECTED] Because problem between apache 2.0.43 and PHP 4.2.3, i download the last version from CVS but i have some apache unpredictable restart. I install the same configuration with apache 1.3.27 and it works fine. -- Edit this bug report at http://bugs.php.net/?id=20220&edit=1
#20109 [Opn->Ctl]: iplanet 6 core dump w/NSAPI load
ID: 20109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 4CVS-2002-10-26 New Comment: As much as I don't like nsapi, we can't have it not working for 4.3.0 release... since it has historically worked (sometimes). Previous Comments: [2002-10-27 08:49:16] [EMAIL PROTECTED] Tried php4-200210262100, same crash, same backtrace. Crash: [27/Oct/2002:09:45:07] catastrophe (29972): Server crash detected (signal SIGBUS) [27/Oct/2002:09:45:07] info (29972): Crash occurred in NSAPI SAF php4_execute [27/Oct/2002:09:45:07] info (29972): Crash occurred in function php_register_variable_ex from module /usr/iplanet/servers/bin/libphp4.so [27/Oct/2002:09:45:12] failure (29957): Child process admin thread is shutting down Backtrace: #0 0xfe629ccc in php_register_variable_ex (var=0xfe6c05c0 "REQUEST_LINE", val=0xfda5f6b8, track_vars_array=0xfe6c05c0, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:176 #1 0xfe62988c in php_register_variable_safe (var=0xfe6c05c0 "REQUEST_LINE", strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", str_len=25, track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:56 #2 0xfe6297a4 in php_register_variable (var=0xfe6c05c0 "REQUEST_LINE", strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:37 #3 0xfe678e10 in sapi_nsapi_register_server_variables ( track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:290 #4 0xfe61e7b4 in php_hash_environment (tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/main.c:1220 #5 0xfe61d278 in php_request_startup (tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/main.c:857 #6 0xfe679590 in nsapi_module_main (request_context=0xc72d60, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:460 #7 0xfe679768 in php4_execute (pb=0xc3f88, sn=0xc36a48, rq=0xc36a90) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:525 #8 0xff1d89b4 in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #9 0xff1d9cf8 in INTobject_execute () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #10 0xff1dd8e8 in INTservact_service () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #11 0xff1dde84 in INTservact_handle_processed () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #12 0xff215c0c in __0fLHttpRequestUUnacceleratedRespondPCcTBPc () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #13 0xff2150c0 in __0fLHttpRequestNHandleRequestP6Gnetbuf () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #14 0xff213388 in __0fNDaemonSessionDrunv () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #15 0xff163b80 in ThreadMain () from /usr/iplanet/servers/bin/https/lib/libnsprwrap.so #16 0xfede76a0 in _pt_root () from /usr/iplanet/servers/bin/https/lib/libnspr4.so [2002-10-26 17:01:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip I've just commited a patch to the CVS that may address the problem you are seeing. [2002-10-26 15:19:19] [EMAIL PROTECTED] Recompiled with the latest snap (php4-200210261200) and with Forte 7 compilers (previous was with gcc 2.95.3) . Similar crash, here is the dbx backtrace: t@18 (l@18) terminated by signal SEGV (no mapping at the fault address) 0xfd8f6834: DumpThreads+0x000c: ldub[%o0 + 0x38], %o0 Current function is php_register_variable 37 php_register_variable_safe(var, strval, strlen(strval), track_vars_array TSRMLS_CC); (dbx) where current thread: t@18 [1] DumpThreads(0x0, 0x587040, 0x17c, 0xfdbd4de4, 0xfdb89080, 0x0), at 0xfd8f6834 [2] panicHandler(0xfeb3e194, 0xfdc5f610, 0x2000, 0x1b852000, 0xb, 0xfdbd5000), at 0xfd9afe98 [3] __sighndlr(0xb, 0xfdc5f610, 0xfdc5f358, 0xfd9ae7a0, 0x0, 0x0), at 0xfebb60a0 [4] call_user_handler(0xb, 0xfdc5f610, 0xfdc5f358, 0x0, 0x0, 0x0), at 0xfebafdd8 [5] sigacthandler(0xb, 0xfdc5f610, 0xfdc5f358, 0x7efefeff, 0x81010100, 0xfdc5ec88), at 0xfebaff88 called from signal handler with signal 11 (SIGSEGV) -- [6] strlen(0x0, 0x0, 0x36c, 0x7efefeff, 0x81010100, 0xfdc5ec88), at 0xfeab2ea8 =>[7] php_register_variable(var = 0xfe3e1b94 "SERVER_NAME", strval = (nil), track
#20148 [Opn->Csd]: The document contains no data....
ID: 20148
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Java related
Operating System: Linux (Mandrake 8.2)
PHP Version: 4.2.3
New Comment:
Symbolic link issue is already in another bug, but I've added a comment
in the java readme for now. Thanks for taking the time to help.
Previous Comments:
[2002-10-30 03:45:29] [EMAIL PROTECTED]
I found the problem ...
In fact there was 2 problems !
1) The first was with the library path
When I put in the php.ini file the command 'java.library =
/path/to/libjvm.so' it solve the prompt on screen saying that the
library couldn't be found.. But If you look apache execution with gdb,
you see apache crashing anyway, with the error 'libjvm.so can not be
found' !!
So, I add in my /etc/ld.so.conf file the 2 lines
"/usr/java/j2sdk1.4.1/jre/lib/i386/" and
"/usr/java/j2sdk1.4.1/jre/lib/i386/server/" but after a ldconfig, I saw
that the "/usr/java/j2sdk1.4.1/jre/lib/i386/" did not work.
I think this is a problem with my OS. Peraps because the last folder
ends with a number, I don't know. But If I create a folder
"/usr/java/j2sdk1.4.1/jre/lib/i386/test" and add it to the
'ld.so.conf', it works !!! (I copied libraries '/i386/*.so' into
before...)
The cleanest solution was to define
"LD_LIBRARY_PATH=/usr/java/j2sdk1.4.1/jre/lib/i386/:/usr/java/j2sdk1.4.1/jre/lib/i386/server/"
and in this case, it works !! (without the created 'test' folder)
That's strange...
2) My second problem was with the 'java.so' file.
I had to create a symbolic link to it with the name 'libphp_java.so'
because the JVM crashed if not.
And that's all !!
I think this kind of information (like the symbolic link for exemple)
should be present in the ext/java/README file, because the
documentation online is not detailed enought.
thank you, and good luck for solving bugs... Java and php are realy
great langages. I would be fine that they perfectly work together ;-)
Fred
[2002-10-29 08:34:04] [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.
[2002-10-29 08:06:46] [EMAIL PROTECTED]
here is my problem
When I try to create a new java object, or when I call a java related
php function (like 'java_last_exception_get()') I get the message
'Document contains no data' in my browser.
here is my test file
yes
getProperty('java.version').' ';
print 'Java vendor=' .$system->getProperty('java.vendor').' ';
print 'OS='.$system->getProperty('os.name').' '.
$system->getProperty('os.version').' on '.
$system->getProperty('os.arch').' ';
// java.util.Date example
$formatter = new Java('java.text.SimpleDateFormat',
", dd, 'at' h:mm:ss a ");
print $formatter->format(new Java('java.util.Date'));
?>
here is my config options
./configure \
--prefix=/usr/local/php4 \
--with-apxs2=/usr/local/apache-2.0.43/bin/apxs \
--with-regex=system \
--enable-inline-optimization \
--enable-debug=yes \
--enable-ftp \
--with-mysql \
--with-java=/usr/java/j2sdk1.4.1 \
--with-sybase=/usr/local/freetds \
--enable-sysvshm \
--enable-sysvsem
here is my php.ini [java] section
[java]
; java.home = /usr/java/j2sdk1.4.1
java.class.path=/usr/local/php4/lib/php/php_java.jar:/home/fred/java/travail/class
; java.library=/usr/java/j2sdk1.4.1/jre/lib/i386/server/libjvm.so
extension_dir=/usr/local/php4/lib/php/extensions/debug-zts-20020429
extension=java.so
here is my 'error.log' file
[Tue Oct 29 14:21:12 2002] [notice] caught SIGTERM, shutting down
[Tue Oct 29 14:30:48 2002] [notice] Apache/2.0.43 (Unix) PHP/4.2.3
configured -- resuming normal operations
[Tue Oct 29 14:31:04 2002] [notice] child pid 29488 exit signal
Segmentation fault (11)
[Tue Oct 29 14:31:04 2002] [notice] child pid 29487 exit signal
Segmentation fault (11)
[Tue Oct 29 14:31:04 2002] [notice] child pid 29486 exit signal
Segmentation fault (11)
[Tue Oct 29 14:31:04 2002] [notice] child pid 29485 exit signal
Segmentation fault (11)
[Tue Oct 29 14:31:04 2002] [notice] child pid 29484 exit signal
Segmentation fault (11)
[Tue Oct 29 14:31:04 2002] [notice] child pid 29483 exit signal
Segmentation fault (11)
[Tue Oct 29 14:31:05 2002] [notice] child pid 29489 exi
#20203 [Opn->Fbk]: odbc_do() or odbc_exec() Always produces a segmentation fault core dump
ID: 20203 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: sparc solaris 2.8 and 2.6 PHP Version: 4.2.3 New Comment: I'd still appriciate the SQL Log :) Previous Comments: [2002-11-02 07:26:43] [EMAIL PROTECTED] at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1274 1274convert_to_string_ex(pv_query); (gdb) n 1277result = (odbc_result *)emalloc(sizeof(odbc_result)); (gdb) display result 1: result = (odbc_result *) 0x1b4a88 (gdb) display result.stmt 2: result.stmt = 0x1b9da8 (gdb) display /s result.stmt 3: x/s result.stmt 0x1b9da8:"select * from kan_keim" At this point the query statment is correct But just before producing the fault is the following : 1305if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TY PE, SQL_CURSOR_DYNAMIC) 5: /u rc = 16 4: rc = 16 3: x/s result.stmt 0x1c5148:"" 2: result.stmt = 0x1c5148 1: result = (odbc_result *) 0x1b9dd8 (gdb) s Program received signal SIGSEGV, Segmentation fault. 0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so I hope this helps you Best regards Christos [2002-11-01 09:32:49] [EMAIL PROTECTED] display query display result->stmt [2002-11-01 06:16:39] [EMAIL PROTECTED] Please i am not too familiar with gdb can you tell me how I can print query and result->stmt variables in step #10 ? Bets regards Christos [2002-10-31 19:45:27] [EMAIL PROTECTED] Also can you please turn on SQL Logging so we can see which steps are being processed. From the looks of it the SQLExtendedFetch is catching an error condition or possibly a need to re-allocate data and refetch furth of data. I find it hard to believe that the odbc_exect (a very basic part of any DB layer) isn't working with MSSQL. What are the types of data you're trying to extract? [2002-10-31 19:31:52] [EMAIL PROTECTED] On step #10 could you print the values of: query and result->stmt 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/20203 -- Edit this bug report at http://bugs.php.net/?id=20203&edit=1
#20221 [Opn->Fbk]: str_replace
ID: 20221 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Strings related Operating System: Linux PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-11-02 13:04:24] [EMAIL PROTECTED] str_replace when used with with arrays, for every element in the search/replace arrays a simple replace in the source string (rather than using an external string) is performed. This causes an unexpected result like if one of the replace values includes a search value it will be replaced in a subsequent replacing action. If this is a feature rather than a bug (which I doubt) please state it in the documentation. An example: $vSearch[] = '@gill'; $vSearch[] = '@doubleyou'; $vReplace[] = '@doubleyou'; $vReplace[] = '@bates'; $sSubject = "@gill is my friend"; $sResult = str_replace($vSearch, $vReplace, $sSubject); echo $sResult; // will output "@bates is not my friend" instead // of "@doubleyou is not my friend" Best regards, Eugen Fernea IT Manager Panacode Software rue de la Station, 1/1 7090 Braine-Le-Comte Belgium E-mail: [EMAIL PROTECTED] Phone: +32 067/48 58 94 Mobile: +32 (0)472 95 15 48 Web: http://www.panacode.com -- Edit this bug report at http://bugs.php.net/?id=20221&edit=1
#17424 [NoF->Csd]: Apache sends HTTP 500, but still sends PHP HTML without error
ID: 17424 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: Apache related Operating System: Windows NT 4.0 SP6a + Fixes PHP Version: 4.2.1 New Comment: This behaviour has been fixed in 4.2.3. Previous Comments: [2002-10-25 01:00:10] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-10-09 11:27:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-26 15:16:39] [EMAIL PROTECTED] This phenomenon may be directly related to bug #19113 (http://bugs.php.net/19113). [2002-06-11 09:02:29] [EMAIL PROTECTED] A similar problem occurs on Win98 SE with Apache 1.3.24 and PHP 4.2.1 (binary zip dist.) with default configurations: any scripts, even empty ones () fail with error 500 when the URL has a "?" at the end, with or without any actual GET parameters; once failed, the script will fail with every consequent call even without the query part (browser caching disabled - IE6). Apache error log has no sign of this, access log looks as if nothing went wrong (ie, the expected page content IS sent). Scripts with phpinfo() work fine. Besides, when I add phpinfo() to a failing script and reload the page, then remove it and reload again, everything works properly, but only until I change the query part, then it fails again. Sometimes PHP scripts with only HTML code in them also behave like this, sometimes not, but each particular script is persistant in its behavior. PHP 4.1 has no trouble with this. [2002-05-25 01:43:59] [EMAIL PROTECTED] Setup: * Windows NT SP6a with all the fixins' and none of the fat (No IIS, etc). * Apache 1.3.23, PHP as a module. Mostly default php.ini settings. Using the zip binary. I upgraded from PHP 4.1.1 to 4.2.0 on my site and immediately ran into problems with users of WebTV and other unreported browsers saying they could not access the site. Using Ethereal, I discovered that Apache was sending "500 Internal Server Error" along with the rest of the headers versus a HTTP 200, but was **STILL** sending the PHP generated HTML. There is no error reported in the Apache error log (the access log was too large to analyze on the server, and probably only says it served a "500" anyway) or any other clues in the HTTP headers. A typical page that generates this error would contain the following: ... some HTML here ... Internet Explorer 5.5 SP2 and Netscape 4.78 appear to ignore the HTTP 500 message and pretend nothing happened. I'll see if I can get back with some more stats. (As a totally unrelated side note, the Microsoft SQL DLL is broken in the v4.1.0< win32 binary dist. Its build 'signature' doesn't match and the main PHP DLL detects, complains, and disables it.) -- Edit this bug report at http://bugs.php.net/?id=17424&edit=1
#20222 [Opn->Bgs]: mssql_free_result():
ID: 20222 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: win 2k server SBS PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Can you give us the full error message as well? Previous Comments: [2002-11-02 13:46:05] [EMAIL PROTECTED] I 've got this warning for a query that works, I don't understand why. PHP Warning: mssql_free_result(): 18 is not a valid MS SQL-result resource in ... here the code: $strSQL = " SELECT REF_PRODUIT FROM PRODUITS WHERE ACTUEL = 1 AND REF_EDITEUR = '$pEditeur' AND REF_PRODUIT ='".$tabCol[0]."'"; $iQuery2 = dbQuery($iConnect, $strSQL) ; echo $iQuery2; dbFetch($iQuery2, $tabref); dbFreeResult($iQuery2); here the echo of iQuery2: Resource id #9 Resource id #12 Resource id #15 Resource id #18 -- Edit this bug report at http://bugs.php.net/?id=20222&edit=1
#20190 [Opn->Ctl]: Random mem corruption: zend_get_executed_filename() mismatch
ID: 20190
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Critical
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.3.0-dev
New Comment:
I'd like to jump this upto a critical standing. Mainly because it will
get someone else to review the patch. Hopefully that someone else will
be a bit more intimately knowledgable with the whole Zend memory system
than I.
Previous Comments:
[2002-11-01 08:22:04] [EMAIL PROTECTED]
My patch explained a bit more ...
The main trick is that we do a stat() on
$path:
if (( stat (path, &statbuf)) < 0) {
If the file does not exist, we can be sure that we triggered the bug
and we let the check pass.
As already said, this is only a workaround for the ugly
bug ...
Martin
[2002-10-31 18:06:01] [EMAIL PROTECTED]
hi all,
I think I can now even provide more information ... :-)
$path beeing wrong does relate from a wrong include_path.
It looks like if the apache child has proceeded a request
from a webserver with include_path or safe_mode_include_dir
set, these are still there. If now a virtual server without
these admin values is called, we fail.
Looks to me like these variables are not properly initialized and still
contain their old values.
Of course the openbasedir checks then against the wrong
include path and there we are :-(
I'll look if I can really find the bug and fix it.
Martin
[2002-10-31 17:09:40] [EMAIL PROTECTED]
I have tried to do workarounds earlier.
But it seems that this one here now has solved both issues,
the wrong random "basedir message" and the segfaults I encountered with
my first two patches.
http://people.freebsd.org/~mbr/patches/patch-main+fopen_wrappers.c
The solution is quite easy. In the onyl case where the error happens,
zend_get_executed_filename() is correct.
and can be used.
Since the error happens on perfect legitimate requests,
which work most of the time, I don't think this is a
security risk. If no executed filename is set, I set
$newpath to a empty string.
Note that this is a workaround only. And I print
the errors to syslog, since I can watch that easier.
[2002-10-31 16:34:24] [EMAIL PROTECTED]
It looks to me that $path is composed somewhere.
And a the old basedir entry was not overwritten
correctly.
So $path is $basedir + $called phpfile and
the $basedir is plain wrong.
Some hint where this happens ?
[2002-10-31 16:24:52] [EMAIL PROTECTED]
Sorry ...
>There is no "/www/doc/www.bbb.imp.ch-80/html/visions/php"
>exists, but this is a different customer.
This should be:
There is a dir "/www/doc/www.bbb.imp.ch-80 ..."
but this is a different customer.
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/20190
--
Edit this bug report at http://bugs.php.net/?id=20190&edit=1
#19349 [Opn->Fbk]: odbc_longreadlen() does not work
ID: 19349 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.2.1 New Comment: can you please provide the full script sample for this? I think I do see what is wrong, but want to make sure. Previous Comments: [2002-09-11 10:27:31] [EMAIL PROTECTED] I have a script that runs a select statement from a 10MB CLOB field (among others). I run the following : odbc_longreadlen($resultid, 300); Then I run: $document = odbc_result($resultid, 2); The problem is, $document ends up with 4096 bytes of data (the default, NOT 300). If I edit php.ini and set up odbc_lrl to 200 in there, then $document ends up with 2MBin it. It acts like the function odbc_longreadlen does not work at all. I don't know how much more information I can give other than odbc_longreadlen does not seem to do anything at all. [2002-09-11 09:49:21] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-09-10 20:33:11] [EMAIL PROTECTED] I am using PHP with ODBC (IBM DB2) support and since upgrading to 4.2.1 from 4.0.4pl1, my odbc_longreadlen() function no longer works. I have to set it in the configuration file now, as that is the only place that it works properly. In addition, when it's set above 200 in the config file, httpd starts taking 75% of the CPU (system, not user) and the data never gets to PHP. Am I hitting some type of limitation? How else do I get my 10MB CLOB out of DB2? -- Edit this bug report at http://bugs.php.net/?id=19349&edit=1
#20217 [Opn->Csd]: .htaccess config settings ignored
ID: 20217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache2 related Operating System: RH Linux 7.3 PHP Version: 4.3.0-pre2 New Comment: 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. Previous Comments: [2002-11-01 23:49:24] [EMAIL PROTECTED] Hi there, This is something I believe I've encountered before (having briefly installed an earlier 4.3.0 snapshot) and now just stumbled over again after upgrading from 4.2.3 to 4.3.0pre2 under Apache2 on Linux. (It may have been the reason I dropped back to 4.2.3 then, IIRC.) Basically, I'm noticing that a significant number of PHP configuration settings in my .htaccess file(s) are being ignored entirely -- settings that worked fine under 4.2.3 (and earlier) and which have remained unmodified. This problem may very well be related to bug #17234. Given this .htaccess snippet: php_flag register_globals off php_flag log_errors on php_flag display_errors on php_flag display_startup_errors on php_flag session.use_trans_sid off php_value include_path ".:/var/www/site/_include" php_value auto_prepend_file "global.php" php_value error_log "/var/www/site/_log/php_error_log.txt" I've determined that only log_errors, display_errors, display_startup_errors, include_path, and error_log are accepted -- the rest are ignored as if they were not specified at all (but can be set in php.ini). A brief test also showed that asp_tags and short_open_tag (as in bug #17234) were ignored in htaccess too. I don't think I'm doing anything wrong, but any suggestions as to a workaround are greatly appreciated -- I depend on these htaccess overrides (particularly auto_prepend_file) and can't move to 4.3.x until they're working flawlessly (in a backward-compatible way with 4.0.x+)... Thanks! -- Edit this bug report at http://bugs.php.net/?id=20217&edit=1
#15702 [NoF->Opn]: Segmentation fault (using jdk1.4 with php 4.2.3)
ID: 15702 User updated by: [EMAIL PROTECTED] -Summary: Segmentation fault (using jdk1.4 with php 4.1.1) & libphp_java.so not created Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Java related Operating System: Red Hat Linux 7.1 -PHP Version: 4.1.1 +PHP Version: 4.2.3 New Comment: I used php 4.2.3 this time with apache 2.0.43 Apache -- ./configure --prefix=/wwwroot --enable-so php /configure --prefix=/wwwroot/php --with-apxs2=/wwwroot/bin/apxs --with-java --with-mysql --with-config-file-path=/wwwroot/php export LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client php.ini Setting --- [Java] java.class.path = /wwwroot/php/lib/php/php_java.jar extension=java.so java.home = /usr/java/j2sdk1.4.0 java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/libjava.so ;java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/client/libjvm.so ;java.library.path = /usr/java/j2sdk1.4.0/jre/lib/i386/client Apache Start $ export LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client $ /wwwroot/bin/apachectl start Fatal error: java.lang.UnsatisfiedLinkError: no php_java in java.library.path in /wwwroot/htdocs/jver.php on line 4 Then I changed java setting in php.ini like this: [Java] java.class.path = /wwwroot/php/lib/php/php_java.jar extension=java.so java.library.path = /wwwroot/php/lib/php But same error was displayed. Fatal error: java.lang.UnsatisfiedLinkError: no php_java in java.library.path in /wwwroot/htdocs/jver.php on line 4 I also want to know what has to be specified in java.library.path? In php.ini I also tried to use java.library.path=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client But it was unable to find other java libraries and this error was displayed: Fatal error: Unable to load Java Library /usr/java/j2sdk1.4.0/./jre/lib/i386/libjava.so, error: libverify.so: cannot load shared object file: No such file or directory in /wwwroot/htdocs/jver.php on line 4 So I had to mannual export LD_LIBRARY_PATH as above and then it displayed the unsatisfied link error. Previous Comments: [2002-10-31 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-10-15 22:38:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip And use MINIMUM amount of configure options when you test it. [2002-10-15 11:24:28] [EMAIL PROTECTED] I think you have not read it properly. My first comment was related apache 1.3.23 Yes this happens with all versions of apache only when using any jdk other later than 1.2.2. [2002-09-09 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-08-08 10:14:53] [EMAIL PROTECTED] 1) Can you please try not using Apache2, it's support is not stable with PHP. 2) Does this happen with the PHP 4.2.x and Apache1.XX releases? 3) Can you please please please please please please please please try making your configure script the bare minimum for these tests? It helps us to determine where things are going wrong. 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/15702 -- Edit this bug report at http://bugs.php.net/?id=15702&edit=1
#20221 [Fbk->Opn]: str_replace
ID: 20221 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Strings related Operating System: Linux PHP Version: 4.2.3 New Comment: Sorry for bothering (and for my writing errors). There actually is another function in PHP that has the behaviour that I expect: strtr(str, arr) $vReplace['@gill'] = '@doubleyou'; $vReplace['@doubleyou'] = '@bates'; $sSubject = "@gill @doubleyou is not my friend"; $sResult = strtr($sSubject, $vReplace); echo $sResult; // will output "@doubleyou @bates is not my friend" Previous Comments: [2002-11-02 14:22:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-02 13:04:24] [EMAIL PROTECTED] str_replace when used with with arrays, for every element in the search/replace arrays a simple replace in the source string (rather than using an external string) is performed. This causes an unexpected result like if one of the replace values includes a search value it will be replaced in a subsequent replacing action. If this is a feature rather than a bug (which I doubt) please state it in the documentation. An example: $vSearch[] = '@gill'; $vSearch[] = '@doubleyou'; $vReplace[] = '@doubleyou'; $vReplace[] = '@bates'; $sSubject = "@gill is my friend"; $sResult = str_replace($vSearch, $vReplace, $sSubject); echo $sResult; // will output "@bates is not my friend" instead // of "@doubleyou is not my friend" Best regards, Eugen Fernea IT Manager Panacode Software rue de la Station, 1/1 7090 Braine-Le-Comte Belgium E-mail: [EMAIL PROTECTED] Phone: +32 067/48 58 94 Mobile: +32 (0)472 95 15 48 Web: http://www.panacode.com -- Edit this bug report at http://bugs.php.net/?id=20221&edit=1
#20221 [Opn->Bgs]: str_replace
ID: 20221 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Linux PHP Version: 4.2.3 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: [2002-11-02 17:43:08] [EMAIL PROTECTED] Sorry for bothering (and for my writing errors). There actually is another function in PHP that has the behaviour that I expect: strtr(str, arr) $vReplace['@gill'] = '@doubleyou'; $vReplace['@doubleyou'] = '@bates'; $sSubject = "@gill @doubleyou is not my friend"; $sResult = strtr($sSubject, $vReplace); echo $sResult; // will output "@doubleyou @bates is not my friend" [2002-11-02 14:22:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-02 13:04:24] [EMAIL PROTECTED] str_replace when used with with arrays, for every element in the search/replace arrays a simple replace in the source string (rather than using an external string) is performed. This causes an unexpected result like if one of the replace values includes a search value it will be replaced in a subsequent replacing action. If this is a feature rather than a bug (which I doubt) please state it in the documentation. An example: $vSearch[] = '@gill'; $vSearch[] = '@doubleyou'; $vReplace[] = '@doubleyou'; $vReplace[] = '@bates'; $sSubject = "@gill is my friend"; $sResult = str_replace($vSearch, $vReplace, $sSubject); echo $sResult; // will output "@bates is not my friend" instead // of "@doubleyou is not my friend" Best regards, Eugen Fernea IT Manager Panacode Software rue de la Station, 1/1 7090 Braine-Le-Comte Belgium E-mail: [EMAIL PROTECTED] Phone: +32 067/48 58 94 Mobile: +32 (0)472 95 15 48 Web: http://www.panacode.com -- Edit this bug report at http://bugs.php.net/?id=20221&edit=1
#20223 [NEW]: PHP-CLI '-r' Switch Broken
From: [EMAIL PROTECTED] Operating system: Windows Me PHP version: 4.3.0-pre2 PHP Bug Type: Unknown/Other Function Bug description: PHP-CLI '-r' Switch Broken PHP 4.2.3, 4.3.0pre1, and 4.3.0pre2 all fail to parse the '-r' option when used with CLI (php-cli.exe on 4.2.3, and php.exe on the others). C:\WINDOWS\DESKTOP\php-4.3.0pre2-Win32>php -r 'phpinfo();' PHP Parse Error: parse error, unexpected $ in Command line code on line 1 -- Edit bug report at http://bugs.php.net/?id=20223&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20223&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20223&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20223&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20223&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20223&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20223&r=support Expected behavior: http://bugs.php.net/fix.php?id=20223&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20223&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20223&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20223&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20223&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20223&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20223&r=isapi
#20224 [NEW]: Constants / Global variables non printable
From: [EMAIL PROTECTED]
Operating system: Slackware Linux Kernel 2.4.5
PHP version: 4.2.2
PHP Bug Type: Output Control
Bug description: Constants / Global variables non printable
I'm not sure if this is a problem with constants and pre-registered
globals, or the printing mechanism.
When setting up a constant such as this:
define("SELF", $SCRIPT_NAME);
and then printing with any of the following:
echo SELF;
print(SELF);
pritnf("%s", SELF);
The output is nothing, however, if I do this:
printf("%s", SELF . "?foo=bar");
it will print properly.
I believe it's a problem with the globals, as when I try just to print
$SCRIPT_NAME or $SCRIPT_FILENAME I go no output unless I concat'ed it to
something else such as shown above.
My PHP configuration is as such:
'./configure' '--with-apxs=/usr/sbin/apxs' '--disable-short-tags'
'--enable-bcmath' '--with-zlib-dir=/usr/lib' '--enable-ftp'
'--with-gd=/usr/local/gd-1.8.4' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--enable-sockets'
'--without-mysql' '--with-pgsql=/usr/local/pgsql'
On Slackware (8.0) Linux, Kernel 2.4.5, Apache 1.3.20. For this particular
script, I was working with sessions, and DID use the following lines to
disable some sessions settings:
ini_set("session.use_cookies", 0);
ini_set("session.use_trans_sid", 0);
The script was written prior to 4.2.2 and the auto enabled trans_sid was
creating extra data in my GET's that I had already accounted for in my own
script.
-Richard
--
Edit bug report at http://bugs.php.net/?id=20224&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20224&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20224&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20224&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20224&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20224&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20224&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20224&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20224&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20224&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20224&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20224&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20224&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20224&r=isapi
#17826 [Com]: PHP 4.2.1 Apache SAPI is not compatible with Apache 2.0.39
ID: 17826 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.2.1 Assigned To: edink New Comment: I have a question for the comment by: [23 Oct 8:52pm] [EMAIL PROTECTED] You omit the following line in your httpd.conf: AddModule mod_php4.c So how is the mod_php4.c module being loaded? This is the error if AddModule is used: C:\Apache2043\bin>apache -t Syntax error on line 976 of C:/Apache2043/conf/httpd.conf: Invalid command 'AddModule', perhaps mis-spelled or defined by a module not included in the server configuration Thank you Previous Comments: [2002-10-23 20:52:41] [EMAIL PROTECTED] If you're getting "Cannot load C:/php4/sapi/php4apache2.dll into server: The specified module could not be found." or "apache: module "c:\php4build\snap\sapi\apache2filter\sapi_apache2.c" is not compatible with this version of Apache (found 20020628, need 20020903)." I got it working and this is everything I did: 1. Download: a. Apache: apache_2.0.43-win32-x86-no_ssl.msi b. PHP: php-4.2.3-Win32.zip c. Latest PHP Snap: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 2. Install a. apache b. PHP (by upzipping and renaming dir to "c:\php" 2. Copy c:\php\php.ini-recommended to c:\windows\php.ini 3. Edit c:\php.ini -doc_root = [current apache doc root] -extension_dir = C:\php\extensions 4. Copy c:\php\php4ts.dll to c:\winnt\system32\ 4. Copy php4apache2.dll from the c. Snap zip file to c:\php\sapi\ 6. Edit Apache's configuration file and add: LoadModule php4_module c:/php/sapi/php4apache2.dll AddType application/x-httpd-php .php [2002-10-12 04:43:08] [EMAIL PROTECTED] I confirm that Apache 2.0.43 and latest PHP4 php4apache2.dll works perfectly. However, I haven't heard about php4ts.dll ? What for is that ? P.S. getting Tomcat 4.11 + Apache 2.0.43 + MySQL + PHP4 working together seems to be even more painfull that getting Apache 2 and PHP4 working together : ) Jari [2002-10-11 14:17:54] [EMAIL PROTECTED] The problem with this message: "Cannot load C:/php4/sapi/php4apache2.dll into server: The specified module could not be found." Should be addressed as: 1. Install PHP/Apache 2. Copy required files from c:\php\dlls\ to c:\winnt\system32\ 3. Grab the latest php snapSnap (http://snaps.php.net/win32/) 4. Copy php4apache2.dll from the snap to c:php\sapi\ 5. Copy php4ts.dll from the snap c:winnt\system32 6. Edit Apache's configuration file and add: LoadModule php4_module c:/php/sapi/php4apache2.dll AddType application/x-httpd-php .php .phtml That's it (probably many are just missing the php4ts.dll part) [2002-10-11 08:37:20] [EMAIL PROTECTED] PHP will work with whatever is current Apache version at the time of its release. Newer versions of Apache2 often break backwards compatibility so php4apache2.dll will not work with them. So either use the version of Apache that is supported by that PHP release, or use (almost) always current snapshot from http://snaps.php.net/win32/ [2002-10-11 07:01:27] [EMAIL PROTECTED] Thank you for all the Help Its working perfect with the php4apache2.dll from the Prerelease PHP Version 4.2.4 from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip But it take alot of time to find this Bugreport. If you would add a little link from the Downloadpage of PHP to this Page, it would help many scared php-newbies like me ;) Thanks for all the help Chojin 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/17826 -- Edit this bug report at http://bugs.php.net/?id=17826&edit=1
#20224 [Opn->Bgs]: Constants / Global variables non printable
ID: 20224
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Slackware Linux Kernel 2.4.5
PHP Version: 4.2.2
New Comment:
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
Previous Comments:
[2002-11-02 20:12:20] [EMAIL PROTECTED]
I'm not sure if this is a problem with constants and pre-registered
globals, or the printing mechanism.
When setting up a constant such as this:
define("SELF", $SCRIPT_NAME);
and then printing with any of the following:
echo SELF;
print(SELF);
pritnf("%s", SELF);
The output is nothing, however, if I do this:
printf("%s", SELF . "?foo=bar");
it will print properly.
I believe it's a problem with the globals, as when I try just to print
$SCRIPT_NAME or $SCRIPT_FILENAME I go no output unless I concat'ed it
to something else such as shown above.
My PHP configuration is as such:
'./configure' '--with-apxs=/usr/sbin/apxs' '--disable-short-tags'
'--enable-bcmath' '--with-zlib-dir=/usr/lib' '--enable-ftp'
'--with-gd=/usr/local/gd-1.8.4' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--enable-sockets'
'--without-mysql' '--with-pgsql=/usr/local/pgsql'
On Slackware (8.0) Linux, Kernel 2.4.5, Apache 1.3.20. For this
particular script, I was working with sessions, and DID use the
following lines to disable some sessions settings:
ini_set("session.use_cookies", 0);
ini_set("session.use_trans_sid", 0);
The script was written prior to 4.2.2 and the auto enabled trans_sid
was creating extra data in my GET's that I had already accounted for in
my own script.
-Richard
--
Edit this bug report at http://bugs.php.net/?id=20224&edit=1
#20223 [Opn->Bgs]: PHP-CLI '-r' Switch Broken
ID: 20223 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows Me PHP Version: 4.3.0-pre2 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. On windows you need to quote the arguments using " not '. Previous Comments: [2002-11-02 18:42:38] [EMAIL PROTECTED] PHP 4.2.3, 4.3.0pre1, and 4.3.0pre2 all fail to parse the '-r' option when used with CLI (php-cli.exe on 4.2.3, and php.exe on the others). C:\WINDOWS\DESKTOP\php-4.3.0pre2-Win32>php -r 'phpinfo();' PHP Parse Error: parse error, unexpected $ in Command line code on line 1 -- Edit this bug report at http://bugs.php.net/?id=20223&edit=1
#20018 [Fbk->Csd]: empty($this->property) always returns TRUE inside class method
ID: 20018
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: OS X 10.1
PHP Version: 4CVS-2002-10-21
New Comment:
Fixed in latest CVS release.
Previous Comments:
[2002-11-02 11:00:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-10-21 23:28:49] [EMAIL PROTECTED]
empty() seems to always return TRUE when testing an object
property from inside a method of the object. it works OK
on regular variables, or when testing the property externally.
test code:
x = NULL;
print "this->x={$this->x}\n";
print "is this->x empty? ".(empty($this->x) ? "yes" :
"no")."\n";
$this->x = 'i am not empty';
print "this->x={$this->x}\n";
print "is this->x empty? ".(empty($this->x) ? "yes" :
"no")."\n";
$x = NULL;
print "x={$x}\n";
print "is x empty? ".(empty($x) ? "yes" : "no")."\n";
$x = 'i am not empty';
print "x={$x}\n";
print "is x empty? ".(empty($x) ? "yes" : "no")."\n";
}
}
$x = new test;
?>
output:
this->x=
is this->x empty? yes
this->x=i am not empty
is this->x empty? yes
x=
is x empty? yes
x=i am not empty
is x empty? no
--
Edit this bug report at http://bugs.php.net/?id=20018&edit=1
#19317 [Fbk->NoF]: cosmetic problem on line 308 in var_unserializer.c
ID: 19317 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: RedHat Linux 7.3 PHP Version: 4.2.3, 4.3.0-dev New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-15 23:42:05] [EMAIL PROTECTED] Please add the error here which you got with latest CVS snapshot and GCC 3.2 when the compile failed. [2002-10-15 15:21:05] [EMAIL PROTECTED] I've just compiled latest CVS using gcc 3.2. It compiled just fine, gave me the same warnings as gcc 2.95.3 gave. If it fails to compile the problem is likely to be else where. The configure line used was: ./configure --disable-all --enable-debug The warnings are certainly something to be fixed, but this is hardly a 'critical' bug. [2002-10-12 09:59:36] [EMAIL PROTECTED] Furthermore, this breaks build with gcc-3.2, so I don't think it is so smart to keep ignoring this. [2002-09-09 10:14:08] [EMAIL PROTECTED] There is a comparison (yych <= '\277') on line 308 in file /ext/standard/var_unserializer.c, which is never true (appeared first in "1.6.2.1 by stas"). I suppose that "goto yy15;" is correct, but the comparison is not OK. -- Edit this bug report at http://bugs.php.net/?id=19317&edit=1
#19892 [Fbk->NoF]: Images would not display.
ID: 19892 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: FreeBSD 4.7 PHP Version: 4.3.0-pre1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-18 08:56:39] [EMAIL PROTECTED] 1st try the latest CVS (unstable) to make sure that the problem still exists. If it does, then in your follow-up report please include all the lines pertaining to PHP configuration from your httpd.conf [2002-10-18 00:10:27] [EMAIL PROTECTED] Reopening. [2002-10-18 00:09:58] [EMAIL PROTECTED] Ah, but it is. It only happened when I installed PHP 4.3.0-pre1. Apache worked just fine running PHP 4.2.3, but not 4.3.0-pre1. All images used to display, and they did not with the 4.3.0 version. It's not a config problem, because the config did not change, just the php version. [2002-10-17 18:00:09] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [2002-10-17 17:59:56] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Using the information you've provided I cannot replicate the bug. Unless you tell Apache to parse image files this will not happen. This looks a misconfiguration issue on your end rather then a PHP problem. If you are not using the latest Apache try upgrading, also try using the latest PHP (unstable) snapshot. 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/19892 -- Edit this bug report at http://bugs.php.net/?id=19892&edit=1
