#33915 [Asn]: Crash in _oci_close_session
ID: 33915 User updated by: jfbustarret at tf1 dot fr Reported By: jfbustarret at tf1 dot fr Status: Assigned Bug Type: OCI8 related Operating System: Linux PHP Version: 5CVS-2005-08-02 Assigned To: tony2001 New Comment: This new patch should be better : diff -u php-5.0.4-orig/ext/oci8/oci8.c php -5.0.4/ext/oci8/oci8.c --- php-5.0.4-orig/ext/oci8/oci8.c2005-07-27 20:24:40.0 +0 200 +++ php-5.0.4/ext/oci8/oci8.c 2005-08-02 09:33:55.0 +0200 @@ -2941,7 +2941,7 @@ oci_debug("START _oci_close_session: logging-off sess=%d",session->num); - if (session->is_open) { + if (session->pEnv && session->is_open) { /* Temporary Service Context */ CALL_OCI_RETURN(OCI(error), OCIHandleAlloc( @@ -3032,12 +3032,13 @@ #ifdef HAVE_OCI_9_2 /* free environment handle (and fix bug #29652 with growing .msb FD numb er under weirdie Solarises) */ - CALL_OCI( - OCIHandleFree( - (dvoid *) session->pEnv, - OCI_HTYPE_ENV - ) - ); + if (session->pEnv) + CALL_OCI( + OCIHandleFree( + (dvoid *) session->pEnv, + OCI_HTYPE_ENV + ) + ); #endif if (session->exclusive) { Previous Comments: [2005-08-01 09:52:42] jfbustarret at tf1 dot fr This bug is : - time dependant, - load dependant, - random. I certainly would not be able to find a piece of code that reproduces the crash. All I know is that _oci_close_session is called with session->server == NULL and that obviously crashes the function because it assumes that session->server is a valid pointer. [2005-07-29 16:21:57] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-07-29 16:15:34] jfbustarret at tf1 dot fr The bug exists with the CVS version of ext/oci8. [2005-07-29 09:56:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-29 08:25:19] jfbustarret at tf1 dot fr Description: Using php 5.0.4, with the oci8 extension from CVS & the oci_ping code activated in _oci_open_server, I have random segfaults on my production servers. Here is the back trace : #0 0xb78f3779 in _oci_close_session (session=0x8382a20) at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961 2961CALL_OCI_RETURN(OCI(error), (gdb) bt #0 0xb78f3779 in _oci_close_session (session=0x8382a20) at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961 #1 0xb79f0d5e in list_entry_destructor (ptr=0x83590f0) at /soft/sources/php/php-5.0.4/Zend/zend_list.c:173 #2 0xb79eef48 in zend_hash_apply_deleter (ht=0xb7a72560, p=0x836a4c8) at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:618 #3 0xb79ef227 in zend_hash_graceful_reverse_destroy (ht=0xb7a72560) at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:684 #4 0xb79e144a in shutdown_executor () at /soft/sources/php/php-5.0.4/Zend/zend_execute_API.c:284 #5 0xb79e8c86 in zend_deactivate () at /soft/sources/php/php-5.0.4/Zend/zend.c:902 #6 0xb79b544c in php_request_shutdown (dummy=0x0) [...] (gdb) print *session $1 = {num = 137800016, persistent = 0 '\0', is_open = 253 'ý', exclusive = 49 '1', thread = 8 '\b', sessions_list = 0x0, server = 0x0, pSession = 0x0, pEnv = 0x0, charsetId = 0} I'll try this patch in _oci_close_session : if (!session) { return; } +if (!session->server) { +return; +} oci_debug("START _oci_close_session: logging-off sess=%d",session->num); Reproduce code: --- No reproducing code. The crashes are random & time/traffic dependant. -- Edit this bug report at http://bugs.php.net/?id=33915&edit=1
#33533 [Opn->Asn]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Updated by: [EMAIL PROTECTED] Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Open +Status: Assigned Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: Wez, the fix didn't quite fix it? :) (note to myself: need to get my eyes checked) Previous Comments: [2005-08-03 06:32:45] scott dot barnett at thuringowa dot qld dot gov dot au Still having build problems. Thanks. (gdb) bt #0 0x in ?? () #1 0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336 #2 0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412 #3 0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704) at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434 #4 0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447 #5 0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870 #6 0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135 #7 0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:19523 #8 0x00f0f51c in execute (op_array=0x83468fc) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:87 #9 0x00ee8ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200508030230/Zend/zend.c:1078 #10 0x00ea8058 in php_execute_script (primary_file=0xbff30f70) at /usr/src/apache/php5-200508030230/main/main.c:1672 #11 0x00f53f8e in php_handler (r=0x8337be0) at /usr/src/apache/php5-200508030230/sapi/apache2handler/sapi_apache2.c:562 #12 0x0809953a in ap_run_handler (r=0x8337be0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x8337be0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x8337be0) at http_request.c:249 #15 0x0807e225 in ap_process_http_connection (c=0x8331948) at http_core.c:251 #16 0x080a2a02 in ap_run_process_connection (c=0x8331948) at connection.c:43 #17 0x08097d15 in child_main (child_num_arg=138040732) at prefork.c:610 #18 0x08097f09 in make_child (s=0x81c5a08, slot=0) at prefork.c:650 #19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722 #20 0x080986a3 in ap_mpm_run (_pconf=0xbff312c0, plog=0x81fa190, s=0xbff312c4) at prefork.c:941 #21 0x0809d7a3 in main (argc=2, argv=0xbff31464) at main.c:618 [2005-07-19 17:27:19] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_hel
#33533 [Csd->Opn]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 User updated by: scott dot barnett at thuringowa dot qld dot gov dot au Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Closed +Status: Open Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: huh? Apologies, I said it was a build problem, that's incorrect (my bad I was being rushed into a meeting). I'm able to compile, but am receiving the same seg fault in the latest snapshot. The snapshot I just tried is 200508030230, that's today! Thanks, Scott. Previous Comments: [2005-08-03 07:52:50] [EMAIL PROTECTED] The snapshots are NOT created that often. Get a newer one and try again. [2005-08-03 06:32:45] scott dot barnett at thuringowa dot qld dot gov dot au Still having build problems. Thanks. (gdb) bt #0 0x in ?? () #1 0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336 #2 0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412 #3 0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704) at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434 #4 0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447 #5 0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870 #6 0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135 #7 0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:19523 #8 0x00f0f51c in execute (op_array=0x83468fc) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:87 #9 0x00ee8ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200508030230/Zend/zend.c:1078 #10 0x00ea8058 in php_execute_script (primary_file=0xbff30f70) at /usr/src/apache/php5-200508030230/main/main.c:1672 #11 0x00f53f8e in php_handler (r=0x8337be0) at /usr/src/apache/php5-200508030230/sapi/apache2handler/sapi_apache2.c:562 #12 0x0809953a in ap_run_handler (r=0x8337be0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x8337be0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x8337be0) at http_request.c:249 #15 0x0807e225 in ap_process_http_connection (c=0x8331948) at http_core.c:251 #16 0x080a2a02 in ap_run_process_connection (c=0x8331948) at connection.c:43 #17 0x08097d15 in child_main (child_num_arg=138040732) at prefork.c:610 #18 0x08097f09 in make_child (s=0x81c5a08, slot=0) at prefork.c:650 #19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722 #20 0x080986a3 in ap_mpm_run (_pconf=0xbff312c0, plog=0x81fa190, s=0xbff312c4) at prefork.c:941 #21 0x0809d7a3 in main (argc=2, argv=0xbff31464) at main.c:618 [2005-07-19 17:27:19] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/s
#33533 [Opn->Csd]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Updated by: [EMAIL PROTECTED] Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Open +Status: Closed Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: The snapshots are NOT created that often. Get a newer one and try again. Previous Comments: [2005-08-03 06:32:45] scott dot barnett at thuringowa dot qld dot gov dot au Still having build problems. Thanks. (gdb) bt #0 0x in ?? () #1 0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336 #2 0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412 #3 0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704) at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434 #4 0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447 #5 0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870 #6 0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135 #7 0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:19523 #8 0x00f0f51c in execute (op_array=0x83468fc) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:87 #9 0x00ee8ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200508030230/Zend/zend.c:1078 #10 0x00ea8058 in php_execute_script (primary_file=0xbff30f70) at /usr/src/apache/php5-200508030230/main/main.c:1672 #11 0x00f53f8e in php_handler (r=0x8337be0) at /usr/src/apache/php5-200508030230/sapi/apache2handler/sapi_apache2.c:562 #12 0x0809953a in ap_run_handler (r=0x8337be0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x8337be0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x8337be0) at http_request.c:249 #15 0x0807e225 in ap_process_http_connection (c=0x8331948) at http_core.c:251 #16 0x080a2a02 in ap_run_process_connection (c=0x8331948) at connection.c:43 #17 0x08097d15 in child_main (child_num_arg=138040732) at prefork.c:610 #18 0x08097f09 in make_child (s=0x81c5a08, slot=0) at prefork.c:650 #19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722 #20 0x080986a3 in ap_mpm_run (_pconf=0xbff312c0, plog=0x81fa190, s=0xbff312c4) at prefork.c:941 #21 0x0809d7a3 in main (argc=2, argv=0xbff31464) at main.c:618 [2005-07-19 17:27:19] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_helper_SPEC (ex
#31327 [Opn->Asn]: chinese char and word problem
ID: 31327 Updated by: [EMAIL PROTECTED] Reported By: vtsuper1 at mail dot hongkong dot com -Status: Open +Status: Assigned Bug Type: COM related Operating System: windowXP PHP Version: 5.1 -Assigned To: +Assigned To: wez New Comment: Assigned to the maintainer of COM extension. Previous Comments: [2005-08-03 05:17:34] vtsuper1 at mail dot hongkong dot com Dear sir, Thanks for your help. I have test it in a php 5.1.X version. But the bug doesn't fixed. The meaningless space change to a square characters only... Anyway, thanks for your help. (This problem hasn't exist in Excel, it only happened in Word only) >From Victor [2005-08-02 23:49:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-12-28 20:46:49] vtsuper1 at mail dot hongkong dot com Description: I have try this code in php 5.0.3 and 4.3 I'm using Chinese winXP and Chinese Office XP apache 2 both version of php also have the same problem When I use Chinese character in the string, the output of the word file will have some meaningless spaces after the words I expected(my expected string is ok, no problem). There are no problem if I using English. And this problem will not occurs in excel. Reproduce code: --- Version}\n"; //bring it to front $word->Visible = 1; //open an empty document $word->Documents->Add(); //do some weird stuff $word->Selection->TypeText("§A¦n¶Ü"); $word->Documents[1]->SaveAs("Useless test.doc"); //closing word $word->Quit(); //free the object $word = null; ?> Expected result: §A¦n¶Ü Actual result: -- §A¦n¶Ü (there are some spaces occurs, I use the underline to repersent the spaces) -- Edit this bug report at http://bugs.php.net/?id=31327&edit=1
#33874 [Opn->Asn]: The Windows builds should be updated to openssl 0.9.8
ID: 33874 Updated by: [EMAIL PROTECTED] Reported By: mdlawler at gwmicro dot com -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: Windows XP PHP Version: 5CVS-2005-07-26 (dev) Assigned To: edink New Comment: Edin, little mistake there? :) Previous Comments: [2005-08-03 02:01:53] mdlawler at gwmicro dot com The php_openssl.dll is now built against openssl 0.9.8, but the libeay32.dll and ssleay32.dll files that are included are still openssl 0.9.7g. [2005-08-02 02:09:05] [EMAIL PROTECTED] updated to openssl 0.9.8 [2005-07-26 23:55:17] [EMAIL PROTECTED] Edin, could you plz take care of that? [2005-07-26 23:45:33] mdlawler at gwmicro dot com Description: Openssl 0.9.8 hs been released and should be used in the Windows php builds -- Edit this bug report at http://bugs.php.net/?id=33874&edit=1
#33533 [Csd->Opn]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 User updated by: scott dot barnett at thuringowa dot qld dot gov dot au Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Closed +Status: Open Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: Still having build problems. Thanks. (gdb) bt #0 0x in ?? () #1 0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336 #2 0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412 #3 0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704) at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434 #4 0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447 #5 0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870 #6 0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135 #7 0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:19523 #8 0x00f0f51c in execute (op_array=0x83468fc) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:87 #9 0x00ee8ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200508030230/Zend/zend.c:1078 #10 0x00ea8058 in php_execute_script (primary_file=0xbff30f70) at /usr/src/apache/php5-200508030230/main/main.c:1672 #11 0x00f53f8e in php_handler (r=0x8337be0) at /usr/src/apache/php5-200508030230/sapi/apache2handler/sapi_apache2.c:562 #12 0x0809953a in ap_run_handler (r=0x8337be0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x8337be0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x8337be0) at http_request.c:249 #15 0x0807e225 in ap_process_http_connection (c=0x8331948) at http_core.c:251 #16 0x080a2a02 in ap_run_process_connection (c=0x8331948) at connection.c:43 #17 0x08097d15 in child_main (child_num_arg=138040732) at prefork.c:610 #18 0x08097f09 in make_child (s=0x81c5a08, slot=0) at prefork.c:650 #19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722 #20 0x080986a3 in ap_mpm_run (_pconf=0xbff312c0, plog=0x81fa190, s=0xbff312c4) at prefork.c:941 #21 0x0809d7a3 in main (argc=2, argv=0xbff31464) at main.c:618 Previous Comments: [2005-07-19 17:27:19] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184 #7 0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe0d160) at /usr/src/apache/php5-
#31327 [Fbk->Opn]: chinese char and word problem
ID: 31327 User updated by: vtsuper1 at mail dot hongkong dot com Reported By: vtsuper1 at mail dot hongkong dot com -Status: Feedback +Status: Open Bug Type: COM related Operating System: windowXP -PHP Version: 5.0.4 +PHP Version: 5.1 New Comment: Dear sir, Thanks for your help. I have test it in a php 5.1.X version. But the bug doesn't fixed. The meaningless space change to a square characters only... Anyway, thanks for your help. (This problem hasn't exist in Excel, it only happened in Word only) >From Victor Previous Comments: [2005-08-02 23:49:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-12-28 20:46:49] vtsuper1 at mail dot hongkong dot com Description: I have try this code in php 5.0.3 and 4.3 I'm using Chinese winXP and Chinese Office XP apache 2 both version of php also have the same problem When I use Chinese character in the string, the output of the word file will have some meaningless spaces after the words I expected(my expected string is ok, no problem). There are no problem if I using English. And this problem will not occurs in excel. Reproduce code: --- Version}\n"; //bring it to front $word->Visible = 1; //open an empty document $word->Documents->Add(); //do some weird stuff $word->Selection->TypeText("§A¦n¶Ü"); $word->Documents[1]->SaveAs("Useless test.doc"); //closing word $word->Quit(); //free the object $word = null; ?> Expected result: §A¦n¶Ü Actual result: -- §A¦n¶Ü (there are some spaces occurs, I use the underline to repersent the spaces) -- Edit this bug report at http://bugs.php.net/?id=31327&edit=1
#33874 [Csd->Opn]: The Windows builds should be updated to openssl 0.9.8
ID: 33874 User updated by: mdlawler at gwmicro dot com Reported By: mdlawler at gwmicro dot com -Status: Closed +Status: Open Bug Type: OpenSSL related Operating System: Windows XP PHP Version: 5CVS-2005-07-26 (dev) Assigned To: edink New Comment: The php_openssl.dll is now built against openssl 0.9.8, but the libeay32.dll and ssleay32.dll files that are included are still openssl 0.9.7g. Previous Comments: [2005-08-02 02:09:05] [EMAIL PROTECTED] updated to openssl 0.9.8 [2005-07-26 23:55:17] [EMAIL PROTECTED] Edin, could you plz take care of that? [2005-07-26 23:45:33] mdlawler at gwmicro dot com Description: Openssl 0.9.8 hs been released and should be used in the Windows php builds -- Edit this bug report at http://bugs.php.net/?id=33874&edit=1
#30127 [Com]: lost oracle connection. need restart apache.
ID: 30127 Comment by: dwcsite at yahoo dot com Reported By: andreys at uniqinfo dot ru Status: No Feedback Bug Type: OCI8 related Operating System: Windows 2000 SP4 PHP Version: 5.0.1 New Comment: My client is a billion dollar corporation. We are using PHP / Oracle to run a financial reporting portal that the high level executives use to access static reports generated by Business Object's broadcast agent. The PHP / Oracle layer is used to provide security and enforce business rules around SEC regulation. We are having the same problem. We get get an error similar to this: [Fri Jul 29 11:09:39 2005] [notice] child pid 15530 exit signal Segmentation fault (11) It seems that this is caused by the DBAs fiddling around with the Oracle server and the connection drops. Because there isn't good coordination between the Unix admins and the DBAs, Apache doesn't get restarted when the connection drops. We are currently having to manually restart the Apache process, which usually involves someone getting woken up at an ungodly hour. We're using Apache 2, PHP 5.0.3, on Solaris 2.9. Our database is Oracle9i Enterprise Edition Release 9.2.0.6.0. Here are snippets of our configuration: PHP Version => 5.0.3 System => SunOS servernamegoeshere 5.9 Generic_117171-14 sun4u Build Date => Feb 11 2005 07:22:47 Configure Command => './configure' '--with-pear' '--with-db4=/local/applications/bdb' '--with-freetype-dir=/opt/gnu' '--with- jpeg-dir=/opt/gnu' '--with-oci8=/local/www/httpd/instantclient10_1' '--enable-mbstring' '--enable-ftp' '--disable-ipv6' '--wit h-ldap=/local/applications/openldap' '--with-ldap-lib=/local/applications/openldap/lib' '--with-ldap-include=/local/applicatio ns/openldap/include' '--with-mysql=/local/www/httpd' '--with-libxml-dir=/local/www/httpd' '--with-imap=/local/development/mail /imap-2004a' '--with-openssl=/local/ssl' '--with-zlib' '--with-zlib-include=/opt/gnu/include' '--with-zlib-lib=/opt/gnu/lib' ' --with-zlib-dir=/opt/gnu/lib' '--with-gd=/opt/gnu' '--with-inifile' '--with-flatfile' '--with-bz2=/opt/gnu' '--prefix=/local/w ww/httpd' '--with-apxs2=/local/www/httpd/bin/apxs' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => /conf/net/www/php/php.ini.finportprd01 PHP API => 20031224 PHP Extension => 20041030 Zend Extension => 220040412 Debug Build => no Thread Safety => disabled IPv6 Support => disabled Registered PHP Streams => php, file, http, ftp, compress.bzip2, compress.zlib, https, ftps Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls ... oci8 OCI8 Support => enabled Revision => $Revision: 1.257.2.5 $ Active Persistent Links => 0 Active Links => 0 Oracle Version => 10.1 Compile-time ORACLE_HOME => /local/www/httpd/instantclient10_1 Libraries Used => Temporary Lob support => enabled Collections support => enabled ... I don't belive that this is rightfully a PHP bug. It has more to do with the fact that Oracle and the way it manages connections sucks ass. But, I did want to document it, because it is a real problem, as andreys suggests, and it will not be solved through the conventional debugging techniques that are being suggested. Better to write a script to monitor your logs and make it your admin's headache, if you are lucky enough not to be the admin, of course. ;-) Previous Comments: [2005-05-02 18:19:12] terry dot greenlaw at logicalshift dot com The current code is returning cached connections that are no longer valid. If the oracle instance is bounced without restarting Apache, the cached connections will no longer function (they will return ORA-24237), but they are still being returned to oci_connect (and oci_new_connect). The connection either needs to be tested for "liveness" before being returned, or closed properly. They really should be closed instead of cached (unless using pconnect). We're going to have to switch to CLI mode on our production systems until this is fixed. [2005-04-30 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-04-22 13:10:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-10-03 15:45:28] cdcampos at netcabo dot pt I have this behaviour with the following scenario: Oracle 8i, server and client 8.1.7.4 Apache 1.3.31 Windows 2000 SP4 PH
#33964 [Csd]: ifx.ec : syntax error before '/' token
ID: 33964 User updated by: jmserra at pereserra dot net Reported By: jmserra at pereserra dot net Status: Closed Bug Type: Compile Failure Operating System: Linux Fedora Core 4 PHP Version: 5.0.4 New Comment: last question before closing this report when a new official/stable release solving this problem will be released? when will be avaliable the PHP 5.0.5 ? thanks for all Goodbye. Previous Comments: [2005-08-02 23:50:13] [EMAIL PROTECTED] We don't give guarantees even to the releases so you're on your own anyway. :) [2005-08-02 23:42:23] jmserra at pereserra dot net I had to change the options of configure script, i enabled suport of libxml2 (else the script outputs an error because DOM requires libxml2) ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 and make not crashed. Problem solved. Now it works fine but i have a question, if i install this version (-dev) on a production server (where it have to go) is safe? i want to mean if this version is more/less stable than the official 5.0.4 ? thank you [2005-08-02 18:12:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 13:54:49] jmserra at pereserra dot net Description: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml works fine , after executing 'make' outputs that syntax error versions: *Informix IDS v9.4 32bit *GNU libtool 1.5.16 *make 3.8 Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml make Expected result: i expected that make outut no errors Actual result: -- /bin/sh /root/php-5.0.4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/informix//incl/esql -Iext/informix/ -I/root/php-5.0.4/ext/informix/ -DPHP_ATOM_INC -I/root/php-5.0.4/include -I/root/php-5.0.4/main -I/root/php-5.0.4 -I/usr/include/mysql -I/root/php-5.0.4/TSRM -I/root/php-5.0.4/Zend -g -O2 -prefer-non-pic -c /root/php-5.0.4/ext/informix/ifx.c -o ext/informix/ifx.lo /root/php-5.0.4/ext/informix/ifx.ec: In function 'zm_info_ifx': /root/php-5.0.4/ext/informix/ifx.ec:452: error: syntax error before '/' token /root/php-5.0.4/ext/informix/ifx.ec:3241:17: error: operator '<' has no left operand make: *** [ext/informix/ifx.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=33964&edit=1
#33964 [Opn->Csd]: ifx.ec : syntax error before '/' token
ID: 33964 Updated by: [EMAIL PROTECTED] Reported By: jmserra at pereserra dot net -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux Fedora Core 4 PHP Version: 5.0.4 New Comment: We don't give guarantees even to the releases so you're on your own anyway. :) Previous Comments: [2005-08-02 23:42:23] jmserra at pereserra dot net I had to change the options of configure script, i enabled suport of libxml2 (else the script outputs an error because DOM requires libxml2) ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 and make not crashed. Problem solved. Now it works fine but i have a question, if i install this version (-dev) on a production server (where it have to go) is safe? i want to mean if this version is more/less stable than the official 5.0.4 ? thank you [2005-08-02 18:12:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 13:54:49] jmserra at pereserra dot net Description: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml works fine , after executing 'make' outputs that syntax error versions: *Informix IDS v9.4 32bit *GNU libtool 1.5.16 *make 3.8 Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml make Expected result: i expected that make outut no errors Actual result: -- /bin/sh /root/php-5.0.4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/informix//incl/esql -Iext/informix/ -I/root/php-5.0.4/ext/informix/ -DPHP_ATOM_INC -I/root/php-5.0.4/include -I/root/php-5.0.4/main -I/root/php-5.0.4 -I/usr/include/mysql -I/root/php-5.0.4/TSRM -I/root/php-5.0.4/Zend -g -O2 -prefer-non-pic -c /root/php-5.0.4/ext/informix/ifx.c -o ext/informix/ifx.lo /root/php-5.0.4/ext/informix/ifx.ec: In function 'zm_info_ifx': /root/php-5.0.4/ext/informix/ifx.ec:452: error: syntax error before '/' token /root/php-5.0.4/ext/informix/ifx.ec:3241:17: error: operator '<' has no left operand make: *** [ext/informix/ifx.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=33964&edit=1
#31327 [Opn->Fbk]: chinese char and word problem
ID: 31327 Updated by: [EMAIL PROTECTED] Reported By: vtsuper1 at mail dot hongkong dot com -Status: Open +Status: Feedback Bug Type: COM related Operating System: windowXP PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2004-12-28 20:46:49] vtsuper1 at mail dot hongkong dot com Description: I have try this code in php 5.0.3 and 4.3 I'm using Chinese winXP and Chinese Office XP apache 2 both version of php also have the same problem When I use Chinese character in the string, the output of the word file will have some meaningless spaces after the words I expected(my expected string is ok, no problem). There are no problem if I using English. And this problem will not occurs in excel. Reproduce code: --- Version}\n"; //bring it to front $word->Visible = 1; //open an empty document $word->Documents->Add(); //do some weird stuff $word->Selection->TypeText("§A¦n¶Ü"); $word->Documents[1]->SaveAs("Useless test.doc"); //closing word $word->Quit(); //free the object $word = null; ?> Expected result: §A¦n¶Ü Actual result: -- §A¦n¶Ü (there are some spaces occurs, I use the underline to repersent the spaces) -- Edit this bug report at http://bugs.php.net/?id=31327&edit=1
#33964 [Fbk->Opn]: ifx.ec : syntax error before '/' token
ID: 33964 User updated by: jmserra at pereserra dot net Reported By: jmserra at pereserra dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Linux Fedora Core 4 PHP Version: 5.0.4 New Comment: I had to change the options of configure script, i enabled suport of libxml2 (else the script outputs an error because DOM requires libxml2) ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 and make not crashed. Problem solved. Now it works fine but i have a question, if i install this version (-dev) on a production server (where it have to go) is safe? i want to mean if this version is more/less stable than the official 5.0.4 ? thank you Previous Comments: [2005-08-02 18:12:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 13:54:49] jmserra at pereserra dot net Description: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml works fine , after executing 'make' outputs that syntax error versions: *Informix IDS v9.4 32bit *GNU libtool 1.5.16 *make 3.8 Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml make Expected result: i expected that make outut no errors Actual result: -- /bin/sh /root/php-5.0.4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/informix//incl/esql -Iext/informix/ -I/root/php-5.0.4/ext/informix/ -DPHP_ATOM_INC -I/root/php-5.0.4/include -I/root/php-5.0.4/main -I/root/php-5.0.4 -I/usr/include/mysql -I/root/php-5.0.4/TSRM -I/root/php-5.0.4/Zend -g -O2 -prefer-non-pic -c /root/php-5.0.4/ext/informix/ifx.c -o ext/informix/ifx.lo /root/php-5.0.4/ext/informix/ifx.ec: In function 'zm_info_ifx': /root/php-5.0.4/ext/informix/ifx.ec:452: error: syntax error before '/' token /root/php-5.0.4/ext/informix/ifx.ec:3241:17: error: operator '<' has no left operand make: *** [ext/informix/ifx.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=33964&edit=1
#33931 [Asn]: __get and __set don't handle arrays correctly
ID: 33931 Updated by: [EMAIL PROTECTED] Reported By: wkonkel at gmail dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: * -PHP Version: 5CVS-2005-07-31 +PHP Version: 5CVS-2005-08-02 Assigned To: dmitry New Comment: /usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088F18B4 (40 bytes), script=t.php Last leak repeated 2 times /usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088F181C (5 bytes), script=t.php /usr/src/php/php5/Zend/zend_variables.c(120) : Actual location (location was relayed) Last leak repeated 2 times /usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088F17DC (16 bytes), script=t.php Last leak repeated 2 times /usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088F1724 (44 bytes), script=t.php /usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was relayed) Last leak repeated 3 times /usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088E0994 (16 bytes), script=t.php Previous Comments: [2005-08-01 09:51:38] [EMAIL PROTECTED] Dmitry, could you check it plz ? [2005-07-31 20:01:33] [EMAIL PROTECTED] And this with Sean's code: PHP Notice: Undefined property: A::$foo in /home/jani/t.php on line 8 Notice: Undefined property: A::$foo in /home/jani/t.php on line 8 PHP Notice: Undefined property: A::$foo in /home/jani/t.php on line 9 Notice: Undefined property: A::$foo in /home/jani/t.php on line 9 PHP Notice: Undefined variable: undefined in /home/jani/t.php on line 10 Notice: Undefined variable: undefined in /home/jani/t.php on line 10 NULL array(2) { ["bar1"]=> string(5) "oink1" [0]=> string(4) "blah" } /usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088ED84C (6 bytes), script=t.php /usr/src/php/php5/Zend/zend_variables.c(120) : Actual location (location was relayed) Last leak repeated 1 time /usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088ED80C (16 bytes), script=t.php Last leak repeated 1 time /usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088ED7B4 (40 bytes), script=t.php Last leak repeated 1 time /usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088ED754 (44 bytes), script=t.php /usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was relayed) Last leak repeated 3 times /usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088DE7CC (16 bytes), script=t.php === Total 11 memory leaks detected === [2005-07-31 20:00:32] [EMAIL PROTECTED] Output with CVS HEAD: Array ( [foo2] => bar2 [foo3] => bar3 [0] => blah ) /usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088EF6FC (40 bytes), script=t.php Last leak repeated 2 times /usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088EF664 (5 bytes), script=t.php /usr/src/php/php5/Zend/zend_variables.c(120) : Actual location (location was relayed) Last leak repeated 2 times /usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088EF624 (16 bytes), script=t.php Last leak repeated 2 times /usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088EF56C (44 bytes), script=t.php /usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was relayed) Last leak repeated 3 times /usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088DE7CC (16 bytes), script=t.php === Total 14 memory leaks detected === [2005-07-30 23:52:13] [EMAIL PROTECTED] Happens to me on 5.0.3 as well. Shorter code: data[$key] = $val; } } $A = new A(); $A->foo['bar'] = 'oink'; $A->foo['bar1'] = 'oink1'; var_dump($undefined); $undefined[] = 'blah'; var_dump($undefined); ?> Outputs: NULL array(2) { ["bar1"]=> string(5) "oink1" [0]=> string(4) "blah" } [2005-07-30 22:39:55] wkonkel at gmail dot com Description: The __set and __get don't seem to handle arrays correctly. What's even worse, is it adds data to memory which is allocated at a later time ($boz gets foo2 and foo3 of $myObj). The code example speaks for itself. Reproduce code: --- data[$key] = $val; } function __get($key) { return $this->data[$key]; } } $myObj = new buggy(); $myObj->somevar['foo1'] = 'bar1'; $myObj->somevar['foo2'] = 'bar2'; $myObj->somevar['foo3'] = 'bar3'; $boz[] = 'blah'; print_r($boz); ?> Expected result: Array ( [0] => blah ) Actual result: -- Array ( [foo2] => bar2 [foo3] => bar3 [0] => blah ) -- Edit this bug report at http://bugs.php.net/?id=33931&edit=1
#33966 [Ver->Asn]: wrong use of reflectionproperty causes a segfault
ID: 33966 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Assigned Bug Type: Class/Object related Operating System: * PHP Version: 5CVS-2005-08-02 -Assigned To: +Assigned To: helly New Comment: This happens because METHOD_NOTSTATIC just checks this_ptr presence and doesn't check it's class entry. So I'd propose this patch: http://tony2001.phpclub.net/dev/tmp/bug33966.diff Previous Comments: [2005-08-02 14:23:59] [EMAIL PROTECTED] Description: When (ab)using the ReflectionProperty class' methods as static, it segfaults. Reproduce code: --- foo; ?> Actual result: -- 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 3359RETURN_BOOL(ref->prop->flags & mask); (gdb) bt #0 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 #1 0x083c2c24 in zif_reflection_property_isPublic (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3366 #2 0x083c6309 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffd090) at zend_vm_execute.h:184 #3 0x083c692d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffd090) at zend_vm_execute.h:299 #4 0x083c5f8a in execute (op_array=0x878dd34) at zend_vm_execute.h:87 #5 0x0838edc6 in zend_call_function (fci=0xbfffd260, fci_cache=0xbfffd220) at /dat/dev/php/php-5.1dev/Zend/zend_execute_API.c:871 #6 0x083aee9d in zend_call_method (object_pp=0xbfffd2f0, obj_ce=0x878c36c, fn_proxy=0x878c44c, function_name=0x85cfd54 "__get", function_name_len=5, retval_ptr_ptr=0xbfffd2e4, param_count=1, arg1=0x878cea4, arg2=0x0) at /dat/dev/php/php-5.1dev/Zend/zend_interfaces.c:87 #7 0x083b4e26 in zend_std_call_getter (object=0x878c714, member=0x878cea4) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:72 #8 0x083b576e in zend_std_read_property (object=0x878c714, member=0x878b148, type=0) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:305 #9 0x083ff3f9 in zend_fetch_property_address_read_helper_SPEC_CV_CONST ( type=0, execute_data=0xbfffd440) at zend_vm_execute.h:20491 #10 0x083ff510 in ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER ( execute_data=0xbfffd440) at zend_vm_execute.h:20513 #11 0x083c5f8a in execute (op_array=0x8786de4) at zend_vm_execute.h:87 #12 0x0839b2fb in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /dat/dev/php/php-5.1dev/Zend/zend.c:1087 #13 0x08350fc4 in php_execute_script (primary_file=0xb8b0) at /dat/dev/php/php-5.1dev/main/main.c:1672 #14 0x0841325c in main (argc=1, argv=0xb994) at /dat/dev/php/php-5.1dev/sapi/cli/php_cli.c:1039 (gdb) print *ref Cannot access memory at address 0x2a8fcc84 -- Edit this bug report at http://bugs.php.net/?id=33966&edit=1
#33942 [Asn->Csd]: the patch to #33156 crash cygwin except cli
ID: 33942 Updated by: [EMAIL PROTECTED] Reported By: xuefer at 21cn dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: cygwin only PHP Version: 5CVS-2005-08-01 (dev) Assigned To: dmitry New Comment: Done. Previous Comments: [2005-08-02 19:24:52] [EMAIL PROTECTED] the patch should also be applied to the 4_4 branch. [2005-08-02 19:02:52] [EMAIL PROTECTED] Nuno's patch is applied to CVS HEAD and PHP_5_0. [2005-08-02 15:10:46] [EMAIL PROTECTED] I've tested fastcgi and it seems to work fine. I've also fixed the indentation in the patch. [2005-08-02 03:06:32] xuefer at 21cn dot com fastcgi, and maybe other sapi except cli/CGI!, as both cli/cgi exit immediately after request shutdown the patch nlopess posted should work (i did it after my report too) but btw, the indention is not consistent with previous patch [2005-08-01 23:25:06] [EMAIL PROTECTED] I've tested the CLI and CGI sapis and eveything works fine. I couldn't test further, because you didn't specify the sapi you were using. Anyway, you are right and I missed the zend_unset_timeout() in my patch. Here is a patch that should fix your problem: http://mega.ist.utl.pt/~ncpl/patch_cygwin_php.txt Please test it. Thanks, Nuno 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/33942 -- Edit this bug report at http://bugs.php.net/?id=33942&edit=1
#33770 [Fbk->Opn]: https:// or ftps:// do not work with both --with-openssl and --with-curlwrappers
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: Tried php5-200508021630 CVS snapshot. https works: ./configure --disable-all --disable-cgi --with-openssl --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl --with-curl --with-curlwrappers My machine is x64 Linux (SuSE 9.3) OpenSSL libraries: openssl-devel-0.9.7e-3 CURL libraries: curl-devel-7.13.0-5 Previous Comments: [2005-08-02 07:57:46] [EMAIL PROTECTED] I can't reproduce this, with having both of those configure options enabled the same time. Please try latest CVS snapshot. [2005-07-20 12:59:32] subscription at nazarenko dot net Since the issue of OpenSSL/https is being looked now, I want to mention something about working with https:// (when it works). Feel free to delete this if you think it is irrelevant to the case and I will try to open a new report then. The PHP file() function manual states: Warning: When using SSL, Microsoft IIS will violate the protocol by closing the connection without sending a close_notify indicator. PHP will report this as "SSL: Fatal Protocol Error" when you reach the end of the data. To workaround this, you should lower your error_reporting level not to include warnings. PHP 4.3.7 and higher can detect buggy IIS server software when you open the stream using the https:// wrapper and will suppress the warning for you. This is not the case with 5.x.x, in other words, I understand I should not be getting this warning, however I do get it. [2005-07-20 00:48:35] subscription at nazarenko dot net Thank you for a speedy response. Indeed, with the minimal configure, it started working again. After 1 hour of mixing and matching the modules I found the culprit. It is: curl-7.13.0 libraries compiled in with the following parameters: --with-curl --with-curlwrappers Actually, without "--with-curlwrappers" it works fine. Tested both for 5.0.4 and 5CVS [2005-07-19 21:32:47] [EMAIL PROTECTED] Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: "Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. " (do NOT add any huge outputs of anything unless asked for!) 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770&edit=1
#33942 [Csd->Asn]: the patch to #33156 crash cygwin except cli
ID: 33942 Updated by: [EMAIL PROTECTED] Reported By: xuefer at 21cn dot com -Status: Closed +Status: Assigned Bug Type: Scripting Engine problem Operating System: cygwin only PHP Version: 5CVS-2005-08-01 (dev) Assigned To: dmitry New Comment: the patch should also be applied to the 4_4 branch. Previous Comments: [2005-08-02 19:02:52] [EMAIL PROTECTED] Nuno's patch is applied to CVS HEAD and PHP_5_0. [2005-08-02 15:10:46] [EMAIL PROTECTED] I've tested fastcgi and it seems to work fine. I've also fixed the indentation in the patch. [2005-08-02 03:06:32] xuefer at 21cn dot com fastcgi, and maybe other sapi except cli/CGI!, as both cli/cgi exit immediately after request shutdown the patch nlopess posted should work (i did it after my report too) but btw, the indention is not consistent with previous patch [2005-08-01 23:25:06] [EMAIL PROTECTED] I've tested the CLI and CGI sapis and eveything works fine. I couldn't test further, because you didn't specify the sapi you were using. Anyway, you are right and I missed the zend_unset_timeout() in my patch. Here is a patch that should fix your problem: http://mega.ist.utl.pt/~ncpl/patch_cygwin_php.txt Please test it. Thanks, Nuno [2005-08-01 12:07:40] [EMAIL PROTECTED] Dmitry, check your patch please. :) 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/33942 -- Edit this bug report at http://bugs.php.net/?id=33942&edit=1
#33963 [Opn->Fbk]: Binding some stored procedure parameters fails
ID: 33963 Updated by: [EMAIL PROTECTED] Reported By: paul dot robinson at groupbc dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5.0.4 New Comment: Provide patches in unified diff format (diff -u) and against PHP CVS HEAD (we're not likely to release any 5.0.x versions anymore). Put the diffs somewhere were people can download it and put the URLs here. Previous Comments: [2005-08-02 18:51:03] paul dot robinson at groupbc dot com Patches suggested are against Snapshot: php5-STABLE-200508021038.tar.gz Although I haven't actually built an example using that snapshot today I have looked at the code which since it is unchanged would seem to exhibit the same problem. [2005-08-02 18:34:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 13:39:23] paul dot robinson at groupbc dot com Description: Using FreeTDS 0.63 (latest stable release), calling mssql_bind can fail due to the restrictions placed on parameters by the dbrpcparam function from FreeTDS. One specific example is an input parameter must have maxlen==-1. With the code as is in PHP 5.0.4 a NULL valued variable length type input parameter will always have maxlen==0 thereby always failing. Diff below shows changes to ext/mssql/php_mssql.c that address this parameter mismatch. 2025,2026c2025,2029 < maxlen=0; < datalen=0; --- > datalen = 0; > if (is_output) > maxlen = -1; > else > maxlen = -1; 2030d2032 < datalen=Z_STRLEN_PP(var); 2031a2034,2046 > > if (is_output) { > if ((maxlen > 0 ) && (maxlen < 256)) > datalen = maxlen; > else { > maxlen = 255; > datalen = 255; > } > } > else { > maxlen = -1; > datalen=Z_STRLEN_PP(var); > } Reproduce code: --- mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR); or mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR, false, true, 57); Expected result: Sucessfully bind input variable. Actual result: -- "Unable to set parameter" i.e. FAIL is returned by the call to dbrpcparam in PHP_FUNCTION(mssql_bind). -- Edit this bug report at http://bugs.php.net/?id=33963&edit=1
#33965 [Opn->Fbk]: NULL valued output parameters from stored procedures contain corrupt data
ID: 33965 Updated by: [EMAIL PROTECTED] Reported By: paul dot robinson at groupbc dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5.0.4 New Comment: Provide patches in unified diff format (diff -u) and against PHP CVS HEAD (we're not likely to release any 5.0.x versions anymore). Put the diffs somewhere were people can download it and put the URLs here. Previous Comments: [2005-08-02 18:50:33] paul dot robinson at groupbc dot com Patches suggested are against Snapshot: php5-STABLE-200508021038.tar.gz Although I haven't actually built an example using that snapshot today I have looked at the code which since it is unchanged would seem to exhibit the same problem. [2005-08-02 18:34:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 14:01:38] paul dot robinson at groupbc dot com Description: MS SQL Server 2000, FreeTDS 0.63 Output parameters from a stored procedure call contain corrupt data when the result should be NULL. Its particularly noticable for variable length strings as output looks as though it just reads from a random pointer until it find a \0 ! No test is done on whether the output is NULL or not. Diff below shows proposed change to fix this. NOTE: This calls a function dbretisnull that is not currently implemented in the FreeTDS package but has been submitted as a proposed change. 19c19 < /* $Id: php_mssql.c,v 1.137.2.9 2005/04/12 17:46:06 fmk Exp $ */ --- > /* $Id: php_mssql.c,v 1.137.2.8 2005/02/25 23:25:33 fmk Exp $ */ 324,326d323 < #ifndef HAVE_FREETDS < dbwinexit(); < #else 328d324 < #endif 978c974 < int i, num_rets, type; --- > int i, num_rets, type, is_null; 992,1019c988,1022 < switch (type) { < case SQLBIT: < case SQLINT1: < case SQLINT2: < case SQLINT4: < convert_to_long_ex(&bind->zval); < /* FIXME this works only on little endian machine !!! */ < Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLFLT4: < case SQLFLT8: < case SQLFLTN: < case SQLMONEY4: < case SQLMONEY: < case SQLMONEYN: < convert_to_double_ex(&bind->zval); < Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLCHAR: < case SQLVARCHAR: < case SQLTEXT: < convert_to_string_ex(&bind->zval); < Z_STRLEN_P(bind->zval) = dbretlen(mssql_ptr->link,i); < Z_STRVAL_P(bind->zval) = estrndup(dbretdata(mssql_ptr->link,i),Z_STRLEN_P(bind->zval)); < break; < /* TODO binary */ --- > /* Test column value for null flag and set value as required */ > is_null = dbretisnull(mssql_ptr->link, i); > if (is_null) { > ZVAL_NULL(bind->zval); > } > else { > switch (type) { > case SQLBIT: > case SQLINT1: > case SQLINT2: > case SQLINT4: > convert_to_long_ex(&bind
#33958 [Ctl->Csd]: Crash with processing HTTP_COOKIE with 'doubled' variables
ID: 33958 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Critical +Status: Closed Bug Type: Reproducible crash Operating System: * PHP Version: 5CVS-2005-08-02 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-08-02 18:56:28] [EMAIL PROTECTED] [Switching to Thread 46912528940992 (LWP 2360)] 0x2aaab000aec1 in _mem_block_check (ptr=0x55b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:736 736 memcpy(&end_magic, (((char *) p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long)); (gdb) (gdb) bt #0 0x2aaab000aec1 in _mem_block_check (ptr=0x55b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:736 #1 0x2aaab000ae9d in _mem_block_check (ptr=0x55b3a081, silent=1, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:728 #2 0x2aaab0009c39 in _efree (ptr=0x55b3a081, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:287 #3 0x2ffe030e in php_register_variable_ex (var=0x55b3a081 "phpbb2mysql_data", val=0x7f839990, track_vars_array=0x55b39ec0) at /usr/src/php/php5/main/php_variables.c:201 #4 0x2ffdfd3c in php_register_variable_safe (var=0x55b3a080 " phpbb2mysql_data", strval=0x557b5500 "a:0:{}", str_len=6, track_vars_array=0x55b39ec0) at /usr/src/php/php5/main/php_variables.c:57 #5 0x2ffe0c8c in php_default_treat_data (arg=2, str=0x0, destArray=0x0) at /usr/src/php/php5/main/php_variables.c:345 #6 0x2ffe1b53 in php_hash_environment () at /usr/src/php/php5/main/php_variables.c:646 #7 0x2ffcf73b in php_request_startup () at /usr/src/php/php5/main/main.c:1064 #8 0x2aaab00b850a in php_apache_request_ctor (r=0x55b23020, ctx=0x55b27a28) at /usr/src/php/php5/sapi/apache2handler/sapi_apache2.c:438 #9 0x2aaab00b8c87 in php_handler (r=0x55b23020) at /usr/src/php/php5/sapi/apache2handler/sapi_apache2.c:534 [2005-08-02 18:50:58] [EMAIL PROTECTED] Verified with latest CVS and Apache2.. [2005-08-02 08:46:15] andrey at cherezov dot koenig dot su In the PHP 4.3.11 under the same server with the same test request = 200 OK. So this bug is PHP5.1 specific. [2005-08-02 08:33:22] andrey at cherezov dot koenig dot su The way to reproduce: GET /php.php5 HTTP/1.0 Host: localhost Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D; phpbb2mysql_data=a%3A0%3A%7B%7D Connection: close Posted this request (via telnet) to my local web-server and got the same error! (the script php.php5 just "echo 'test'"). PHP has encountered an Access Violation at 00F2813A If I delete second variable copy, i.e.: GET /php.php5 HTTP/1.0 Host: localhost Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D Connection: close - the script works ok. [2005-08-02 03:58:49] andrey at cherezov dot koenig dot su Description: Just downloaded and installed 5.1 snap (2 Aug) and replaced PHP5.1b3 in my server (ISAPI mode). Now I see in log, some users got "error 500" while accessing /forum/ and /forum/viewtopic.php (PhpBB current version). Turn on trace and get error pages: Mon, 01 Aug 2005 20:48:52 -0500 www.mdaemon.ru/forum/ HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 00F9813A Mon, 01 Aug 2005 20:48:54 -0500 www.mdaemon.ru/forum/ HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 00F9813A After server restart - address changed: PHP has encountered an Access Violation at 0109813A Reproduce code: --- I can't reproduce it myself (same pages loaded ok), but there are lot of such dumps in my log. I can install and try any test version there. Expected result: Page load. Actual result: ---
#33942 [Asn->Csd]: the patch to #33156 crash cygwin except cli
ID: 33942 Updated by: [EMAIL PROTECTED] Reported By: xuefer at 21cn dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: cygwin only PHP Version: 5CVS-2005-08-01 (dev) Assigned To: dmitry New Comment: Nuno's patch is applied to CVS HEAD and PHP_5_0. Previous Comments: [2005-08-02 15:10:46] [EMAIL PROTECTED] I've tested fastcgi and it seems to work fine. I've also fixed the indentation in the patch. [2005-08-02 03:06:32] xuefer at 21cn dot com fastcgi, and maybe other sapi except cli/CGI!, as both cli/cgi exit immediately after request shutdown the patch nlopess posted should work (i did it after my report too) but btw, the indention is not consistent with previous patch [2005-08-01 23:25:06] [EMAIL PROTECTED] I've tested the CLI and CGI sapis and eveything works fine. I couldn't test further, because you didn't specify the sapi you were using. Anyway, you are right and I missed the zend_unset_timeout() in my patch. Here is a patch that should fix your problem: http://mega.ist.utl.pt/~ncpl/patch_cygwin_php.txt Please test it. Thanks, Nuno [2005-08-01 12:07:40] [EMAIL PROTECTED] Dmitry, check your patch please. :) [2005-08-01 06:47:30] xuefer at 21cn dot com Description: in reply to: http://bugs.php.net/bug.php?id=33156 (can't open the bug) for CYGWIN in zend_set_timeout() ITIMER_REAL is set in zend_unset_timeout() ITIMER_REAL is NOT unset, but unset ITIMER_PROF instead it has no problem with "make test" as the test won't last long. but with any SAPI other than cli. ITIMER_REAL is triggered after php request is shutdown, result a crash Reproduce code: --- set timeout to 5 ./sapi/php -b 1026 request it with an empty php script wait for 5 second countdown crash -- Edit this bug report at http://bugs.php.net/?id=33942&edit=1
#33958 [Ctl]: Crash with processing HTTP_COOKIE with 'doubled' variables
ID: 33958 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su Status: Critical Bug Type: Reproducible crash Operating System: * PHP Version: 5CVS-2005-08-02 New Comment: [Switching to Thread 46912528940992 (LWP 2360)] 0x2aaab000aec1 in _mem_block_check (ptr=0x55b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:736 736 memcpy(&end_magic, (((char *) p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long)); (gdb) (gdb) bt #0 0x2aaab000aec1 in _mem_block_check (ptr=0x55b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:736 #1 0x2aaab000ae9d in _mem_block_check (ptr=0x55b3a081, silent=1, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:728 #2 0x2aaab0009c39 in _efree (ptr=0x55b3a081, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", __zend_lineno=201, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php/php5/Zend/zend_alloc.c:287 #3 0x2ffe030e in php_register_variable_ex (var=0x55b3a081 "phpbb2mysql_data", val=0x7f839990, track_vars_array=0x55b39ec0) at /usr/src/php/php5/main/php_variables.c:201 #4 0x2ffdfd3c in php_register_variable_safe (var=0x55b3a080 " phpbb2mysql_data", strval=0x557b5500 "a:0:{}", str_len=6, track_vars_array=0x55b39ec0) at /usr/src/php/php5/main/php_variables.c:57 #5 0x2ffe0c8c in php_default_treat_data (arg=2, str=0x0, destArray=0x0) at /usr/src/php/php5/main/php_variables.c:345 #6 0x2ffe1b53 in php_hash_environment () at /usr/src/php/php5/main/php_variables.c:646 #7 0x2ffcf73b in php_request_startup () at /usr/src/php/php5/main/main.c:1064 #8 0x2aaab00b850a in php_apache_request_ctor (r=0x55b23020, ctx=0x55b27a28) at /usr/src/php/php5/sapi/apache2handler/sapi_apache2.c:438 #9 0x2aaab00b8c87 in php_handler (r=0x55b23020) at /usr/src/php/php5/sapi/apache2handler/sapi_apache2.c:534 Previous Comments: [2005-08-02 18:50:58] [EMAIL PROTECTED] Verified with latest CVS and Apache2.. [2005-08-02 08:46:15] andrey at cherezov dot koenig dot su In the PHP 4.3.11 under the same server with the same test request = 200 OK. So this bug is PHP5.1 specific. [2005-08-02 08:33:22] andrey at cherezov dot koenig dot su The way to reproduce: GET /php.php5 HTTP/1.0 Host: localhost Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D; phpbb2mysql_data=a%3A0%3A%7B%7D Connection: close Posted this request (via telnet) to my local web-server and got the same error! (the script php.php5 just "echo 'test'"). PHP has encountered an Access Violation at 00F2813A If I delete second variable copy, i.e.: GET /php.php5 HTTP/1.0 Host: localhost Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D Connection: close - the script works ok. [2005-08-02 03:58:49] andrey at cherezov dot koenig dot su Description: Just downloaded and installed 5.1 snap (2 Aug) and replaced PHP5.1b3 in my server (ISAPI mode). Now I see in log, some users got "error 500" while accessing /forum/ and /forum/viewtopic.php (PhpBB current version). Turn on trace and get error pages: Mon, 01 Aug 2005 20:48:52 -0500 www.mdaemon.ru/forum/ HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 00F9813A Mon, 01 Aug 2005 20:48:54 -0500 www.mdaemon.ru/forum/ HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 00F9813A After server restart - address changed: PHP has encountered an Access Violation at 0109813A Reproduce code: --- I can't reproduce it myself (same pages loaded ok), but there are lot of such dumps in my log. I can install and try any test version there. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 0109813A -- Edit this bug report at http://bugs.php.net/?id=33958&edit=1
#33963 [Fbk->Opn]: Binding some stored procedure parameters fails
ID: 33963 User updated by: paul dot robinson at groupbc dot com Reported By: paul dot robinson at groupbc dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5.0.4 New Comment: Patches suggested are against Snapshot: php5-STABLE-200508021038.tar.gz Although I haven't actually built an example using that snapshot today I have looked at the code which since it is unchanged would seem to exhibit the same problem. Previous Comments: [2005-08-02 18:34:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 13:39:23] paul dot robinson at groupbc dot com Description: Using FreeTDS 0.63 (latest stable release), calling mssql_bind can fail due to the restrictions placed on parameters by the dbrpcparam function from FreeTDS. One specific example is an input parameter must have maxlen==-1. With the code as is in PHP 5.0.4 a NULL valued variable length type input parameter will always have maxlen==0 thereby always failing. Diff below shows changes to ext/mssql/php_mssql.c that address this parameter mismatch. 2025,2026c2025,2029 < maxlen=0; < datalen=0; --- > datalen = 0; > if (is_output) > maxlen = -1; > else > maxlen = -1; 2030d2032 < datalen=Z_STRLEN_PP(var); 2031a2034,2046 > > if (is_output) { > if ((maxlen > 0 ) && (maxlen < 256)) > datalen = maxlen; > else { > maxlen = 255; > datalen = 255; > } > } > else { > maxlen = -1; > datalen=Z_STRLEN_PP(var); > } Reproduce code: --- mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR); or mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR, false, true, 57); Expected result: Sucessfully bind input variable. Actual result: -- "Unable to set parameter" i.e. FAIL is returned by the call to dbrpcparam in PHP_FUNCTION(mssql_bind). -- Edit this bug report at http://bugs.php.net/?id=33963&edit=1
#33958 [Opn->Ctl]: Crash with processing HTTP_COOKIE with 'doubled' variables
ID: 33958 Updated by: [EMAIL PROTECTED] -Summary: Access Violation on processing HTTP_COOKIE with 'doubled' variables (ISAPI) Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Critical Bug Type: Reproducible crash -Operating System: Windows 2003 +Operating System: * -PHP Version: 5CVS-2005-08-02 (dev) +PHP Version: 5CVS-2005-08-02 New Comment: Verified with latest CVS and Apache2.. Previous Comments: [2005-08-02 08:46:15] andrey at cherezov dot koenig dot su In the PHP 4.3.11 under the same server with the same test request = 200 OK. So this bug is PHP5.1 specific. [2005-08-02 08:33:22] andrey at cherezov dot koenig dot su The way to reproduce: GET /php.php5 HTTP/1.0 Host: localhost Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D; phpbb2mysql_data=a%3A0%3A%7B%7D Connection: close Posted this request (via telnet) to my local web-server and got the same error! (the script php.php5 just "echo 'test'"). PHP has encountered an Access Violation at 00F2813A If I delete second variable copy, i.e.: GET /php.php5 HTTP/1.0 Host: localhost Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D Connection: close - the script works ok. [2005-08-02 08:32:33] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-08-02 08:22:16] andrey at cherezov dot koenig dot su Dear Sniper! If you've already have this COOKIE problem in the bugs database - please let me know, I've not found it :( Now I'm sure, it is reproducible crash - it _always_ happens when there is _two variables with the same name_ in the HTTP_COOKIE. All latest "500 error" have such doubled vars. Users from these IPs (below) can't work at all - any request to any PHP script on the site failes with 500. Others work w/o any problems. 2005-08-01 22:31:42;195.46.121.102 "phpbb2mysql_data=a%3A0%3A%7B%7D; phpbb2mysql_data=a%3A0%3A%7B%7D; phpbb2mysql_sid=47f1a774212623ea22c95933b707d9d0" 2005-08-01 23:50:44;213.148.164.89 "phpbb2mysql_data=a%3A0%3A%7B%7D; phpbb2mysql_data=a%3A0%3A%7B%7D" 2005-08-02 00:19:00;80.92.194.174 "phpbb2mysql_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A32%3A%22cc17e49473154b6dc50e5493e79d5283%22%3Bs%3A6%3A%22userid%22%3Bi%3A1411%3B%7D; phpbb2mysql_data=a%3A0%3A%7B%7D" [2005-08-02 03:58:49] andrey at cherezov dot koenig dot su Description: Just downloaded and installed 5.1 snap (2 Aug) and replaced PHP5.1b3 in my server (ISAPI mode). Now I see in log, some users got "error 500" while accessing /forum/ and /forum/viewtopic.php (PhpBB current version). Turn on trace and get error pages: Mon, 01 Aug 2005 20:48:52 -0500 www.mdaemon.ru/forum/ HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 00F9813A Mon, 01 Aug 2005 20:48:54 -0500 www.mdaemon.ru/forum/ HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 00F9813A After server restart - address changed: PHP has encountered an Access Violation at 0109813A Reproduce code: --- I can't reproduce it myself (same pages loaded ok), but there are lot of such dumps in my log. I can install and try any test version there. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 0109813A -- Edit this bug report at http://bugs.php.net/?id=33958&edit=1
#33965 [Fbk->Opn]: NULL valued output parameters from stored procedures contain corrupt data
ID: 33965 User updated by: paul dot robinson at groupbc dot com Reported By: paul dot robinson at groupbc dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5.0.4 New Comment: Patches suggested are against Snapshot: php5-STABLE-200508021038.tar.gz Although I haven't actually built an example using that snapshot today I have looked at the code which since it is unchanged would seem to exhibit the same problem. Previous Comments: [2005-08-02 18:34:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 14:01:38] paul dot robinson at groupbc dot com Description: MS SQL Server 2000, FreeTDS 0.63 Output parameters from a stored procedure call contain corrupt data when the result should be NULL. Its particularly noticable for variable length strings as output looks as though it just reads from a random pointer until it find a \0 ! No test is done on whether the output is NULL or not. Diff below shows proposed change to fix this. NOTE: This calls a function dbretisnull that is not currently implemented in the FreeTDS package but has been submitted as a proposed change. 19c19 < /* $Id: php_mssql.c,v 1.137.2.9 2005/04/12 17:46:06 fmk Exp $ */ --- > /* $Id: php_mssql.c,v 1.137.2.8 2005/02/25 23:25:33 fmk Exp $ */ 324,326d323 < #ifndef HAVE_FREETDS < dbwinexit(); < #else 328d324 < #endif 978c974 < int i, num_rets, type; --- > int i, num_rets, type, is_null; 992,1019c988,1022 < switch (type) { < case SQLBIT: < case SQLINT1: < case SQLINT2: < case SQLINT4: < convert_to_long_ex(&bind->zval); < /* FIXME this works only on little endian machine !!! */ < Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLFLT4: < case SQLFLT8: < case SQLFLTN: < case SQLMONEY4: < case SQLMONEY: < case SQLMONEYN: < convert_to_double_ex(&bind->zval); < Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLCHAR: < case SQLVARCHAR: < case SQLTEXT: < convert_to_string_ex(&bind->zval); < Z_STRLEN_P(bind->zval) = dbretlen(mssql_ptr->link,i); < Z_STRVAL_P(bind->zval) = estrndup(dbretdata(mssql_ptr->link,i),Z_STRLEN_P(bind->zval)); < break; < /* TODO binary */ --- > /* Test column value for null flag and set value as required */ > is_null = dbretisnull(mssql_ptr->link, i); > if (is_null) { > ZVAL_NULL(bind->zval); > } > else { > switch (type) { > case SQLBIT: > case SQLINT1: > case SQLINT2: > case SQLINT4: > convert_to_long_ex(&bind->zval); > /* FIXME this works only on little endian machine !!! */ > Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); > brea
#33960 [Opn->Bgs]: fsockopen() timeout parameter has no function
ID: 33960 Updated by: [EMAIL PROTECTED] Reported By: cyberline at techno4ever dot net -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: Suse 9.3 PHP Version: 5.0.4 New Comment: See bug #24867 (you propably have error_reporting set too low or you're not displaying errors or you simply didn't paste the error here, so I'm guessing) Also, RTFM: "Note: If you need to set a timeout for reading/writing data over the socket, use stream_set_timeout(), as the timeout parameter to fsockopen() only applies while connecting the socket." Previous Comments: [2005-08-02 10:27:39] cyberline at techno4ever dot net Description: When i set a timelimit for fsockopen() the script won't stop after the limit reaches. Reproduce code: --- if($fp = fsockopen($host, $port, &$errno, &$errnum, 2)) { ... } Expected result: When the checked host is offline, the script reported that afetr 2 seconds. Actual result: -- The Script is stopping after 60 seconds. -- Edit this bug report at http://bugs.php.net/?id=33960&edit=1
#33963 [Opn->Fbk]: Binding some stored procedure parameters fails
ID: 33963 Updated by: [EMAIL PROTECTED] Reported By: paul dot robinson at groupbc dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-08-02 13:39:23] paul dot robinson at groupbc dot com Description: Using FreeTDS 0.63 (latest stable release), calling mssql_bind can fail due to the restrictions placed on parameters by the dbrpcparam function from FreeTDS. One specific example is an input parameter must have maxlen==-1. With the code as is in PHP 5.0.4 a NULL valued variable length type input parameter will always have maxlen==0 thereby always failing. Diff below shows changes to ext/mssql/php_mssql.c that address this parameter mismatch. 2025,2026c2025,2029 < maxlen=0; < datalen=0; --- > datalen = 0; > if (is_output) > maxlen = -1; > else > maxlen = -1; 2030d2032 < datalen=Z_STRLEN_PP(var); 2031a2034,2046 > > if (is_output) { > if ((maxlen > 0 ) && (maxlen < 256)) > datalen = maxlen; > else { > maxlen = 255; > datalen = 255; > } > } > else { > maxlen = -1; > datalen=Z_STRLEN_PP(var); > } Reproduce code: --- mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR); or mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR, false, true, 57); Expected result: Sucessfully bind input variable. Actual result: -- "Unable to set parameter" i.e. FAIL is returned by the call to dbrpcparam in PHP_FUNCTION(mssql_bind). -- Edit this bug report at http://bugs.php.net/?id=33963&edit=1
#33965 [Opn->Fbk]: NULL valued output parameters from stored procedures contain corrupt data
ID: 33965 Updated by: [EMAIL PROTECTED] Reported By: paul dot robinson at groupbc dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-08-02 14:01:38] paul dot robinson at groupbc dot com Description: MS SQL Server 2000, FreeTDS 0.63 Output parameters from a stored procedure call contain corrupt data when the result should be NULL. Its particularly noticable for variable length strings as output looks as though it just reads from a random pointer until it find a \0 ! No test is done on whether the output is NULL or not. Diff below shows proposed change to fix this. NOTE: This calls a function dbretisnull that is not currently implemented in the FreeTDS package but has been submitted as a proposed change. 19c19 < /* $Id: php_mssql.c,v 1.137.2.9 2005/04/12 17:46:06 fmk Exp $ */ --- > /* $Id: php_mssql.c,v 1.137.2.8 2005/02/25 23:25:33 fmk Exp $ */ 324,326d323 < #ifndef HAVE_FREETDS < dbwinexit(); < #else 328d324 < #endif 978c974 < int i, num_rets, type; --- > int i, num_rets, type, is_null; 992,1019c988,1022 < switch (type) { < case SQLBIT: < case SQLINT1: < case SQLINT2: < case SQLINT4: < convert_to_long_ex(&bind->zval); < /* FIXME this works only on little endian machine !!! */ < Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLFLT4: < case SQLFLT8: < case SQLFLTN: < case SQLMONEY4: < case SQLMONEY: < case SQLMONEYN: < convert_to_double_ex(&bind->zval); < Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLCHAR: < case SQLVARCHAR: < case SQLTEXT: < convert_to_string_ex(&bind->zval); < Z_STRLEN_P(bind->zval) = dbretlen(mssql_ptr->link,i); < Z_STRVAL_P(bind->zval) = estrndup(dbretdata(mssql_ptr->link,i),Z_STRLEN_P(bind->zval)); < break; < /* TODO binary */ --- > /* Test column value for null flag and set value as required */ > is_null = dbretisnull(mssql_ptr->link, i); > if (is_null) { > ZVAL_NULL(bind->zval); > } > else { > switch (type) { > case SQLBIT: > case SQLINT1: > case SQLINT2: > case SQLINT4: > convert_to_long_ex(&bind->zval); > /* FIXME this works only on little endian machine !!! */ > Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); > break; > > case SQLFLT4: > case SQLFLT8: > case SQLFLTN: > case SQLMONEY4: > case SQLMONEY: >
#33966 [Opn->Ver]: wrong use of reflectionproperty causes a segfault
ID: 33966 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Class/Object related -Operating System: Linux (Debian) +Operating System: * -PHP Version: 5CVS-2005-08-02 (dev) +PHP Version: 5CVS-2005-08-02 Previous Comments: [2005-08-02 14:23:59] [EMAIL PROTECTED] Description: When (ab)using the ReflectionProperty class' methods as static, it segfaults. Reproduce code: --- foo; ?> Actual result: -- 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 3359RETURN_BOOL(ref->prop->flags & mask); (gdb) bt #0 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 #1 0x083c2c24 in zif_reflection_property_isPublic (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3366 #2 0x083c6309 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffd090) at zend_vm_execute.h:184 #3 0x083c692d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffd090) at zend_vm_execute.h:299 #4 0x083c5f8a in execute (op_array=0x878dd34) at zend_vm_execute.h:87 #5 0x0838edc6 in zend_call_function (fci=0xbfffd260, fci_cache=0xbfffd220) at /dat/dev/php/php-5.1dev/Zend/zend_execute_API.c:871 #6 0x083aee9d in zend_call_method (object_pp=0xbfffd2f0, obj_ce=0x878c36c, fn_proxy=0x878c44c, function_name=0x85cfd54 "__get", function_name_len=5, retval_ptr_ptr=0xbfffd2e4, param_count=1, arg1=0x878cea4, arg2=0x0) at /dat/dev/php/php-5.1dev/Zend/zend_interfaces.c:87 #7 0x083b4e26 in zend_std_call_getter (object=0x878c714, member=0x878cea4) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:72 #8 0x083b576e in zend_std_read_property (object=0x878c714, member=0x878b148, type=0) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:305 #9 0x083ff3f9 in zend_fetch_property_address_read_helper_SPEC_CV_CONST ( type=0, execute_data=0xbfffd440) at zend_vm_execute.h:20491 #10 0x083ff510 in ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER ( execute_data=0xbfffd440) at zend_vm_execute.h:20513 #11 0x083c5f8a in execute (op_array=0x8786de4) at zend_vm_execute.h:87 #12 0x0839b2fb in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /dat/dev/php/php-5.1dev/Zend/zend.c:1087 #13 0x08350fc4 in php_execute_script (primary_file=0xb8b0) at /dat/dev/php/php-5.1dev/main/main.c:1672 #14 0x0841325c in main (argc=1, argv=0xb994) at /dat/dev/php/php-5.1dev/sapi/cli/php_cli.c:1039 (gdb) print *ref Cannot access memory at address 0x2a8fcc84 -- Edit this bug report at http://bugs.php.net/?id=33966&edit=1
#33967 [Opn->Csd]: misuse of Exception constructor doesn't display errorfile
ID: 33967 Updated by: [EMAIL PROTECTED] Reported By: benjamin at schulz dot name -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: linux PHP Version: 5.1.0b3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-08-02 15:34:07] benjamin at schulz dot name Description: If the Exception constructor or a child class gets an object as argument the errormessage doesn't contain a file or line what makes it hard to track down because in <5.1 or even <= 5.1.0b2 (not sure) it was possible to use different prototypes in Exception children Reproduce code: --- Actual result: -- Fatal error: Wrong parameter count for exception([string $exception [, long $code ]]) in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=33967&edit=1
#33970 [Opn->Fbk]: Seg fault when error should be returned
ID: 33970 Updated by: [EMAIL PROTECTED] Reported By: lists at cyberlot dot net -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Fedora Core 3 PHP Version: 5.1.0b3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-08-02 17:40:59] lists at cyberlot dot net Description: Running this script seg faults instead of producing a reasonable error. Reproduce code: --- $dsn = "mysql:dbname=123;host=localhost"; $dbuser = "123"; $dbpass = "123"; class PDO_Dynamic extends PDO { private $dsn; private $dbuser; private $dbpass; function PDO_Dynamic($dsn, $dbuser, $dbpass) { $this->dsn = $dsn; $this->dbuser = $dbuser; $this->dbpass = $dbpass; $temp = $this->PDO($dsn, $dbuser, $dbpass); } } $db_read = new PDO_Dynamic($dsn, $dbuser, $dbpass); $db_write = new PDO_Dynamic($dsn, $dbuser, $dbpass.'-'); Expected result: No error at all expected, or at least some sort of warning/fault Actual result: -- #0 0x08130533 in pdo_hash_methods (dbh=0x9e189b4, kind=0) at /root/sources/php-5.1.0b3/ext/pdo/pdo_dbh.c:990 #1 0x081308bf in dbh_method_get (object_pp=0xbffb5294, method_name=0x9e1baa4 "PDO", method_len=3) at /root/sources/php-5.1.0b3/ext/pdo/pdo_dbh.c:1065 #2 0x0833f150 in ZEND_INIT_METHOD_CALL_SPEC_UNUSED_CONST_HANDLER (execute_data=0xbffb5270) at zend_vm_execute.h:14663 #3 0x08317eeb in execute (op_array=0x9e1b52c) at zend_vm_execute.h:87 #4 0x0831835b in zend_do_fcall_common_helper_SPEC (execute_data=0xbffb54a0) at zend_vm_execute.h:213 #5 0x08318a73 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbffb54a0) at zend_vm_execute.h:299 #6 0x08317eeb in execute (op_array=0x9e140ac) at zend_vm_execute.h:87 #7 0x082f19f9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/sources/php-5.1.0b3/Zend/zend.c:1087 #8 0x082b0a9d in php_execute_script (primary_file=0xbffb78d0) at /root/sources/php-5.1.0b3/main/main.c:1672 #9 0x0835ce9b in main (argc=2, argv=0xbffb79a4) at /root/sources/php-5.1.0b3/sapi/cli/php_cli.c:1039 -- Edit this bug report at http://bugs.php.net/?id=33970&edit=1
#33964 [Opn->Fbk]: ifx.ec : syntax error before '/' token
ID: 33964 Updated by: [EMAIL PROTECTED] Reported By: jmserra at pereserra dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Linux Fedora Core 4 PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-08-02 13:54:49] jmserra at pereserra dot net Description: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml works fine , after executing 'make' outputs that syntax error versions: *Informix IDS v9.4 32bit *GNU libtool 1.5.16 *make 3.8 Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml make Expected result: i expected that make outut no errors Actual result: -- /bin/sh /root/php-5.0.4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/informix//incl/esql -Iext/informix/ -I/root/php-5.0.4/ext/informix/ -DPHP_ATOM_INC -I/root/php-5.0.4/include -I/root/php-5.0.4/main -I/root/php-5.0.4 -I/usr/include/mysql -I/root/php-5.0.4/TSRM -I/root/php-5.0.4/Zend -g -O2 -prefer-non-pic -c /root/php-5.0.4/ext/informix/ifx.c -o ext/informix/ifx.lo /root/php-5.0.4/ext/informix/ifx.ec: In function 'zm_info_ifx': /root/php-5.0.4/ext/informix/ifx.ec:452: error: syntax error before '/' token /root/php-5.0.4/ext/informix/ifx.ec:3241:17: error: operator '<' has no left operand make: *** [ext/informix/ifx.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=33964&edit=1
#33956 [Opn->Bgs]: Undefined reference; Cannot find libssl.
ID: 33956 Updated by: [EMAIL PROTECTED] Reported By: Jaguar at digitalmarble dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Debian Linux 3.1 Sarge r0a i386 PHP Version: 4.4.0 New Comment: You don't have the path to libz in your /etc/ld.so.conf.. And you don't install the openssl.pc in right place. This should output something: # pkg-config --libs openssl Nevertheless: Not PHP bug. Previous Comments: [2005-08-02 12:05:55] Jaguar at digitalmarble dot com Regardless, if I recompile openssl without zlib this error disappears and php builds. Only problem is, I'd like to use zlib. If it is a system error, give me a helpful hint here and I'll start my hunt for it and leave you good people alone :). [2005-08-02 07:52:52] [EMAIL PROTECTED] We can't do miracles here..just fix your system, it's pretty screwed up right now. [2005-08-02 03:01:14] Jaguar at digitalmarble dot com Description: libssl not found! Or so it says. Upon configuring extensions configure dies "checking for SSL_CTX_set_ssl_version in -lss...". I know it has something to do with zlib 1.2.3 as I had the same problem when I configured apache 2.0.54. I resolved it with the configure flag --enable-deflate in apache but php (unless I missed it) doesn't seem to have such an option. I configured zlib in with openssl 0.9.8 and the configured openssl into apache (which required a patch due to some problems between apache 2.0.54, openssl 0.9.8 and zlib 1.2.2+). I suspect the problem is with zlib but that's all I can decipher. I have libssl.so.0.9.7 every possible place I could think configure would look. I scoured google and tried countless forum suggestions. I'm working off php 4.4.0 cvs snapshot august 1st 2005. Perhaps someone can help? Reproduce code: --- ./configure --with-openssl=/usr/local/ssl --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql --with-bz2 --with-zlib=/usr/local --with-mcrypt=/usr --enable-ftp --with-regex=apache --with-swf Actual result: -- ./configure output -- SNIPPET -- checking for SSL_CTX_set_ssl_version in -lssl... no configure: error: libssl not found! -- END SNIPPET -- config.log -- SNIPPET -- configure:18083: checking for SSL_CTX_set_ssl_version in -lssl configure:18102: gcc -o conftest -g -O2 -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib conftest.c -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypto 1>&5 /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x78): In function `zlib_stateful_init': : undefined reference to `inflateInit_' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0xd7): In function `zlib_stateful_init': : undefined reference to `deflateInit_' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x290): In function `zlib_stateful_compress_block': : undefined reference to `deflate' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x315): In function `zlib_stateful_expand_block': : undefined reference to `inflate' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x33f): In function `zlib_stateful_free_ex_data': : undefined reference to `inflateEnd' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x34a): In function `zlib_stateful_free_ex_data': : undefined reference to `deflateEnd' collect2: ld returned 1 exit status configure: failed program was: #line 18091 "configure" #include "confdefs.h" -- END SNIPPET -- -- Edit this bug report at http://bugs.php.net/?id=33956&edit=1
#33970 [NEW]: Seg fault when error should be returned
From: lists at cyberlot dot net Operating system: Fedora Core 3 PHP version: 5.1.0b3 PHP Bug Type: PDO related Bug description: Seg fault when error should be returned Description: Running this script seg faults instead of producing a reasonable error. Reproduce code: --- $dsn = "mysql:dbname=123;host=localhost"; $dbuser = "123"; $dbpass = "123"; class PDO_Dynamic extends PDO { private $dsn; private $dbuser; private $dbpass; function PDO_Dynamic($dsn, $dbuser, $dbpass) { $this->dsn = $dsn; $this->dbuser = $dbuser; $this->dbpass = $dbpass; $temp = $this->PDO($dsn, $dbuser, $dbpass); } } $db_read = new PDO_Dynamic($dsn, $dbuser, $dbpass); $db_write = new PDO_Dynamic($dsn, $dbuser, $dbpass.'-'); Expected result: No error at all expected, or at least some sort of warning/fault Actual result: -- #0 0x08130533 in pdo_hash_methods (dbh=0x9e189b4, kind=0) at /root/sources/php-5.1.0b3/ext/pdo/pdo_dbh.c:990 #1 0x081308bf in dbh_method_get (object_pp=0xbffb5294, method_name=0x9e1baa4 "PDO", method_len=3) at /root/sources/php-5.1.0b3/ext/pdo/pdo_dbh.c:1065 #2 0x0833f150 in ZEND_INIT_METHOD_CALL_SPEC_UNUSED_CONST_HANDLER (execute_data=0xbffb5270) at zend_vm_execute.h:14663 #3 0x08317eeb in execute (op_array=0x9e1b52c) at zend_vm_execute.h:87 #4 0x0831835b in zend_do_fcall_common_helper_SPEC (execute_data=0xbffb54a0) at zend_vm_execute.h:213 #5 0x08318a73 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbffb54a0) at zend_vm_execute.h:299 #6 0x08317eeb in execute (op_array=0x9e140ac) at zend_vm_execute.h:87 #7 0x082f19f9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/sources/php-5.1.0b3/Zend/zend.c:1087 #8 0x082b0a9d in php_execute_script (primary_file=0xbffb78d0) at /root/sources/php-5.1.0b3/main/main.c:1672 #9 0x0835ce9b in main (argc=2, argv=0xbffb79a4) at /root/sources/php-5.1.0b3/sapi/cli/php_cli.c:1039 -- Edit bug report at http://bugs.php.net/?id=33970&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33970&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33970&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33970&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33970&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33970&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33970&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33970&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33970&r=support Expected behavior: http://bugs.php.net/fix.php?id=33970&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33970&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33970&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33970&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33970&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33970&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33970&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33970&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33970&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33970&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33970&r=mysqlcfg
#33969 [Opn->Bgs]: No out
ID: 33969 Updated by: [EMAIL PROTECTED] Reported By: webmaster at ebv dot com dot br -Status: Open +Status: Bogus Bug Type: Output Control Operating System: case PHP Version: 4.3.11 New Comment: You have discovered octal numbers. Remove the leading 0's or put qoutes around them to treat them as strings. Previous Comments: [2005-08-02 17:02:32] webmaster at ebv dot com dot br Description: case no out 08 and 09 O Case não retorna! 08 e 09 Reproduce code: --- echo $atemes = '08'; switch($atemes) { case 01: echo $messql2 = 'Jan'; break; case 08: echo $messql2 = 'Aug'; break; case 09: echo $messql2 = 'Sep'; break; } Expected result: case "01" ok --- "01" or "1" case "02" ok ... case "08" beee! NO!! (case 8 ok) --> 08 no 8 yes (only) case "09" beee! NO!! (case 9 ok) --> 09 no 9 yes (only) case "10" ok ... Actual result: -- echo "mes 1 ".$messql.""; echo "atmes ".$atemes.""; echo $atemes = '08'; switch($atemes) { case 01: echo $messql2 = 'Jan'; break; case 8: echo $messql2 = 'Aug'; break; case 9: echo $messql2 = 'Sep'; break; } -- Edit this bug report at http://bugs.php.net/?id=33969&edit=1
#33969 [NEW]: No out
From: webmaster at ebv dot com dot br Operating system: case PHP version: 4.3.11 PHP Bug Type: Output Control Bug description: No out Description: case no out 08 and 09 O Case não retorna! 08 e 09 Reproduce code: --- echo $atemes = '08'; switch($atemes) { case 01: echo $messql2 = 'Jan'; break; case 08: echo $messql2 = 'Aug'; break; case 09: echo $messql2 = 'Sep'; break; } Expected result: case "01" ok --- "01" or "1" case "02" ok ... case "08" beee! NO!! (case 8 ok) --> 08 no 8 yes (only) case "09" beee! NO!! (case 9 ok) --> 09 no 9 yes (only) case "10" ok ... Actual result: -- echo "mes 1 ".$messql.""; echo "atmes ".$atemes.""; echo $atemes = '08'; switch($atemes) { case 01: echo $messql2 = 'Jan'; break; case 8: echo $messql2 = 'Aug'; break; case 9: echo $messql2 = 'Sep'; break; } -- Edit bug report at http://bugs.php.net/?id=33969&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33969&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33969&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33969&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33969&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33969&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33969&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33969&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33969&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33969&r=support Expected behavior: http://bugs.php.net/fix.php?id=33969&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33969&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33969&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33969&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33969&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33969&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33969&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33969&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33969&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33969&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33969&r=mysqlcfg
#33957 [Asn]: gmdate('W')/date('W') sometimes returns wrong week number.
ID: 33957 User updated by: paul at stunning-stuff dot com Reported By: paul at stunning-stuff dot com Status: Assigned Bug Type: Date/time related Operating System: Windows XP Pro PHP Version: 5.1.0b3 Assigned To: derick New Comment: Thanks for your quick reply and thanks for doing such a great job on PHP. You dev's really make this the best open source language today. I hope you are able to solve this problem (I'm sure you will). One more note though: This problem should reoccur every 28 years before and after 1992. This might help you in your testing. Thanks, Paul van der Maas --- www.stunning-stuff.com Previous Comments: [2005-08-02 16:22:09] [EMAIL PROTECTED] Indeed a bug, will have a look at it - thanks for the reproducable case. [2005-08-02 16:19:09] paul at stunning-stuff dot com Here is some example code to reproduce the problem: '; $timestamp = gmmktime(12, 0, 0, 12, 29, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 30, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 31, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 28, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 29, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 30, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 31, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; ?> Expected result: Week number for Mon Dec 28, 1992 12:00:00: 53 Week number for Tue Dec 29, 1992 12:00:00: 53 Week number for Wed Dec 30, 1992 12:00:00: 53 Week number for Thu Dec 31, 1992 12:00:00: 53 Week number for Mon Dec 28, 2020 12:00:00: 53 Week number for Tue Dec 29, 2020 12:00:00: 53 Week number for Wed Dec 30, 2020 12:00:00: 53 Week number for Thu Dec 31, 2020 12:00:00: 53 Actual result: Week number for Mon Dec 28, 1992 12:00:00: 1 Week number for Tue Dec 29, 1992 12:00:00: 1 Week number for Wed Dec 30, 1992 12:00:00: 1 Week number for Thu Dec 31, 1992 12:00:00: 1 Week number for Mon Dec 28, 2020 12:00:00: 1 Week number for Tue Dec 29, 2020 12:00:00: 1 Week number for Wed Dec 30, 2020 12:00:00: 1 Week number for Thu Dec 31, 2020 12:00:00: 1 Check http://www.timeanddate.com/calendar/custom.html?year=1992&month=12&typ=1&display=1&wno=1 and http://www.timeanddate.com/calendar/custom.html?year=2020&month=12&typ=1&display=1&wno=1 to see these expected results confirmed. Sorry for the bulky post, but this way there is no room for misinterpretation. Thanks, Paul van der Maas --- www.stunning-stuff.com [2005-08-02 07:55:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-08-02 03:27:51] paul at stunning-stuff dot com Description: Hi, While I was writing my own getWeekNumber method I discovered gmdate('W') and date('W') both return incorrect results for the year 1992 and 2020. Both years end on a thursday and both are leap years. I'm guessing that this is exactly the reason they return incorrect results :). Expected result: The last 4 days in 1992 and 2020 belong to week 53 of those years according to ISO 8601 rules. Actual result: gmdate('W') and date('W') think the last 4 days of 1992 and 2020 belong to week 1 of the following year. I only had the time to test these two years, but I expect that PHP will return the incorrect week number for every leap year that ends with a thursday. Thanks, Paul van der Maas --- www.stunning-stuff.com -- Edit this bug report at http://bugs.php.net/?id=33957&edit=1
#33957 [Opn->Asn]: gmdate('W')/date('W') sometimes returns wrong week number.
ID: 33957 Updated by: [EMAIL PROTECTED] Reported By: paul at stunning-stuff dot com -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Windows XP Pro PHP Version: 5.1.0b3 -Assigned To: +Assigned To: derick New Comment: Indeed a bug, will have a look at it - thanks for the reproducable case. Previous Comments: [2005-08-02 16:19:09] paul at stunning-stuff dot com Here is some example code to reproduce the problem: '; $timestamp = gmmktime(12, 0, 0, 12, 29, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 30, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 31, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 28, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 29, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 30, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 31, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; ?> Expected result: Week number for Mon Dec 28, 1992 12:00:00: 53 Week number for Tue Dec 29, 1992 12:00:00: 53 Week number for Wed Dec 30, 1992 12:00:00: 53 Week number for Thu Dec 31, 1992 12:00:00: 53 Week number for Mon Dec 28, 2020 12:00:00: 53 Week number for Tue Dec 29, 2020 12:00:00: 53 Week number for Wed Dec 30, 2020 12:00:00: 53 Week number for Thu Dec 31, 2020 12:00:00: 53 Actual result: Week number for Mon Dec 28, 1992 12:00:00: 1 Week number for Tue Dec 29, 1992 12:00:00: 1 Week number for Wed Dec 30, 1992 12:00:00: 1 Week number for Thu Dec 31, 1992 12:00:00: 1 Week number for Mon Dec 28, 2020 12:00:00: 1 Week number for Tue Dec 29, 2020 12:00:00: 1 Week number for Wed Dec 30, 2020 12:00:00: 1 Week number for Thu Dec 31, 2020 12:00:00: 1 Check http://www.timeanddate.com/calendar/custom.html?year=1992&month=12&typ=1&display=1&wno=1 and http://www.timeanddate.com/calendar/custom.html?year=2020&month=12&typ=1&display=1&wno=1 to see these expected results confirmed. Sorry for the bulky post, but this way there is no room for misinterpretation. Thanks, Paul van der Maas --- www.stunning-stuff.com [2005-08-02 07:55:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-08-02 03:27:51] paul at stunning-stuff dot com Description: Hi, While I was writing my own getWeekNumber method I discovered gmdate('W') and date('W') both return incorrect results for the year 1992 and 2020. Both years end on a thursday and both are leap years. I'm guessing that this is exactly the reason they return incorrect results :). Expected result: The last 4 days in 1992 and 2020 belong to week 53 of those years according to ISO 8601 rules. Actual result: gmdate('W') and date('W') think the last 4 days of 1992 and 2020 belong to week 1 of the following year. I only had the time to test these two years, but I expect that PHP will return the incorrect week number for every leap year that ends with a thursday. Thanks, Paul van der Maas --- www.stunning-stuff.com -- Edit this bug report at http://bugs.php.net/?id=33957&edit=1
#33957 [Fbk->Opn]: gmdate('W')/date('W') sometimes returns wrong week number.
ID: 33957 User updated by: paul at stunning-stuff dot com Reported By: paul at stunning-stuff dot com -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Windows XP Pro PHP Version: 5.1.0b3 New Comment: Here is some example code to reproduce the problem: '; $timestamp = gmmktime(12, 0, 0, 12, 29, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 30, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 31, 1992); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 28, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 29, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 30, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; $timestamp = gmmktime(12, 0, 0, 12, 31, 2020); echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' . gmdate('W', $timestamp) . ''; ?> Expected result: Week number for Mon Dec 28, 1992 12:00:00: 53 Week number for Tue Dec 29, 1992 12:00:00: 53 Week number for Wed Dec 30, 1992 12:00:00: 53 Week number for Thu Dec 31, 1992 12:00:00: 53 Week number for Mon Dec 28, 2020 12:00:00: 53 Week number for Tue Dec 29, 2020 12:00:00: 53 Week number for Wed Dec 30, 2020 12:00:00: 53 Week number for Thu Dec 31, 2020 12:00:00: 53 Actual result: Week number for Mon Dec 28, 1992 12:00:00: 1 Week number for Tue Dec 29, 1992 12:00:00: 1 Week number for Wed Dec 30, 1992 12:00:00: 1 Week number for Thu Dec 31, 1992 12:00:00: 1 Week number for Mon Dec 28, 2020 12:00:00: 1 Week number for Tue Dec 29, 2020 12:00:00: 1 Week number for Wed Dec 30, 2020 12:00:00: 1 Week number for Thu Dec 31, 2020 12:00:00: 1 Check http://www.timeanddate.com/calendar/custom.html?year=1992&month=12&typ=1&display=1&wno=1 and http://www.timeanddate.com/calendar/custom.html?year=2020&month=12&typ=1&display=1&wno=1 to see these expected results confirmed. Sorry for the bulky post, but this way there is no room for misinterpretation. Thanks, Paul van der Maas --- www.stunning-stuff.com Previous Comments: [2005-08-02 07:55:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-08-02 03:27:51] paul at stunning-stuff dot com Description: Hi, While I was writing my own getWeekNumber method I discovered gmdate('W') and date('W') both return incorrect results for the year 1992 and 2020. Both years end on a thursday and both are leap years. I'm guessing that this is exactly the reason they return incorrect results :). Expected result: The last 4 days in 1992 and 2020 belong to week 53 of those years according to ISO 8601 rules. Actual result: gmdate('W') and date('W') think the last 4 days of 1992 and 2020 belong to week 1 of the following year. I only had the time to test these two years, but I expect that PHP will return the incorrect week number for every leap year that ends with a thursday. Thanks, Paul van der Maas --- www.stunning-stuff.com -- Edit this bug report at http://bugs.php.net/?id=33957&edit=1
#33967 [NEW]: pdo-pgsql crashes by PDO_FETCH_LAZY attribute
From: benjamin at schulz dot name Operating system: linux PHP version: 5.1.0b3 PHP Bug Type: Unknown/Other Function Bug description: pdo-pgsql crashes by PDO_FETCH_LAZY attribute Description: If the Exception constructor or a child class gets an object as argument the errormessage doesn't contain a file or line what makes it hard to track down because in <5.1 or even <= 5.1.0b2 (not sure) it was possible to use different prototypes in Exception children Reproduce code: --- Actual result: -- Fatal error: Wrong parameter count for exception([string $exception [, long $code ]]) in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=33967&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33967&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33967&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33967&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33967&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33967&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33967&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33967&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33967&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33967&r=support Expected behavior: http://bugs.php.net/fix.php?id=33967&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33967&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33967&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33967&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33967&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33967&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33967&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33967&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33967&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33967&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33967&r=mysqlcfg
#33912 [Com]: Crash when trying to access registry using com
ID: 33912 Comment by: terrafrost at gmail dot com Reported By: awsewell at catawba dot edu Status: Assigned Bug Type: COM related Operating System: Windows XP PHP Version: 5CVS-2005-07-29 Assigned To: wez New Comment: Doesn't seem to work on the latest beta of PHP5, but it works on PHP4... EnumKey(HKEY_LOCAL_MACHINE, $keyPath, &$keys); $keys = $keys->value; foreach($keys as $key){ print "$key\n"; } ?> Previous Comments: [2005-08-02 00:49:14] terrafrost at gmail dot com EnumKey's first variable isn't supposed to be a string - it's supposed to be an int. The number representing HKEY_LOCAL_MACHINE is 0x8002. Check out the following link for more information: http://msdn.microsoft.com/library/en-us/wmisdk/wmi/enumkey_method_in_class_stdregprov.asp That said, even when "HKEY_LOCAL_MACHINE" is replaced with 0x8002 in awsewell's code, the code still doesn't work as it should. The problem would seem to be due to arrays not being passed by reference. I say that because in vBScript, they do seem to be (just check out the examples in the link I provided). [2005-07-28 23:41:02] awsewell at catawba dot edu I tried the latest version via the link provided and get the same results. [2005-07-28 23:34:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-28 23:30:55] awsewell at catawba dot edu Description: When trying to use php 5.04 to access the registry with the code below PHP crashes. Reproduce code: --- EnumKey("HKEY_LOCAL_MACHINE", $keyPath, $keys); foreach($keys as $key){ print $key; } unset($wshShell); ?> Expected result: I execpt to see the list of subkeys from the registry. Actual result: -- PHP crashes with only "CLI has encountered a problem and needs to close. We are sorry for the inconvenience." -- Edit this bug report at http://bugs.php.net/?id=33912&edit=1
#33942 [Asn]: the patch to #33156 crash cygwin except cli
ID: 33942 Updated by: [EMAIL PROTECTED] Reported By: xuefer at 21cn dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: cygwin only PHP Version: 5CVS-2005-08-01 (dev) Assigned To: dmitry New Comment: I've tested fastcgi and it seems to work fine. I've also fixed the indentation in the patch. Previous Comments: [2005-08-02 03:06:32] xuefer at 21cn dot com fastcgi, and maybe other sapi except cli/CGI!, as both cli/cgi exit immediately after request shutdown the patch nlopess posted should work (i did it after my report too) but btw, the indention is not consistent with previous patch [2005-08-01 23:25:06] [EMAIL PROTECTED] I've tested the CLI and CGI sapis and eveything works fine. I couldn't test further, because you didn't specify the sapi you were using. Anyway, you are right and I missed the zend_unset_timeout() in my patch. Here is a patch that should fix your problem: http://mega.ist.utl.pt/~ncpl/patch_cygwin_php.txt Please test it. Thanks, Nuno [2005-08-01 12:07:40] [EMAIL PROTECTED] Dmitry, check your patch please. :) [2005-08-01 06:47:30] xuefer at 21cn dot com Description: in reply to: http://bugs.php.net/bug.php?id=33156 (can't open the bug) for CYGWIN in zend_set_timeout() ITIMER_REAL is set in zend_unset_timeout() ITIMER_REAL is NOT unset, but unset ITIMER_PROF instead it has no problem with "make test" as the test won't last long. but with any SAPI other than cli. ITIMER_REAL is triggered after php request is shutdown, result a crash Reproduce code: --- set timeout to 5 ./sapi/php -b 1026 request it with an empty php script wait for 5 second countdown crash -- Edit this bug report at http://bugs.php.net/?id=33942&edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286 Comment by: nikobaer at gmx dot net Reported By: igg10 at alu dot ua dot es Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Hi, I've the same problem, and the advice to search the bug in the own application didn't solve it. I can rule out an infinite repeat. The Apache crashes in unreproducable intervals, but everytime at a OCILogon. I've had ran the scripts at an IBM AIX Server with Apache 1.3.31 and php 4.3.11 and at a HP-UX Server with Apache 2.0.47 and php 4.2.3 without any crash. Win2k Sp4 with apache 2.0.54 and php 4.3.10 crashes randomly. cu nikobaer Previous Comments: [2005-06-20 17:53:28] maxim at am dot id dot lv It`s not apache or php bug. It`s your own bug. Some where in your code you have cycle which never ends. Look through your code and you will find the error. [2005-05-30 09:10:14] mail at fabianhess dot de I'm experiencing the problem when accessing an Oracle Database. The Apache Log says: [client 192.168.101.19] PHP Warning: ociserverversion() [function.ociserverversion]: OCIServerVersion: ORA-03113: Unerwartetes \xdcbertragungsende in Kommunikation\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 179 [client 192.168.101.19] PHP Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-03114: Nicht mit ORACLE verbunden\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 308 [client 192.168.101.19] PHP Warning: ociserverversion() [function.ociserverversion]: OCIServerVersion: ORA-01041: Interner Fehler: hostdef-Erweiterung ist nicht vorhanden\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 179 [client 192.168.101.19] PHP Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-03114: Nicht mit ORACLE verbunden\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 308 [Thu May 26 01:50:06 2005] [notice] Parent: child process exited with status 3221225477 -- Restarting. [2003-11-17 14:18:03] [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. [2003-11-17 07:51:17] igg10 at alu dot ua dot es Description: Apache2 crashes PHP as module on apache 2.0.47 php 4.3.2 windows 2000 Fri Nov 14 12:53:09 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Fri Nov 14 12:53:09 2003] [notice] Parent: Created child process 1044 [Fri Nov 14 12:53:09 2003] [notice] Child 1044: Child process is running [Fri Nov 14 12:53:10 2003] [notice] Child 1044: Acquired the start mutex. [Fri Nov 14 12:53:10 2003] [notice] Child 1044: Starting 64 worker threads. -- Edit this bug report at http://bugs.php.net/?id=26286&edit=1
#33966 [NEW]: wrong use of reflectionproperty causes a segfault
From: [EMAIL PROTECTED] Operating system: Linux (Debian) PHP version: 5CVS-2005-08-02 (dev) PHP Bug Type: Class/Object related Bug description: wrong use of reflectionproperty causes a segfault Description: When (ab)using the ReflectionProperty class' methods as static, it segfaults. Reproduce code: --- foo; ?> Actual result: -- 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 3359RETURN_BOOL(ref->prop->flags & mask); (gdb) bt #0 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 #1 0x083c2c24 in zif_reflection_property_isPublic (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3366 #2 0x083c6309 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffd090) at zend_vm_execute.h:184 #3 0x083c692d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffd090) at zend_vm_execute.h:299 #4 0x083c5f8a in execute (op_array=0x878dd34) at zend_vm_execute.h:87 #5 0x0838edc6 in zend_call_function (fci=0xbfffd260, fci_cache=0xbfffd220) at /dat/dev/php/php-5.1dev/Zend/zend_execute_API.c:871 #6 0x083aee9d in zend_call_method (object_pp=0xbfffd2f0, obj_ce=0x878c36c, fn_proxy=0x878c44c, function_name=0x85cfd54 "__get", function_name_len=5, retval_ptr_ptr=0xbfffd2e4, param_count=1, arg1=0x878cea4, arg2=0x0) at /dat/dev/php/php-5.1dev/Zend/zend_interfaces.c:87 #7 0x083b4e26 in zend_std_call_getter (object=0x878c714, member=0x878cea4) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:72 #8 0x083b576e in zend_std_read_property (object=0x878c714, member=0x878b148, type=0) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:305 #9 0x083ff3f9 in zend_fetch_property_address_read_helper_SPEC_CV_CONST ( type=0, execute_data=0xbfffd440) at zend_vm_execute.h:20491 #10 0x083ff510 in ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER ( execute_data=0xbfffd440) at zend_vm_execute.h:20513 #11 0x083c5f8a in execute (op_array=0x8786de4) at zend_vm_execute.h:87 #12 0x0839b2fb in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /dat/dev/php/php-5.1dev/Zend/zend.c:1087 #13 0x08350fc4 in php_execute_script (primary_file=0xb8b0) at /dat/dev/php/php-5.1dev/main/main.c:1672 #14 0x0841325c in main (argc=1, argv=0xb994) at /dat/dev/php/php-5.1dev/sapi/cli/php_cli.c:1039 (gdb) print *ref Cannot access memory at address 0x2a8fcc84 -- Edit bug report at http://bugs.php.net/?id=33966&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33966&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33966&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33966&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33966&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33966&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33966&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33966&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33966&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33966&r=support Expected behavior: http://bugs.php.net/fix.php?id=33966&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33966&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33966&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33966&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33966&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33966&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33966&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33966&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33966&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33966&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33966&r=mysqlcfg
#33965 [NEW]: NULL valued output parameters from stored procedures contain corrupt data
From: paul dot robinson at groupbc dot com Operating system: Linux (RHEL 4) PHP version: 5.0.4 PHP Bug Type: MSSQL related Bug description: NULL valued output parameters from stored procedures contain corrupt data Description: MS SQL Server 2000, FreeTDS 0.63 Output parameters from a stored procedure call contain corrupt data when the result should be NULL. Its particularly noticable for variable length strings as output looks as though it just reads from a random pointer until it find a \0 ! No test is done on whether the output is NULL or not. Diff below shows proposed change to fix this. NOTE: This calls a function dbretisnull that is not currently implemented in the FreeTDS package but has been submitted as a proposed change. 19c19 < /* $Id: php_mssql.c,v 1.137.2.9 2005/04/12 17:46:06 fmk Exp $ */ --- > /* $Id: php_mssql.c,v 1.137.2.8 2005/02/25 23:25:33 fmk Exp $ */ 324,326d323 < #ifndef HAVE_FREETDS < dbwinexit(); < #else 328d324 < #endif 978c974 < int i, num_rets, type; --- > int i, num_rets, type, is_null; 992,1019c988,1022 < switch (type) { < case SQLBIT: < case SQLINT1: < case SQLINT2: < case SQLINT4: < convert_to_long_ex(&bind->zval); < /* FIXME this works only on little endian machine !!! */ < Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLFLT4: < case SQLFLT8: < case SQLFLTN: < case SQLMONEY4: < case SQLMONEY: < case SQLMONEYN: < convert_to_double_ex(&bind->zval); < Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i))); < break; < < case SQLCHAR: < case SQLVARCHAR: < case SQLTEXT: < convert_to_string_ex(&bind->zval); < Z_STRLEN_P(bind->zval) = dbretlen(mssql_ptr->link,i); < Z_STRVAL_P(bind->zval) = estrndup(dbretdata(mssql_ptr->link,i),Z_STRLEN_P(bind->zval)); < break; < /* TODO binary */ --- > /* Test column value for null flag and set value as required */ > is_null = dbretisnull(mssql_ptr->link, i); > if (is_null) { > ZVAL_NULL(bind->zval); > } > else { > switch (type) { > case SQLBIT: > case SQLINT1: > case SQLINT2: > case SQLINT4: > convert_to_long_ex(&bind->zval); > /* FIXME this works only on little endian machine !!! */ > Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i))); > break; > > case SQLFLT4: > case SQLFLT8: > case SQLFLTN: > case SQLMONEY4: > case SQLMONEY: > case SQLMONEYN: > convert_to_double_ex(&bind->zval); > Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i))); >
#33964 [NEW]: ifx.ec : syntax error before '/' token
From: jmserra at pereserra dot net Operating system: Linux Fedora Core 4 PHP version: 5.0.4 PHP Bug Type: Compile Failure Bug description: ifx.ec : syntax error before '/' token Description: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml works fine , after executing 'make' outputs that syntax error versions: *Informix IDS v9.4 32bit *GNU libtool 1.5.16 *make 3.8 Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysqli --with-informix=/usr/informix --with-gd2 --disable-libxml make Expected result: i expected that make outut no errors Actual result: -- /bin/sh /root/php-5.0.4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/informix//incl/esql -Iext/informix/ -I/root/php-5.0.4/ext/informix/ -DPHP_ATOM_INC -I/root/php-5.0.4/include -I/root/php-5.0.4/main -I/root/php-5.0.4 -I/usr/include/mysql -I/root/php-5.0.4/TSRM -I/root/php-5.0.4/Zend-g -O2 -prefer-non-pic -c /root/php-5.0.4/ext/informix/ifx.c -o ext/informix/ifx.lo /root/php-5.0.4/ext/informix/ifx.ec: In function 'zm_info_ifx': /root/php-5.0.4/ext/informix/ifx.ec:452: error: syntax error before '/' token /root/php-5.0.4/ext/informix/ifx.ec:3241:17: error: operator '<' has no left operand make: *** [ext/informix/ifx.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=33964&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33964&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33964&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33964&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33964&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33964&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33964&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33964&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33964&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33964&r=support Expected behavior: http://bugs.php.net/fix.php?id=33964&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33964&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33964&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33964&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33964&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33964&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33964&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33964&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33964&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33964&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33964&r=mysqlcfg
#33963 [NEW]: Binding some stored procedure parameters fails
From: paul dot robinson at groupbc dot com Operating system: Linux (RHEL 4) PHP version: 5.0.4 PHP Bug Type: MSSQL related Bug description: Binding some stored procedure parameters fails Description: Using FreeTDS 0.63 (latest stable release), calling mssql_bind can fail due to the restrictions placed on parameters by the dbrpcparam function from FreeTDS. One specific example is an input parameter must have maxlen==-1. With the code as is in PHP 5.0.4 a NULL valued variable length type input parameter will always have maxlen==0 thereby always failing. Diff below shows changes to ext/mssql/php_mssql.c that address this parameter mismatch. 2025,2026c2025,2029 < maxlen=0; < datalen=0; --- > datalen = 0; > if (is_output) > maxlen = -1; > else > maxlen = -1; 2030d2032 < datalen=Z_STRLEN_PP(var); 2031a2034,2046 > > if (is_output) { > if ((maxlen > 0 ) && (maxlen < 256)) > datalen = maxlen; > else { > maxlen = 255; > datalen = 255; > } > } > else { > maxlen = -1; > datalen=Z_STRLEN_PP(var); > } Reproduce code: --- mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR); or mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR, false, true, 57); Expected result: Sucessfully bind input variable. Actual result: -- "Unable to set parameter" i.e. FAIL is returned by the call to dbrpcparam in PHP_FUNCTION(mssql_bind). -- Edit bug report at http://bugs.php.net/?id=33963&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33963&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33963&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33963&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33963&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33963&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33963&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33963&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33963&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33963&r=support Expected behavior: http://bugs.php.net/fix.php?id=33963&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33963&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33963&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33963&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33963&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33963&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33963&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33963&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33963&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33963&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33963&r=mysqlcfg
#31327 [NoF->Opn]: chinese char and word problem
ID: 31327 User updated by: vtsuper1 at mail dot hongkong dot com Reported By: vtsuper1 at mail dot hongkong dot com -Status: No Feedback +Status: Open Bug Type: COM related Operating System: windowXP -PHP Version: 5.0.3 +PHP Version: 5.0.4 New Comment: I'm sorry, becuase I haven'r report to this bug for a long time. I have try the same code in php 5.0.4, but it having the same problem. In honest I don't know what is CVSso...I don;t know what can I do Previous Comments: [2005-03-08 01:00:21] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-02-28 21:06:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-12-28 20:46:49] vtsuper1 at mail dot hongkong dot com Description: I have try this code in php 5.0.3 and 4.3 I'm using Chinese winXP and Chinese Office XP apache 2 both version of php also have the same problem When I use Chinese character in the string, the output of the word file will have some meaningless spaces after the words I expected(my expected string is ok, no problem). There are no problem if I using English. And this problem will not occurs in excel. Reproduce code: --- Version}\n"; //bring it to front $word->Visible = 1; //open an empty document $word->Documents->Add(); //do some weird stuff $word->Selection->TypeText("§A¦n¶Ü"); $word->Documents[1]->SaveAs("Useless test.doc"); //closing word $word->Quit(); //free the object $word = null; ?> Expected result: §A¦n¶Ü Actual result: -- §A¦n¶Ü (there are some spaces occurs, I use the underline to repersent the spaces) -- Edit this bug report at http://bugs.php.net/?id=31327&edit=1
#33956 [Bgs->Opn]: Undefined reference; Cannot find libssl.
ID: 33956 User updated by: Jaguar at digitalmarble dot com Reported By: Jaguar at digitalmarble dot com -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Debian Linux 3.1 Sarge r0a i386 PHP Version: 4.4.0 New Comment: Regardless, if I recompile openssl without zlib this error disappears and php builds. Only problem is, I'd like to use zlib. If it is a system error, give me a helpful hint here and I'll start my hunt for it and leave you good people alone :). Previous Comments: [2005-08-02 07:52:52] [EMAIL PROTECTED] We can't do miracles here..just fix your system, it's pretty screwed up right now. [2005-08-02 03:01:14] Jaguar at digitalmarble dot com Description: libssl not found! Or so it says. Upon configuring extensions configure dies "checking for SSL_CTX_set_ssl_version in -lss...". I know it has something to do with zlib 1.2.3 as I had the same problem when I configured apache 2.0.54. I resolved it with the configure flag --enable-deflate in apache but php (unless I missed it) doesn't seem to have such an option. I configured zlib in with openssl 0.9.8 and the configured openssl into apache (which required a patch due to some problems between apache 2.0.54, openssl 0.9.8 and zlib 1.2.2+). I suspect the problem is with zlib but that's all I can decipher. I have libssl.so.0.9.7 every possible place I could think configure would look. I scoured google and tried countless forum suggestions. I'm working off php 4.4.0 cvs snapshot august 1st 2005. Perhaps someone can help? Reproduce code: --- ./configure --with-openssl=/usr/local/ssl --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql --with-bz2 --with-zlib=/usr/local --with-mcrypt=/usr --enable-ftp --with-regex=apache --with-swf Actual result: -- ./configure output -- SNIPPET -- checking for SSL_CTX_set_ssl_version in -lssl... no configure: error: libssl not found! -- END SNIPPET -- config.log -- SNIPPET -- configure:18083: checking for SSL_CTX_set_ssl_version in -lssl configure:18102: gcc -o conftest -g -O2 -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib conftest.c -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypto 1>&5 /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x78): In function `zlib_stateful_init': : undefined reference to `inflateInit_' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0xd7): In function `zlib_stateful_init': : undefined reference to `deflateInit_' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x290): In function `zlib_stateful_compress_block': : undefined reference to `deflate' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x315): In function `zlib_stateful_expand_block': : undefined reference to `inflate' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x33f): In function `zlib_stateful_free_ex_data': : undefined reference to `inflateEnd' /usr/local/ssl/lib/libcrypto.a(c_zlib.o)(.text+0x34a): In function `zlib_stateful_free_ex_data': : undefined reference to `deflateEnd' collect2: ld returned 1 exit status configure: failed program was: #line 18091 "configure" #include "confdefs.h" -- END SNIPPET -- -- Edit this bug report at http://bugs.php.net/?id=33956&edit=1
#33961 [NEW]: Bundle SQLite extension
From: [EMAIL PROTECTED] Operating system: Win2000 PHP version: 4.4.0 PHP Bug Type: Feature/Change Request Bug description: Bundle SQLite extension Description: Why not to include sqlite extension in standard windows .zip distribution of PHP 4.4.x ? -- Edit bug report at http://bugs.php.net/?id=33961&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33961&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33961&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33961&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33961&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33961&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33961&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33961&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33961&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33961&r=support Expected behavior: http://bugs.php.net/fix.php?id=33961&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33961&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33961&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33961&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33961&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33961&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33961&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33961&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33961&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33961&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33961&r=mysqlcfg
#33960 [Fbk->Opn]: fsockopen() timeout parameter has no function
ID: 33960 User updated by: cyberline at techno4ever dot net Reported By: cyberline at techno4ever dot net -Status: Feedback +Status: Open Bug Type: Sockets related -Operating System: Suse 9.2/3 +Operating System: Suse 9.3 PHP Version: 5.0.4 New Comment: same result as before :/ i think the Nameserver of the checked hosts are Offline atm. By the way: compiling snapshot with: "--enable-soap" produces this output: /root/php5-200508020630/ext/soap/php_xml.c -o ext/soap/php_xml.lo /root/php5-200508020630/ext/soap/php_xml.c: In function `soap_xmlParseFile': /root/php5-200508020630/ext/soap/php_xml.c:89: error: `tsrm_ls' undeclared (first use in this function) /root/php5-200508020630/ext/soap/php_xml.c:89: error: (Each undeclared identifier is reported only once /root/php5-200508020630/ext/soap/php_xml.c:89: error: for each function it appears in.) Previous Comments: [2005-08-02 10:30:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-02 10:27:39] cyberline at techno4ever dot net Description: When i set a timelimit for fsockopen() the script won't stop after the limit reaches. Reproduce code: --- if($fp = fsockopen($host, $port, &$errno, &$errnum, 2)) { ... } Expected result: When the checked host is offline, the script reported that afetr 2 seconds. Actual result: -- The Script is stopping after 60 seconds. -- Edit this bug report at http://bugs.php.net/?id=33960&edit=1
#33960 [Opn->Fbk]: fsockopen() timeout parameter has no function
ID: 33960 Updated by: [EMAIL PROTECTED] Reported By: cyberline at techno4ever dot net -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Suse 9.2/3 PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-08-02 10:27:39] cyberline at techno4ever dot net Description: When i set a timelimit for fsockopen() the script won't stop after the limit reaches. Reproduce code: --- if($fp = fsockopen($host, $port, &$errno, &$errnum, 2)) { ... } Expected result: When the checked host is offline, the script reported that afetr 2 seconds. Actual result: -- The Script is stopping after 60 seconds. -- Edit this bug report at http://bugs.php.net/?id=33960&edit=1
#33960 [NEW]: fsockopen() timeout parameter has no function
From: cyberline at techno4ever dot net Operating system: Suse 9.2/3 PHP version: 5.0.4 PHP Bug Type: Sockets related Bug description: fsockopen() timeout parameter has no function Description: When i set a timelimit for fsockopen() the script won't stop after the limit reaches. Reproduce code: --- if($fp = fsockopen($host, $port, &$errno, &$errnum, 2)) { ... } Expected result: When the checked host is offline, the script reported that afetr 2 seconds. Actual result: -- The Script is stopping after 60 seconds. -- Edit bug report at http://bugs.php.net/?id=33960&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33960&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33960&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33960&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33960&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33960&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33960&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33960&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33960&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33960&r=support Expected behavior: http://bugs.php.net/fix.php?id=33960&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33960&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33960&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33960&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33960&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33960&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33960&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33960&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33960&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33960&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33960&r=mysqlcfg
#30348 [Com]: GD imagegif temp files not removed
ID: 30348 Comment by: abyss at m3ezw dot co dot uk Reported By: phpsupport at shopandlearn dot net Status: No Feedback Bug Type: GD related Operating System: Windows XP with SP2 PHP Version: 5.0.2 New Comment: I have this same problem. .gif leaves behind a .tmp file but .jpeg and .png do not. This is annoying because .jpeg is too low in quality but .png is too high in size to use. .gif is perfect match of both. Please fix the bug! Previous Comments: [2005-07-22 05:25:01] bkfake-temp at yahoo dot com No feedback? Here's some: I've got a slew of tmp files lingering around.. PHP 5.0.4 w/ bundled GD Win XP SP2 same as bug 30696? which was closed... [2004-12-06 20:35:42] player0 at liquidninjas dot com I got this bug upgrading from 4.3.7 to 4.3.9 on Windows 2003 Server running Apache2 2.0.52, using the included GD libraries. It starts dumping xx.tmp files on my root directory. Had to go back to 4.3.7 cause I use GD a lot and it was making a serious mess. [2004-11-20 15:15:48] mario at huelsenitz dot de On my Linux Suse 8.1 with PHP 4.3.9 an the bundle GD is the same. Files are not removed from the temp. [2004-10-26 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-10-18 23:49:34] mcnuke at gmx dot net I just tried that and it does not help. There are still temp files left in /tmp after I started scripts having image-functions. 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/30348 -- Edit this bug report at http://bugs.php.net/?id=30348&edit=1