#22427 [Com]: Missing Form Post Data
ID: 22427 Comment by: medhat dot s at scs-net dot org Reported By: jroland at uow dot edu dot au Status: No Feedback Bug Type: *General Issues Operating System: Windows XP / 2000 PHP Version: 4.2.3 New Comment: I have the same problem! sometimes, all post variables disappear although that I use a normal form with normal text inputs & normal data size. no textareas and no "multiform" tag in the form php version : 5.1.6 apache webserver on Linux server. I'm still unable to fix it! Previous Comments: [2009-02-05 23:38:04] neal dot pressley at yahoo dot com Please ignore the above comments. changing the case did not fix the problem. Its just irratic. it works some time, it does not work some time. The problem with both post and get. I have a checkbox and submit button in the form. If I do not check the checkbox and just submit the button, it works but if I use check and enter submit, it does not work. I moved the related part of the code from the big php file and tried to isolate the problem. Surprisingly it works perfectly as a small file but in the big php which has few more forms and tables, it does not work. = "; echo "post is"; print_r($_POST); echo "get is"; print_r($_GET); echo "request is"; print_r($_REQUEST); echo "let us check HTTP_POST_VARS"; print_r($HTTP_POST_VARS); echo ""; ?> http://www.w3.org/TR/html4/loose.dtd";> Managing URL to StartContext Mapping Delete existing mappings from the database before loading the data from the CSV File. === [2009-02-05 18:49:59] neal dot pressley at yahoo dot com I was facing the same problem. I had a html form with php scripts in which I was submitting radio buttons or checkboxes. When I post the form, PHP was not finding any post parameters. it was random, some time it was working and some time not. Even I tried with Get, it worked some time and some time not. Then I change ENCTYPE from uppercase to lowercase and it started working prefectly [2008-11-13 16:58:11] keith at tdrnetworks dot com Regarding the enctype="multipart/form-data" not populating the $_POST vars I found my solution was to disable the Suhosin security module. Have a go! [2008-07-21 11:19:33] americo dot patetta at gmail dot com CONFIRMATION: The bug is present even using PHP 5.x and Apache 2.x ON WINDOWS; It only shows up when posting from IE an using multipart/data. Firefox works just fine. [2008-02-12 08:10:28] derrickpereira at gmail dot com Had this same issue where form fields would NOT get passed if I was using IE6, but went through without issues on Firefox. Using $_POST, $_GET I would get nothing... I traced the problem to the name I had given to textfield inputs - Changed them to m_height and m_length respectively and the form passed without issues. Perhaps there are some reserved keywords that you cannot use as name in IE6? Hope that helps. Derrick 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/22427 -- Edit this bug report at http://bugs.php.net/?id=22427&edit=1
#50060 [NEW]: "failed creating formpost data" if post array value starts with '@'
From: bugs dot php dot net at sgerrand dot com Operating system: Linux (Ubuntu x86_64 2.6.31-14) PHP version: 5.2.11 PHP Bug Type: cURL related Bug description: "failed creating formpost data" if post array value starts with '@' Description: PHP's cURL library dies returning the error message "failed creating formpost data" when trying to use an array that contains a value starting with '@'. If the array is changed to a string in URL encoded like format, the problem does not occur. Reproduce code: --- http://www.php.net'; $postData = array('key' => '@value'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $postData); if (! curl_exec($ch) ) print 'cURL error: ' . curl_error($ch); else print "cURL success"; curl_close($ch); ?> Expected result: cURL success Actual result: -- cURL error: failed creating formpost data -- Edit bug report at http://bugs.php.net/?id=50060&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50060&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50060&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50060&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50060&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50060&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50060&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50060&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50060&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50060&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50060&r=support Expected behavior: http://bugs.php.net/fix.php?id=50060&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50060&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50060&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50060&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50060&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50060&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50060&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50060&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50060&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50060&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50060&r=mysqlcfg
#49997 [NoF->Opn]: Implementing a namespaced interface crashes
ID: 49997 User updated by: flavius dot as at gmail dot com Reported By: flavius dot as at gmail dot com -Status: No Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux x86_64 PHP Version: 5.3.0 New Comment: Could someone do something with this report? Previous Comments: [2009-11-03 01:00:00] 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". [2009-10-28 19:30:23] flavius dot as at gmail dot com Sorry for the incomplete post. This happens in my scripts because it's trying to autoload an interface. My code was indeed buggy, but I woudn't expect PHP to crash. [2009-10-28 19:27:29] flavius dot as at gmail dot com After some debugging, I came to the conclusion that it crashes because of an exception being thrown inside a spl_register_autoload()'ed userland method. Here's the bt: #0 zend_lookup_class_ex (name=0x15b9d40 "Exception", name_length=9, use_autoload=1, ce=0x7fffb2e0) at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1016 #1 0x007954d1 in zend_fetch_class (class_name=0x15b9d40 "Exception", class_name_len=9, fetch_type=4) at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1524 #2 0x007d8d22 in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER (execute_data=0x76552cc0) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:724 #3 0x007d6b50 in execute (op_array=0x15bc828) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:104 #4 0x007940e5 in zend_call_function (fci=0x7fffb640, fci_cache=0x7fffb5d0) at /home/flav/php-5.3.0/Zend/zend_execute_API.c:936 #5 0x007bfae4 in zend_call_method (object_pp=0x0, obj_ce=0x15b8eb0, fn_proxy=0x15b09f8, function_name=0x15ba410 "\\yap\\base::autoload", function_name_len=20, retval_ptr_ptr=0x7fffb748, param_count=1, arg1=0x15f8930, arg2=0x0) at /home/flav/php-5.3.0/Zend/zend_interfaces.c:97 #6 0x00600de0 in zif_spl_autoload_call (ht=1, return_value=0x161c620, return_value_ptr=0x7fffba70, this_ptr=0x0, return_value_used=1) at /home/flav/php-5.3.0/ext/spl/php_spl.c:395 #7 0x007942c2 in zend_call_function (fci=0x7fffba20, fci_cache=0x7fffb9f0) at /home/flav/php-5.3.0/Zend/zend_execute_API.c:958 #8 0x00794999 in zend_lookup_class_ex (name=0x15f8a30 "YAP\\patterns\\IInheritable", name_length=25, use_autoload=1, ce=0x7fffbb20) at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1089 #9 0x007954d1 in zend_fetch_class (class_name=0x15f8a30 "YAP\\patterns\\IInheritable", class_name_len=25, fetch_type=6) at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1524 #10 0x007d93d3 in ZEND_ADD_INTERFACE_SPEC_CONST_HANDLER (execute_data=0x76552bb8) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:890 #11 0x007d6b50 in execute (op_array=0x15f68c8) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:104 #12 0x007a38de in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/flav/php-5.3.0/Zend/zend.c:1188 #13 0x0072ed19 in php_execute_script (primary_file=0x7fffe1b0) at /home/flav/php-5.3.0/main/main.c:2196 #14 0x0088c885 in main (argc=7, argv=0x7fffe408) at /home/flav/php-5.3.0/sapi/cli/php_cli.c:1188 [2009-10-26 16:54:38] flavius dot as at gmail dot com Done. The output: Reading symbols from /home/flav/php-5.3.0/sapi/cli/php...done. (gdb) run /usr/bin/phpunit --bootstrap bootstrap.php --configuration phpunit.xml testunit/ Starting program: /home/flav/php-5.3.0/sapi/cli/php /usr/bin/phpunit --bootstrap bootstrap.php --configuration phpunit.xml testunit/ [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x007d93db in ZEND_ADD_INTERFACE_SPEC_CONST_HANDLER (execute_data=0x765529a8) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:892 892 if (!(iface->ce_flags & ZEND_ACC_INTERFACE)) { (gdb) bt #0 0x007d93db in ZEND_ADD_INTERFACE_SPEC_CONST_HANDLER (execute_data=0x765529a8) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:892 #1 0x007d6b50 in execute (op_array=0x161f078) at /home/flav/php-5.3.0/Zend/zend_vm_execute.h:104 #2 0x007a38de in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/flav/php-5.3.0/Zend/zend.c:1188 #3 0x0072ed19 in php_execute_script (primary_file=0x7fffe1e0) at /home/flav/php-5.3.0/main/main.c:2196 #4 0x0088c885 in main (argc=7, argv=0x7fffe438) at /home/flav/php-5.3.0/sapi/cli/php_cli.c:1
#50047 [Opn]: interface binding for fsockopen (like socket_bind)
ID: 50047 User updated by: naox at o2 dot pl Reported By: naox at o2 dot pl Status: Open Bug Type: Feature/Change Request Operating System: - PHP Version: 5.2.11 New Comment: nope. this would be setting destination not source interface. Check out http://php.net/manual/pl/function.socket-bind.php this however is for socket functions not "network" like fsockopen Previous Comments: [2009-11-03 03:06:00] srina...@php.net is this some thing what you are looking for ? $fp = fsockopen("tcp://127.0.0.1", 8080); or $fp = fsockopen("unix:///tmp/mysocket", ..); [2009-11-01 00:26:59] naox at o2 dot pl Description: PHP really needs interface binding for fsockopen() (like socket_bind()) -- Edit this bug report at http://bugs.php.net/?id=50047&edit=1
#50059 [NEW]: strototime() incorrectly parses first sunday of Nov 2009
From: herrnoel at gmail dot com Operating system: Linux/Debian 5.0.3 PHP version: 5.2.11 PHP Bug Type: Date/time related Bug description: strototime() incorrectly parses first sunday of Nov 2009 Description: Actual php version is latest from debian stable: PHP 5.2.6-1+lenny3 When using strtotime() for some really handy english parsing, it works great EXCEPT for the first day of the month. The format is as follows: [1-4] [day of week] [month] [year] If the day of the week is the first day of the month, this will return the date starting one week ahead of the first day of the month. Otherwise, the behavior is as expected. This is repeatable for all months. If you leave out the initial digit, the broken first day of the month works, but then you must use 1 to indicate the 2nd instance of that day and so on. Reproduce code: --- echo date('Y-m-d', strtotime('1 thu oct 2009')); # first day of month echo date('Y-m-d', strtotime('1 fri oct 2009')); # second day of month echo date('Y-m-d', strtotime('1 sun nov 2009')); # first day of month echo date('Y-m-d', strtotime('2 sun nov 2009')); # second sunday of month (sunday is the first day of month) Expected result: 2009-10-01 2009-10-02 2009-11-01 2009-11-08 Actual result: -- 2009-10-08 2009-10-02 2009-11-08 2009-11-15 -- Edit bug report at http://bugs.php.net/?id=50059&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50059&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50059&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50059&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50059&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50059&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50059&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50059&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50059&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50059&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50059&r=support Expected behavior: http://bugs.php.net/fix.php?id=50059&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50059&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50059&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50059&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50059&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50059&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50059&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50059&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50059&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50059&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50059&r=mysqlcfg
#50047 [Opn]: interface binding for fsockopen (like socket_bind)
ID: 50047 Updated by: srina...@php.net Reported By: naox at o2 dot pl Status: Open Bug Type: Feature/Change Request Operating System: - PHP Version: 5.2.11 New Comment: is this some thing what you are looking for ? $fp = fsockopen("tcp://127.0.0.1", 8080); or $fp = fsockopen("unix:///tmp/mysocket", ..); Previous Comments: [2009-11-01 00:26:59] naox at o2 dot pl Description: PHP really needs interface binding for fsockopen() (like socket_bind()) -- Edit this bug report at http://bugs.php.net/?id=50047&edit=1
#50057 [Com]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
ID: 50057 Comment by: proforg at maloletka dot ru Reported By: proforg at maloletka dot ru Status: Open Bug Type: Reproducible crash Operating System: Debian Lenny 2.6.26-2-amd64 PHP Version: 5.2SVN-2009-11-02 (snap) New Comment: the same for 5.2.10 and 5.2.11 but 5.2.9 works fine Previous Comments: [2009-11-02 23:10:30] proforg at maloletka dot ru Description: php5.2-200911021930 + apache2 / fpm sapi frequently crashes on debian horde3 + imp4 installation. Reproduce code: --- Current debian horde and imp packages. Actual result: -- fpm log output: Nov 03 01:51:13.738647 [WARNING] fpm_children_bury(), line 217: child 19892 (pool www-data) exited on signal 11 SIGSEGV (core dumped) after 2377.432524 seconds from start Nov 03 01:51:13.738687 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "[Tue Nov 3 01:36:48 2009] Script: '/usr/share/horde3//index.php'" Nov 03 01:51:13.738716 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(289) : Freeing 0x029A97C0 (46 bytes), script=/usr/share/horde3//index.php", pipe is closed Nov 03 01:51:13.738738 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "[Tue Nov 3 01:36:48 2009] Script: '/usr/share/horde3//index.php'", pipe is closed Nov 03 01:51:13.738758 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(361) : Freeing 0x02540370 (16 bytes), script=/usr/share/horde3//index.php", pipe is closed Nov 03 01:51:13.738779 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "=== Total 2 memory leaks detected ===", pipe is closed backtrace: [New process 19892] #0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0, ptr=0x69766f7270207469, silent=1, __zend_filename=0x8913f8 "/usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304 1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)- >info._prev) { (gdb) bt #0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0, ptr=0x69766f7270207469, silent=1, __zend_filename=0x8913f8 "/usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304 #1 0x007367da in _zend_mm_free_int (heap=0x1e392a0, p=0x69766f7270207469, __zend_filename=0x8913f8 "/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2- 200911021930/Zend/zend_alloc.c:1943 #2 0x00737d76 in _efree (ptr=0x69766f7270207469, __zend_filename=0x8913f8 "/usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:2311 #3 0x005a7ba0 in _php_pgsql_notice_ptr_dtor (ptr=0x1fe2928) at /usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c:379 #4 0x0076503d in zend_hash_clean (ht=0xb83a88) at /usr/local/src/php5.2-200911021930/Zend/zend_hash.c:552 #5 0x005a843e in zm_deactivate_pgsql (type=1, module_number=18) at /usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c:578 #6 0x0075f9c5 in module_registry_cleanup (module=0x1e70e80) at /usr/local/src/php5.2- 200911021930/Zend/zend_API.c:1976 #7 0x007658a5 in zend_hash_reverse_apply (ht=0xb87e60, apply_func=0x75f98a ) at /usr/local/src/php5.2-200911021930/Zend/zend_hash.c:755 #8 0x00756f2d in zend_deactivate_modules () at /usr/local/src/php5.2-200911021930/Zend/zend.c:838 #9 0x006fed04 in php_request_shutdown (dummy=0x0) at /usr/local/src/php5.2-200911021930/main/main.c:1474 #10 0x007de90f in main (argc=6, argv=0x7fff4f59af58) at /usr/local/src/php5.2- 200911021930/sapi/fpm/cgi/cgi_main.c:1589 php build options: --with-fpm --with-libevent=shared,/usr --with-pgsql --with-gd --with- mhash --with-mcrypt --with-pear=/usr/share/php/ --enable- debug --with-imap --with-kerberos --with-imap-ssl --with-gettext same result with apache2 sapi -- Edit this bug report at http://bugs.php.net/?id=50057&edit=1
#50057 [NEW]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
From: proforg at maloletka dot ru Operating system: Debian Lenny 2.6.26-2-amd64 PHP version: 5.2SVN-2009-11-02 (snap) PHP Bug Type: Reproducible crash Bug description: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde Description: php5.2-200911021930 + apache2 / fpm sapi frequently crashes on debian horde3 + imp4 installation. Reproduce code: --- Current debian horde and imp packages. Actual result: -- fpm log output: Nov 03 01:51:13.738647 [WARNING] fpm_children_bury(), line 217: child 19892 (pool www-data) exited on signal 11 SIGSEGV (core dumped) after 2377.432524 seconds from start Nov 03 01:51:13.738687 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "[Tue Nov 3 01:36:48 2009] Script: '/usr/share/horde3//index.php'" Nov 03 01:51:13.738716 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(289) : Freeing 0x029A97C0 (46 bytes), script=/usr/share/horde3//index.php", pipe is closed Nov 03 01:51:13.738738 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "[Tue Nov 3 01:36:48 2009] Script: '/usr/share/horde3//index.php'", pipe is closed Nov 03 01:51:13.738758 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(361) : Freeing 0x02540370 (16 bytes), script=/usr/share/horde3//index.php", pipe is closed Nov 03 01:51:13.738779 [WARNING] fpm_stdio_child_said(), line 167: child 19892 (pool www-data) said into stderr: "=== Total 2 memory leaks detected ===", pipe is closed backtrace: [New process 19892] #0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0, ptr=0x69766f7270207469, silent=1, __zend_filename=0x8913f8 "/usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304 1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)- >info._prev) { (gdb) bt #0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0, ptr=0x69766f7270207469, silent=1, __zend_filename=0x8913f8 "/usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304 #1 0x007367da in _zend_mm_free_int (heap=0x1e392a0, p=0x69766f7270207469, __zend_filename=0x8913f8 "/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2- 200911021930/Zend/zend_alloc.c:1943 #2 0x00737d76 in _efree (ptr=0x69766f7270207469, __zend_filename=0x8913f8 "/usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c", __zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:2311 #3 0x005a7ba0 in _php_pgsql_notice_ptr_dtor (ptr=0x1fe2928) at /usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c:379 #4 0x0076503d in zend_hash_clean (ht=0xb83a88) at /usr/local/src/php5.2-200911021930/Zend/zend_hash.c:552 #5 0x005a843e in zm_deactivate_pgsql (type=1, module_number=18) at /usr/local/src/php5.2- 200911021930/ext/pgsql/pgsql.c:578 #6 0x0075f9c5 in module_registry_cleanup (module=0x1e70e80) at /usr/local/src/php5.2- 200911021930/Zend/zend_API.c:1976 #7 0x007658a5 in zend_hash_reverse_apply (ht=0xb87e60, apply_func=0x75f98a ) at /usr/local/src/php5.2-200911021930/Zend/zend_hash.c:755 #8 0x00756f2d in zend_deactivate_modules () at /usr/local/src/php5.2-200911021930/Zend/zend.c:838 #9 0x006fed04 in php_request_shutdown (dummy=0x0) at /usr/local/src/php5.2-200911021930/main/main.c:1474 #10 0x007de90f in main (argc=6, argv=0x7fff4f59af58) at /usr/local/src/php5.2- 200911021930/sapi/fpm/cgi/cgi_main.c:1589 php build options: --with-fpm --with-libevent=shared,/usr --with-pgsql --with-gd --with- mhash --with-mcrypt --with-pear=/usr/share/php/ --enable- debug --with-imap --with-kerberos --with-imap-ssl --with-gettext same result with apache2 sapi -- Edit bug report at http://bugs.php.net/?id=50057&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50057&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50057&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50057&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50057&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50057&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50057&r=alreadyfixed Need backtrace: http://bugs.php
#49954 [Fbk]: Crypt() does not work for string < 4 character
ID: 49954 Updated by: paj...@php.net Reported By: rgr at woodwing dot com Status: Feedback Bug Type: *Encryption and hash functions Operating System: win32 only - Win XP 64-bit PHP Version: 5.3.0 Assigned To: pajoye New Comment: May be related to #50052. Please try a SVN snapshot. Previous Comments: [2009-10-31 16:53:13] paj...@php.net I can't reproduce it here. Can you try using a php 5.3 VC9 snapshot please? http://windows.php.net/snapshots/ [2009-10-30 12:47:59] carlodeboer at me dot com We are also experiencing problems with this bug. Especially during testing and pilot studies it is quite common to have short passwords. Upgrading to PHP 5.3 is not possible with this bug since we have to support existing installations with short passwords. [2009-10-27 13:44:50] vdklah at hotmail dot com This problem is pretty bad; After PHP 5.2->5.3 migration, users having short passwords are no longer allowed to login (to our system) due to the crypt mismatch! And, even worse, they are not allowed to change their password due to the very same problem! [2009-10-22 11:51:05] rgr at woodwing dot com Description: The function Crypt() does not work with less than 4 characters in PHP 5.3.0. See the code sample below. When using 'test' as $user_input and $password it does work correct. Reproduce code: --- --- >From manual page: function.crypt#Examples --- $user_input = 'tes'; $password = crypt('tes'); // let the salt be automatically generated if (crypt($user_input, $password) == $password) { echo "Password verified!"; } Expected result: The comparison should result true. Actual result: -- The comparison returns false. -- Edit this bug report at http://bugs.php.net/?id=49954&edit=1
#50052 [Asn->Csd]: Crypt - Different Hashes on Windows and Linux on wrong Salt size
ID: 50052 Updated by: paj...@php.net Reported By: otaviodiniz at gmail dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.0 Assigned To: pajoye New Comment: This bug has been fixed in SVN. 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: [2009-11-02 20:46:53] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=290154 Log: - Fixed #50052, Different Hashes on Windows and Linux on wrong Salt size [2009-11-02 13:57:13] otaviodiniz at gmail dot com As you can see the output are different in 5.2 and 5.3 near 0$or 01or. [2009-11-02 09:59:54] paj...@php.net Forgot to copy 5.3 output as well: g:\php-sdk\php53\vc9\x86\php53>..\obj\Debug\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF01orVloNmKSLvOeswusE0bY. [2009-11-02 09:46:31] paj...@php.net Cannot reproduce: g:\php-sdk\php53\vc9\x8\php53>\test\php52ntssnap\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. Please try using VC9-x86 binaries, http://windows.php.net/snapshots/ [2009-11-02 02:39:32] otaviodiniz at gmail dot com Description: The behave of Crypt function on Windows and Linux boxes are different. In the sample function we create a Salt with length of 12 characters. First, the Salt size is incorrect, if i remove one character the Salt, the result will be correct. But with the wrong Salt size the behavior are different: On Windows - The output is incorrect, as it shows the whole Salt without the terminator $... On Linux - PHP strips one character of Salt into it's correct expected size, outputing correctly with the terminator $... Reproduce code: --- md5crypt("test"); function md5crypt($password) { $base64_alphabet='ABCDEFGHIJKLMNOPQRSTUVWXYZ' .'abcdefghijklmnopqrstuvwxyz0123456789+/'; $salt='$1$'; for($i=0; $i<9; $i++) { $salt.=$base64_alphabet[rand(0,63)]; } $salt.='$'; echo ""; echo "Salt: ".$salt."\r\n"; echo "Output: ".crypt($password,$salt); echo ""; } Expected result: Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. //Linux Actual result: -- Salt: $1$XcPmtBmRG$ Output: $1$XcPmtBmRGuM82Sm1HMy0I0lX0P3nAd0 //Windows -- Edit this bug report at http://bugs.php.net/?id=50052&edit=1
#40787 [Opn->Asn]: Error trying to insert into a CLOB column when using multi-byte charset.
ID: 40787 Updated by: paj...@php.net Reported By: jarismar at adplabs dot com dot br -Status: Open +Status: Assigned Bug Type:PDO related PHP Version: 5.2.1 -Assigned To: wez +Assigned To: sixd New Comment: Assigned it to someone more active :) Previous Comments: [2009-11-02 20:06:16] markus at computino dot de Still a valid bug, cost me multiple hours trying to work it out before I found the bug report. Now using adodb/oci8. [2009-04-30 19:57:19] jarismar at adplabs dot com dot br Status changed to open again. [2009-04-30 19:44:03] jarismar at gmail dot com Infortunately this error persists, it still occurs. Tested with PHP Version : 5.2.10-dev Build Date : Apr 26 2009 23:39:22 [2009-04-25 14:44:07] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-01-09 16:41:59] inbox at trevorbramble dot com I am experiencing the same error as charles at crh-systems dot com, however I'm trying to enter a string into a varchar2(4000) column. I've gone through a lot in the course of diagnosing this problem so I can't recall exactly what changed, but originally I was getting this error: ORA-01460: unimplemented or unreasonable conversion requested The resolution has been to define the length for that parameter: $stmt->bindParam( ':notes', $this->notes, PDO::PARAM_STR, 4000 ); Why this fixes the problem is still a mystery. None of the inserted data is lost, so there don't appear to have really been too many bytes in the string to insert. I'm not experiencing the same problem with any of the smaller columns (a string of 4 or more characters will insert into a column defined varchar2(10), for example). 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/40787 -- Edit this bug report at http://bugs.php.net/?id=40787&edit=1
#40787 [Com]: Error trying to insert into a CLOB column when using multi-byte charset.
ID: 40787 Comment by: markus at computino dot de Reported By: jarismar at adplabs dot com dot br Status: Open Bug Type:PDO related PHP Version: 5.2.1 Assigned To: wez New Comment: Still a valid bug, cost me multiple hours trying to work it out before I found the bug report. Now using adodb/oci8. Previous Comments: [2009-04-30 19:57:19] jarismar at adplabs dot com dot br Status changed to open again. [2009-04-30 19:44:03] jarismar at gmail dot com Infortunately this error persists, it still occurs. Tested with PHP Version : 5.2.10-dev Build Date : Apr 26 2009 23:39:22 [2009-04-25 14:44:07] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-01-09 16:41:59] inbox at trevorbramble dot com I am experiencing the same error as charles at crh-systems dot com, however I'm trying to enter a string into a varchar2(4000) column. I've gone through a lot in the course of diagnosing this problem so I can't recall exactly what changed, but originally I was getting this error: ORA-01460: unimplemented or unreasonable conversion requested The resolution has been to define the length for that parameter: $stmt->bindParam( ':notes', $this->notes, PDO::PARAM_STR, 4000 ); Why this fixes the problem is still a mystery. None of the inserted data is lost, so there don't appear to have really been too many bytes in the string to insert. I'm not experiencing the same problem with any of the smaller columns (a string of 4 or more characters will insert into a column defined varchar2(10), for example). [2008-04-01 03:28:49] charles at crh-systems dot com I am having the same problem, OCIStmtExecute: ORA-01461: can bind a LONG value only for insert into a LONG column I can only get 1333 chars to insert into a clob field no matter which connection charset I use. 4000 / 3 = 1333.333 ...any fixes? 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/40787 -- Edit this bug report at http://bugs.php.net/?id=40787&edit=1
#49244 [Asn->Csd]: [PATCH] Floating point NaN cause garbage characters
ID: 49244 Updated by: paj...@php.net Reported By: ronlentjes at yahoo dot com dot au -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux Fedora 8 PHP Version: 5.*, 6 (2009-09-20) Assigned To: felipe Previous Comments: [2009-11-02 17:57:03] paj...@php.net DId you reproduce the garbage in trunk on x64 and x86, ubuntu and windows? That's why I did not apply it yet. [2009-11-02 17:41:14] fel...@php.net This bug has been fixed in SVN. 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. Thanks for the patch. I've added more a change on the HEAD version because the different function for unicode stuff. Looks all right. [2009-11-02 17:37:33] s...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=290150 Log: - Fixed bug #49244 (Floating point NaN cause garbage characters). (patch by Sjoerd) [2009-10-01 11:38:50] sjo...@php.net With the patch applied, I could not reproduce the problem anymore. Pajoye still has problems, so it is not clear whether the patch solves this bug. The patch can be found here: http://www.gissen.nl/files/bug49244.patch [2009-09-21 13:25:45] paj...@php.net Can you verify why your patch does not work in trunk please? There is still garbage. If you have a new patch, please post a link to it, the form breaks the patch format. 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/49244 -- Edit this bug report at http://bugs.php.net/?id=49244&edit=1
#49244 [Csd->Asn]: [PATCH] Floating point NaN cause garbage characters
ID: 49244 Updated by: paj...@php.net Reported By: ronlentjes at yahoo dot com dot au -Status: Closed +Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux Fedora 8 PHP Version: 5.*, 6 (2009-09-20) Assigned To: felipe New Comment: DId you reproduce the garbage in trunk on x64 and x86, ubuntu and windows? That's why I did not apply it yet. Previous Comments: [2009-11-02 17:41:14] fel...@php.net This bug has been fixed in SVN. 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. Thanks for the patch. I've added more a change on the HEAD version because the different function for unicode stuff. Looks all right. [2009-11-02 17:37:33] s...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=290150 Log: - Fixed bug #49244 (Floating point NaN cause garbage characters). (patch by Sjoerd) [2009-10-01 11:38:50] sjo...@php.net With the patch applied, I could not reproduce the problem anymore. Pajoye still has problems, so it is not clear whether the patch solves this bug. The patch can be found here: http://www.gissen.nl/files/bug49244.patch [2009-09-21 13:25:45] paj...@php.net Can you verify why your patch does not work in trunk please? There is still garbage. If you have a new patch, please post a link to it, the form breaks the patch format. [2009-09-20 10:24:28] sjo...@php.net I can't commit things. Somebody with SVN access should apply my patch and commit it. I've improved some things and added a testcase: Index: ext/standard/formatted_print.c === --- ext/standard/formatted_print.c (revision 288201) +++ ext/standard/formatted_print.c (working copy) @@ -42,6 +42,8 @@ #define FLOAT_PRECISION 6 #define MAX_FLOAT_DIGITS 38 #define MAX_FLOAT_PRECISION 40 +#define NOT_A_NUMBER "NaN" +#define INFINITE "INF" #if 0 /* trick to control varargs functions through cpp */ @@ -231,15 +233,15 @@ if (zend_isnan(number)) { is_negative = (number<0); - php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0, padding, -alignment, precision, is_negative, 0, always_sign); + php_sprintf_appendstring(buffer, pos, size, NOT_A_NUMBER, strlen(NOT_A_NUMBER), 0, padding, + alignment, strlen(NOT_A_NUMBER), is_negative, 0, always_sign); return; } if (zend_isinf(number)) { is_negative = (number<0); - php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0, padding, -alignment, precision, is_negative, 0, always_sign); + php_sprintf_appendstring(buffer, pos, size, INFINITE, strlen(INFINITE), 0, padding, + alignment, strlen(INFINITE), is_negative, 0, always_sign); return; } Index: ext/standard/tests/strings/bug49244.phpt === --- ext/standard/tests/strings/bug49244.phpt(revision 0) +++ ext/standard/tests/strings/bug49244.phpt(revision 0) @@ -0,0 +1,8 @@ +--TEST-- +Bug #49244 (Floating point NaN cause garbage characters) +--FILE-- + +--EXPECT-- +NaN 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/49244 -- Edit this bug report at http://bugs.php.net/?id=49244&edit=1
#49984 [Bgs]: DOM model is completely broken
ID: 49984 User updated by: ppass at hotmail dot fr Reported By: ppass at hotmail dot fr Status: Bogus Bug Type: DOM XML related Operating System: Linux ns1 2.6.28.4-rsbac PHP Version: 5.2.11 New Comment: The reply from the libxml2 team is to try to add the HTML_PARSE_RECOVER option when creating the parsing context. I have no idea what that means. Does anybody know how this can be done from PHP code? Previous Comments: [2009-11-02 13:46:20] ppass at hotmail dot fr That you for details, I just filed a bug in their system. [2009-11-02 06:53:03] ras...@php.net We didn't write the DOM implementation. We are simply using libxml2. Information on how to file a bug against libxml2 is here: http://xmlsoft.org/bugs.html But I suspect they won't consider this a bug. Their relaxed html parser isn't a full html parser that knows about embedded script objects. This would only be a PHP bug if we are somehow calling libxml2 incorrectly causing this, but it doesn't appear to be the case here. [2009-11-02 05:42:09] ppass at hotmail dot fr No reaction still to this bug. Maybe my previous title was too specific. More generally speaking, it means that the DOM model is broken in php when ever a script tag contains other tags in its text. This is a serious bug that must be corrected asap, other wise it is not possible to make a reliable use of DOM. [2009-10-24 04:27:57] ppass at hotmail dot fr Description: The script node's parent is a div. The script node has the text '' inside its script. The DOM node returns only partial contents of the script node, as if the node was mistakenly truncated when reaching the '' text. Reproduce code: --- $html = 'Titlefunction dummy { object.innerHTML="text"; } function dummy2 { alert("hello"); }'; $dom = new DOMDocument('1.0', 'UTF-8'); @$dom->loadHTML($html); $script_node = $dom->getElementById('script1'); Echo ""; Expected result: function dummy { object.innerHTML="text"; } function dummy2 { alert("hello"); } I expect to see the whole content of the script node. Actual result: -- function dummy { object.innerHTML="text The script node has been truncated. -- Edit this bug report at http://bugs.php.net/?id=49984&edit=1
#49244 [Asn->Csd]: [PATCH] Floating point NaN cause garbage characters
ID: 49244 Updated by: fel...@php.net Reported By: ronlentjes at yahoo dot com dot au -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux Fedora 8 PHP Version: 5.*, 6 (2009-09-20) -Assigned To: pajoye +Assigned To: felipe New Comment: This bug has been fixed in SVN. 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. Thanks for the patch. I've added more a change on the HEAD version because the different function for unicode stuff. Looks all right. Previous Comments: [2009-11-02 17:37:33] s...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=290150 Log: - Fixed bug #49244 (Floating point NaN cause garbage characters). (patch by Sjoerd) [2009-10-01 11:38:50] sjo...@php.net With the patch applied, I could not reproduce the problem anymore. Pajoye still has problems, so it is not clear whether the patch solves this bug. The patch can be found here: http://www.gissen.nl/files/bug49244.patch [2009-09-21 13:25:45] paj...@php.net Can you verify why your patch does not work in trunk please? There is still garbage. If you have a new patch, please post a link to it, the form breaks the patch format. [2009-09-20 10:24:28] sjo...@php.net I can't commit things. Somebody with SVN access should apply my patch and commit it. I've improved some things and added a testcase: Index: ext/standard/formatted_print.c === --- ext/standard/formatted_print.c (revision 288201) +++ ext/standard/formatted_print.c (working copy) @@ -42,6 +42,8 @@ #define FLOAT_PRECISION 6 #define MAX_FLOAT_DIGITS 38 #define MAX_FLOAT_PRECISION 40 +#define NOT_A_NUMBER "NaN" +#define INFINITE "INF" #if 0 /* trick to control varargs functions through cpp */ @@ -231,15 +233,15 @@ if (zend_isnan(number)) { is_negative = (number<0); - php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0, padding, -alignment, precision, is_negative, 0, always_sign); + php_sprintf_appendstring(buffer, pos, size, NOT_A_NUMBER, strlen(NOT_A_NUMBER), 0, padding, + alignment, strlen(NOT_A_NUMBER), is_negative, 0, always_sign); return; } if (zend_isinf(number)) { is_negative = (number<0); - php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0, padding, -alignment, precision, is_negative, 0, always_sign); + php_sprintf_appendstring(buffer, pos, size, INFINITE, strlen(INFINITE), 0, padding, + alignment, strlen(INFINITE), is_negative, 0, always_sign); return; } Index: ext/standard/tests/strings/bug49244.phpt === --- ext/standard/tests/strings/bug49244.phpt(revision 0) +++ ext/standard/tests/strings/bug49244.phpt(revision 0) @@ -0,0 +1,8 @@ +--TEST-- +Bug #49244 (Floating point NaN cause garbage characters) +--FILE-- + +--EXPECT-- +NaN [2009-09-01 16:34:22] garre...@php.net sjoerd -- That fix works fine for me. Can you commit that? 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/49244 -- Edit this bug report at http://bugs.php.net/?id=49244&edit=1
#33500 [Com]: imap_open() fails when the server advertises GSSAPI
ID: 33500 Comment by: nick at mailtrust dot com Reported By: ed2019 at columbia dot edu Status: Feedback Bug Type: Feature/Change Request Operating System: * PHP Version: 5.2.9 Assigned To: pajoye New Comment: It looks like you may have forgotten to add the following to your patch: Index: php_imap.c === --- php_imap.c(revision 3434) +++ php_imap.c(working copy) @@ -105,6 +105,7 @@ ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_open, 0, 0, 3) ZEND_ARG_INFO(0, mailbox) ZEND_ARG_INFO(0, user) ZEND_ARG_INFO(0, password) ZEND_ARG_INFO(0, options) ZEND_ARG_INFO(0, n_retries) + ZEND_ARG_INFO(0, params) ZEND_END_ARG_INFO() This should allow for a max of 6 arguments instead of just 5. Previous Comments: [2009-10-27 11:24:31] paj...@php.net It sounds like the patch was not applied then. It clearly takes 3 or 6 parameters: + if (zend_parse_parameters(argc TSRMLS_CC, "sss|lla", &mailbox, &mailbox_len, &user, &user_len, + &passwd, &passwd_len, &flags, &retries, ¶ms) == FAILURE) { Can you verify that the patch was actually applied? [2009-10-27 11:19:12] b dot parnell at abertay dot ac dot uk I have tried the patch and keep getting the error: Warning: Wrong parameter count for imap_open() I am using Ubuntu 9.04 and am compiling against the php 5.3.0 source with the associated patch applied and with the ./configure --with-imap --with-kerberos --with-imap-ssl initial command, make clean;make all;make install is the next commands I execute. I have also tried the source 5.3.1RC2 and this gives the error: Warning: imap_open() expects at most 5 parameters, 6 given If someone has managed to get this to work please provide a copy of the binaries until the release is rolled out to apt. Am I missing something here? Best Regards, Bill [2009-10-05 01:00:00] 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". [2009-09-27 16:42:42] paj...@php.net Please try this patch: http://pierre.libgd.org/patches/bug33500.txt (against PHP 5.3). It adds a parameter option to imap_open. For now only 'DISABLE_AUTHENTICATOR' is supported. Example usages: $im = imap_open($hostname, $username, $password, NULL, 1, array('DISABLE_AUTHENTICATOR' => array('GSSAPI', 'NTLM'))); $im = imap_open($hostname, $username, $password, NULL, 1, array('DISABLE_AUTHENTICATOR' => 'NTLM')); To disable respectively GSSAPI and NTLM or only NTLM. [2009-09-15 20:13:13] haggis at shaz-bot dot com any ETA of when this will be checked into SVN (and what files to pull)? We have run into this exact problem when we upgraded to Exchange 2007. 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/33500 -- Edit this bug report at http://bugs.php.net/?id=33500&edit=1
#50055 [Opn->Asn]: indeterminant DateInterval does not subtract correctly
ID: 50055 Updated by: der...@php.net Reported By: jennifer dot kimball at nrc dot ca -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Solaris 10 PHP Version: 5.3.0 -Assigned To: +Assigned To: derick New Comment: There is a bug here, but the only thing would be that "sub" can *not* be used with relative time strings such as "last ... of". It is logically too complicated (for people) to easily reverse strings like that. Such an attempt should throw an exception/error instead though. Previous Comments: [2009-11-02 15:07:18] jennifer dot kimball at nrc dot ca Description: The logical behaviour of a DateInterval created with the "next" keyword, when subtracted from a DateTime, should be to use "last" instead of "next" in the calculation (and vice versa). Instead, it appears that DateIntervals created with "next" or "last" keywords cannot be subtracted from DateTimes with any accuracy. A DateTime results from the operation but has an unexpected value. Reproduce code: --- //positive DateInterval $da1=date_create(); $ds1=date_create(); $i=DateInterval::createFromDateString('third Tuesday of next month'); echo $da1->format('Y-m-d'); echo date_add($da1,$i)->format('Y-m-d');//works echo date_sub($ds1,$i)->format('Y-m-d');//fails with weird date //negative DateInterval $da2=date_create(); $ds2=date_create(); $i2=DateInterval::createFromDateString('third Tuesday of last month'); echo $da2->format('Y-m-d'); echo date_add($da2,$i2)->format('Y-m-d');//works echo date_sub($ds2,$i2)->format('Y-m-d');//fails with weird date Expected result: 2009-11-02 //today 2009-12-15 //third Tuesday of December 2009-10-20 //third Tuesday of October 2009-11-02 //today 2009-10-20 //third Tuesday of October 2009-12-15 //third Tuesday of December Actual result: -- 2009-11-02 //today 2009-12-15 //third Tuesday of December 2009-09-18 //third Friday of September 2009-11-02 //today 2009-10-20 //third Tuesday of October 2009-11-18 //third Wednesday of November -- Edit this bug report at http://bugs.php.net/?id=50055&edit=1
#50029 [Opn->Ana]: Weird invoke issue on class as property
ID: 50029 Updated by: ka...@php.net Reported By: marc dot gray at gmail dot com -Status: Open +Status: Analyzed Bug Type: Class/Object related Operating System: Ubuntu 9.04 PHP Version: 5.3.0 New Comment: There was lots of discussion about this, because it could override class methods like: class Test { private $closure; public function __construct() { $this->closure = function() { echo 'Hello World'; }; } public function closure() { echo 'Hello PHP'; } public function call() { $this->closure(); } } $test = new Test; // Call Test::$closure or Test::closure() now? $test->call(); What you need to do is to copy the instance into a variable like: $closoure = $this->closure; $closure(); Previous Comments: [2009-10-29 01:15:36] marc dot gray at gmail dot com Description: Placing a class with an __invoke method as a property inside another class seems to nullify the invokeability of the original class. Tested on: Ubuntu 9.04, PHP 5.3.0 CentOS 5.3, PHP 5.2.11 ionCube / Suhosin Reproduce code: --- class a { function __construct() { } function __invoke() { echo("Invoked\n"); } } $a = new a(); $a(); // Prints: Invoked class b { private $x; function __construct() { $this->x = new a(); $this->x(); } } $b = new b(); // Issues error: undefined method b::x Expected result: I expect "new b()" construct to call the class a invoke Actual result: -- Undefined method - it doesn't seem to recognise the invokeable class property as actually invokeable. -- Edit this bug report at http://bugs.php.net/?id=50029&edit=1
#50055 [NEW]: indeterminant DateInterval does not subtract correctly
From: jennifer dot kimball at nrc dot ca Operating system: Solaris 10 PHP version: 5.3.0 PHP Bug Type: Date/time related Bug description: indeterminant DateInterval does not subtract correctly Description: The logical behaviour of a DateInterval created with the "next" keyword, when subtracted from a DateTime, should be to use "last" instead of "next" in the calculation (and vice versa). Instead, it appears that DateIntervals created with "next" or "last" keywords cannot be subtracted from DateTimes with any accuracy. A DateTime results from the operation but has an unexpected value. Reproduce code: --- //positive DateInterval $da1=date_create(); $ds1=date_create(); $i=DateInterval::createFromDateString('third Tuesday of next month'); echo $da1->format('Y-m-d'); echo date_add($da1,$i)->format('Y-m-d');//works echo date_sub($ds1,$i)->format('Y-m-d');//fails with weird date //negative DateInterval $da2=date_create(); $ds2=date_create(); $i2=DateInterval::createFromDateString('third Tuesday of last month'); echo $da2->format('Y-m-d'); echo date_add($da2,$i2)->format('Y-m-d');//works echo date_sub($ds2,$i2)->format('Y-m-d');//fails with weird date Expected result: 2009-11-02 //today 2009-12-15 //third Tuesday of December 2009-10-20 //third Tuesday of October 2009-11-02 //today 2009-10-20 //third Tuesday of October 2009-12-15 //third Tuesday of December Actual result: -- 2009-11-02 //today 2009-12-15 //third Tuesday of December 2009-09-18 //third Friday of September 2009-11-02 //today 2009-10-20 //third Tuesday of October 2009-11-18 //third Wednesday of November -- Edit bug report at http://bugs.php.net/?id=50055&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50055&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50055&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50055&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50055&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50055&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50055&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50055&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50055&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50055&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50055&r=support Expected behavior: http://bugs.php.net/fix.php?id=50055&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50055&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50055&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50055&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50055&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50055&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50055&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50055&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50055&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50055&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50055&r=mysqlcfg
#50054 [NEW]: magick/semaphore.c Assertion
From: technik at cyberagent dot de Operating system: Debian 5.0.3 Linux version 2.6.2 PHP version: 5.3.0 PHP Bug Type: Reproducible crash Bug description: magick/semaphore.c Assertion Description: goofy:~ # php -m [PHP Modules] Core ctype curl date dom ereg facedetect fileinfo filter ftp gd geoip gettext hash iconv idn imagick imap json libpuzzle libxml lzf magickwand mbstring mcrypt memcache mhash mysql mysqli openssl pcre PDO pdo_sqlite Phar posix Reflection session SimpleXML SPL SQLite sqlite3 standard tidy tokenizer xml xmlreader xmlwriter xsl zip zlib [Zend Modules] php: magick/semaphore.c:288: LockSemaphoreInfo: Assertion `semaphore_info != (SemmaphoreInfo *) ((void *)0)' failed. Aborted goofy:~ # (assertion occures on every php call) Reproduce code: --- none -- Edit bug report at http://bugs.php.net/?id=50054&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50054&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50054&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50054&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50054&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50054&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50054&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50054&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50054&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50054&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50054&r=support Expected behavior: http://bugs.php.net/fix.php?id=50054&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50054&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50054&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50054&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50054&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50054&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50054&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50054&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50054&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50054&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50054&r=mysqlcfg
#50052 [Fbk->Asn]: Crypt - Different Hashes on Windows and Linux on wrong Salt size
ID: 50052 Updated by: paj...@php.net Reported By: otaviodiniz at gmail dot com -Status: Feedback +Status: Assigned Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.0 -Assigned To: +Assigned To: pajoye Previous Comments: [2009-11-02 13:57:13] otaviodiniz at gmail dot com As you can see the output are different in 5.2 and 5.3 near 0$or 01or. [2009-11-02 09:59:54] paj...@php.net Forgot to copy 5.3 output as well: g:\php-sdk\php53\vc9\x86\php53>..\obj\Debug\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF01orVloNmKSLvOeswusE0bY. [2009-11-02 09:46:31] paj...@php.net Cannot reproduce: g:\php-sdk\php53\vc9\x8\php53>\test\php52ntssnap\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. Please try using VC9-x86 binaries, http://windows.php.net/snapshots/ [2009-11-02 02:39:32] otaviodiniz at gmail dot com Description: The behave of Crypt function on Windows and Linux boxes are different. In the sample function we create a Salt with length of 12 characters. First, the Salt size is incorrect, if i remove one character the Salt, the result will be correct. But with the wrong Salt size the behavior are different: On Windows - The output is incorrect, as it shows the whole Salt without the terminator $... On Linux - PHP strips one character of Salt into it's correct expected size, outputing correctly with the terminator $... Reproduce code: --- md5crypt("test"); function md5crypt($password) { $base64_alphabet='ABCDEFGHIJKLMNOPQRSTUVWXYZ' .'abcdefghijklmnopqrstuvwxyz0123456789+/'; $salt='$1$'; for($i=0; $i<9; $i++) { $salt.=$base64_alphabet[rand(0,63)]; } $salt.='$'; echo ""; echo "Salt: ".$salt."\r\n"; echo "Output: ".crypt($password,$salt); echo ""; } Expected result: Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. //Linux Actual result: -- Salt: $1$XcPmtBmRG$ Output: $1$XcPmtBmRGuM82Sm1HMy0I0lX0P3nAd0 //Windows -- Edit this bug report at http://bugs.php.net/?id=50052&edit=1
#50052 [Com]: Crypt - Different Hashes on Windows and Linux on wrong Salt size
ID: 50052 Comment by: otaviodiniz at gmail dot com Reported By: otaviodiniz at gmail dot com Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.0 New Comment: As you can see the output are different in 5.2 and 5.3 near 0$or 01or. Previous Comments: [2009-11-02 09:59:54] paj...@php.net Forgot to copy 5.3 output as well: g:\php-sdk\php53\vc9\x86\php53>..\obj\Debug\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF01orVloNmKSLvOeswusE0bY. [2009-11-02 09:46:31] paj...@php.net Cannot reproduce: g:\php-sdk\php53\vc9\x8\php53>\test\php52ntssnap\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. Please try using VC9-x86 binaries, http://windows.php.net/snapshots/ [2009-11-02 02:39:32] otaviodiniz at gmail dot com Description: The behave of Crypt function on Windows and Linux boxes are different. In the sample function we create a Salt with length of 12 characters. First, the Salt size is incorrect, if i remove one character the Salt, the result will be correct. But with the wrong Salt size the behavior are different: On Windows - The output is incorrect, as it shows the whole Salt without the terminator $... On Linux - PHP strips one character of Salt into it's correct expected size, outputing correctly with the terminator $... Reproduce code: --- md5crypt("test"); function md5crypt($password) { $base64_alphabet='ABCDEFGHIJKLMNOPQRSTUVWXYZ' .'abcdefghijklmnopqrstuvwxyz0123456789+/'; $salt='$1$'; for($i=0; $i<9; $i++) { $salt.=$base64_alphabet[rand(0,63)]; } $salt.='$'; echo ""; echo "Salt: ".$salt."\r\n"; echo "Output: ".crypt($password,$salt); echo ""; } Expected result: Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. //Linux Actual result: -- Salt: $1$XcPmtBmRG$ Output: $1$XcPmtBmRGuM82Sm1HMy0I0lX0P3nAd0 //Windows -- Edit this bug report at http://bugs.php.net/?id=50052&edit=1
#49984 [Bgs]: DOM model is completely broken
ID: 49984 User updated by: ppass at hotmail dot fr Reported By: ppass at hotmail dot fr Status: Bogus Bug Type: DOM XML related Operating System: Linux ns1 2.6.28.4-rsbac PHP Version: 5.2.11 New Comment: That you for details, I just filed a bug in their system. Previous Comments: [2009-11-02 06:53:03] ras...@php.net We didn't write the DOM implementation. We are simply using libxml2. Information on how to file a bug against libxml2 is here: http://xmlsoft.org/bugs.html But I suspect they won't consider this a bug. Their relaxed html parser isn't a full html parser that knows about embedded script objects. This would only be a PHP bug if we are somehow calling libxml2 incorrectly causing this, but it doesn't appear to be the case here. [2009-11-02 05:42:09] ppass at hotmail dot fr No reaction still to this bug. Maybe my previous title was too specific. More generally speaking, it means that the DOM model is broken in php when ever a script tag contains other tags in its text. This is a serious bug that must be corrected asap, other wise it is not possible to make a reliable use of DOM. [2009-10-24 04:27:57] ppass at hotmail dot fr Description: The script node's parent is a div. The script node has the text '' inside its script. The DOM node returns only partial contents of the script node, as if the node was mistakenly truncated when reaching the '' text. Reproduce code: --- $html = 'Titlefunction dummy { object.innerHTML="text"; } function dummy2 { alert("hello"); }'; $dom = new DOMDocument('1.0', 'UTF-8'); @$dom->loadHTML($html); $script_node = $dom->getElementById('script1'); Echo ""; Expected result: function dummy { object.innerHTML="text"; } function dummy2 { alert("hello"); } I expect to see the whole content of the script node. Actual result: -- function dummy { object.innerHTML="text The script node has been truncated. -- Edit this bug report at http://bugs.php.net/?id=49984&edit=1
#43526 [Asn->Csd]: fixing warnings/errors in pgsql.c
ID: 43526 Updated by: il...@php.net Reported By: mi+php at aldan dot algebra dot com -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: FreeBSD/amd64 PHP Version: 5.2.5 Assigned To: iliaa New Comment: This bug has been fixed in SVN. 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: [2007-12-07 06:21:44] mi+php at aldan dot algebra dot com Change the Summary to reflect the contents of /this/ bug report. [2007-12-07 05:18:50] mi+php at aldan dot algebra dot com Description: The pgsql.c extension fails to compile on a 64-bit system, when ``-Wall -Werror'' are enabled. Some of the raised warnings point to likely programming mistakes, such as when a pointer is casted to int, which loses bits wherever void* is wider than int. The patch at http://virtual-estates.com/~mi/port-stuff/patch-pgsql-64bit fixes this. It requires the earlier submitted patch for zend_list functions, or else the pointer's bits will be truncated by the call to zend_list_find anyway. -- Edit this bug report at http://bugs.php.net/?id=43526&edit=1
#50048 [Bgs]: Strtotime Last fails
ID: 50048 User updated by: arnbme at gmail dot com Reported By: arnbme at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Wamp or Linux PHP Version: 5.3.0 New Comment: DateInterval::__construct (PHP 5 >= 5.3.0) My Wamp server, that I use for development runs PHP 5.3, 5.2.11 and 5.2.9. My commercial web host runs PHP 5.2.9 and my code was initially developed in PHP 3 something, hence my use of strtotime, but thank you for a way to code future dates in PHP >=5.3 BTW you have a coding error in your example db = new DateTime('2008-12-31'); should be $db = new DateTime('2008-12-31'); Au revoir (beam me out of here Scotty) Previous Comments: [2009-11-02 11:28:41] ras...@php.net You also seem to imply that strtotime() should have some sort of bias toward future dates? That makes no sense. You need dates in the past almost as often as you need dates in the future. [2009-11-02 11:25:57] ras...@php.net For repeating events like that use a DateInterval. For example, this will give you the last Tuesday of every month of 2009: db = new DateTime('2008-12-31'); $de = new DateTime('2009-12-31'); $di = DateInterval::createFromDateString('last tuesday of next month'); $dp = new DatePeriod($db, $di, $de, DatePeriod::EXCLUDE_START_DATE); foreach($dp as $dt) { echo $dt->format("F jS\n") . "\n"; } [2009-11-02 11:22:42] arnbme at gmail dot com It's also common to set repeating events such as meetings on the "nth" or "last" "weekday" of a month. As far as I know no one has yet learned how to hold an event on the last day of a prior month, unless we are holding the last event in a handbasket. [2009-11-02 07:19:52] ras...@php.net No, in common English usage, when you just say "last Sunday" it means the previous Sunday. eg. "Where were you last Sunday?" You have to be explicit and say: "What date is the last Sunday of November?" Then the English makes sense, and if you try that with strtotime() you will find that it works. eg. strtotime("last Sunday of November") [2009-11-02 01:14:01] arnbme at gmail dot com It would seem my interpretation of "last" varies from the one used by PHP strtotime. I assumed "last Sunday" means the last date that was a Sunday in the month specified by now, similar to how "4 Sunday" moves forward in time, however PHP strtotme apparently interprets "last" to mean "prior" in which case it is operating as designed. Example 1 for strtotime does not show any results. If documentation for using last with strtotime is available please post a link. 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/50048 -- Edit this bug report at http://bugs.php.net/?id=50048&edit=1
#49367 [Opn->WFx]: Automatic type casting for the variable function name
ID: 49367 Updated by: col...@php.net Reported By: kexianbin at diyism dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.3.1 New Comment: If you want to handle what goes on when $o(); is used, see the __invoke() magic method Previous Comments: [2009-11-02 08:57:26] kexianbin at diyism dot com Change expected version to 5.3.1 from 5.3.0 [2009-08-26 03:02:21] kexianbin at diyism dot com In fact, i make the above request for the "SoWork PHP Framework": val; break; } } $tmp=eval('return defined("'.$fun.'")?constant("'.$fun.'"):"'.$fun.'";'); $this->val=call_user_func_array($tmp, $pars); return $this; } function __toString() {return 'so_work'; } function cls_so_work() {$obj=func_get_args(); $this->val=isset($obj[0])?$obj[0]:null; } } function so_work() {$obj=func_get_args(); if (isset($obj[0])) {return new cls_so_work($obj[0]); } else {if (!isset($GLOABALS['so_work'])) {$GLOABALS['so_work']=new cls_so_work(); } else {$GLOABALS['so_work']->val=null; } return $GLOABALS['so_work']; } } $o=so_work(); define('echo', 'my_echo'); function my_echo($obj) {echo $obj; return $obj; } //$o('abcd')->substr(this, 2, 2)->strlen(this)->echo(this); $o->substr('abcd', 1, 3)->strlen(this)->echo(this); ?> The commented line in the end will raise the error. [2009-08-26 02:57:13] kexianbin at diyism dot com Description: Currently, php 5.3.0 doesn't support automatic type casting for the variable function name, we indeed need it, it could lead to very cool applications. Reproduce code: --- '; $o(); ?> Expected result: so_work hello Actual result: -- so_work Fatal error: Function name must be a string in E:\WWW\PhpApps\test\test.php on line 18 -- Edit this bug report at http://bugs.php.net/?id=49367&edit=1
#50048 [Bgs]: Strtotime Last fails
ID: 50048 Updated by: ras...@php.net Reported By: arnbme at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Wamp or Linux PHP Version: 5.3.0 New Comment: You also seem to imply that strtotime() should have some sort of bias toward future dates? That makes no sense. You need dates in the past almost as often as you need dates in the future. Previous Comments: [2009-11-02 11:25:57] ras...@php.net For repeating events like that use a DateInterval. For example, this will give you the last Tuesday of every month of 2009: db = new DateTime('2008-12-31'); $de = new DateTime('2009-12-31'); $di = DateInterval::createFromDateString('last tuesday of next month'); $dp = new DatePeriod($db, $di, $de, DatePeriod::EXCLUDE_START_DATE); foreach($dp as $dt) { echo $dt->format("F jS\n") . "\n"; } [2009-11-02 11:22:42] arnbme at gmail dot com It's also common to set repeating events such as meetings on the "nth" or "last" "weekday" of a month. As far as I know no one has yet learned how to hold an event on the last day of a prior month, unless we are holding the last event in a handbasket. [2009-11-02 07:19:52] ras...@php.net No, in common English usage, when you just say "last Sunday" it means the previous Sunday. eg. "Where were you last Sunday?" You have to be explicit and say: "What date is the last Sunday of November?" Then the English makes sense, and if you try that with strtotime() you will find that it works. eg. strtotime("last Sunday of November") [2009-11-02 01:14:01] arnbme at gmail dot com It would seem my interpretation of "last" varies from the one used by PHP strtotime. I assumed "last Sunday" means the last date that was a Sunday in the month specified by now, similar to how "4 Sunday" moves forward in time, however PHP strtotme apparently interprets "last" to mean "prior" in which case it is operating as designed. Example 1 for strtotime does not show any results. If documentation for using last with strtotime is available please post a link. [2009-11-01 20:00:28] sjo...@php.net Thank you for your bug report. Your example prints the last Sunday for December 1st, 2009. The Sunday before that date is November 29th. Can you explain why you think the output is wrong? Also, could you provide a shorter reproduce script, like this: 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/50048 -- Edit this bug report at http://bugs.php.net/?id=50048&edit=1
#50048 [Bgs]: Strtotime Last fails
ID: 50048 Updated by: ras...@php.net Reported By: arnbme at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Wamp or Linux PHP Version: 5.3.0 New Comment: For repeating events like that use a DateInterval. For example, this will give you the last Tuesday of every month of 2009: db = new DateTime('2008-12-31'); $de = new DateTime('2009-12-31'); $di = DateInterval::createFromDateString('last tuesday of next month'); $dp = new DatePeriod($db, $di, $de, DatePeriod::EXCLUDE_START_DATE); foreach($dp as $dt) { echo $dt->format("F jS\n") . "\n"; } Previous Comments: [2009-11-02 11:22:42] arnbme at gmail dot com It's also common to set repeating events such as meetings on the "nth" or "last" "weekday" of a month. As far as I know no one has yet learned how to hold an event on the last day of a prior month, unless we are holding the last event in a handbasket. [2009-11-02 07:19:52] ras...@php.net No, in common English usage, when you just say "last Sunday" it means the previous Sunday. eg. "Where were you last Sunday?" You have to be explicit and say: "What date is the last Sunday of November?" Then the English makes sense, and if you try that with strtotime() you will find that it works. eg. strtotime("last Sunday of November") [2009-11-02 01:14:01] arnbme at gmail dot com It would seem my interpretation of "last" varies from the one used by PHP strtotime. I assumed "last Sunday" means the last date that was a Sunday in the month specified by now, similar to how "4 Sunday" moves forward in time, however PHP strtotme apparently interprets "last" to mean "prior" in which case it is operating as designed. Example 1 for strtotime does not show any results. If documentation for using last with strtotime is available please post a link. [2009-11-01 20:00:28] sjo...@php.net Thank you for your bug report. Your example prints the last Sunday for December 1st, 2009. The Sunday before that date is November 29th. Can you explain why you think the output is wrong? Also, could you provide a shorter reproduce script, like this: [2009-11-01 14:12:20] arnbme at gmail dot com Description: the last option of strtotime seems to ignore the int $now parameter. Reproduce code: --- '; $mths = array("","January","February","March","April","May","June","July","August","September","October","November","December"); $x = strtotime('2009-11-29'); //date to age $Year = date("Y",$x); $Month = date("m",$x); if ($Month == 12){ $Year++; $Month = 1;} else $Month++; $n=strtotime($mths[$Month].' 01, '.$Year); echo 'base date:',date("Y-m-d",$n),$br; if ($n==false) die ('bad date'); $nextdt=date( "Y-m-d",strtotime("last Sunday", $n)); echo 'Calc Last:',$nextdt,$br; //result is 2009-11-29 should be 2009-12-27 ?> Expected result: Should show 2009-12-27 Actual result: -- 2009-11-29 -- Edit this bug report at http://bugs.php.net/?id=50048&edit=1
#50048 [Bgs]: Strtotime Last fails
ID: 50048 User updated by: arnbme at gmail dot com Reported By: arnbme at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Wamp or Linux PHP Version: 5.3.0 New Comment: It's also common to set repeating events such as meetings on the "nth" or "last" "weekday" of a month. As far as I know no one has yet learned how to hold an event on the last day of a prior month, unless we are holding the last event in a handbasket. Previous Comments: [2009-11-02 07:19:52] ras...@php.net No, in common English usage, when you just say "last Sunday" it means the previous Sunday. eg. "Where were you last Sunday?" You have to be explicit and say: "What date is the last Sunday of November?" Then the English makes sense, and if you try that with strtotime() you will find that it works. eg. strtotime("last Sunday of November") [2009-11-02 01:14:01] arnbme at gmail dot com It would seem my interpretation of "last" varies from the one used by PHP strtotime. I assumed "last Sunday" means the last date that was a Sunday in the month specified by now, similar to how "4 Sunday" moves forward in time, however PHP strtotme apparently interprets "last" to mean "prior" in which case it is operating as designed. Example 1 for strtotime does not show any results. If documentation for using last with strtotime is available please post a link. [2009-11-01 20:00:28] sjo...@php.net Thank you for your bug report. Your example prints the last Sunday for December 1st, 2009. The Sunday before that date is November 29th. Can you explain why you think the output is wrong? Also, could you provide a shorter reproduce script, like this: [2009-11-01 14:12:20] arnbme at gmail dot com Description: the last option of strtotime seems to ignore the int $now parameter. Reproduce code: --- '; $mths = array("","January","February","March","April","May","June","July","August","September","October","November","December"); $x = strtotime('2009-11-29'); //date to age $Year = date("Y",$x); $Month = date("m",$x); if ($Month == 12){ $Year++; $Month = 1;} else $Month++; $n=strtotime($mths[$Month].' 01, '.$Year); echo 'base date:',date("Y-m-d",$n),$br; if ($n==false) die ('bad date'); $nextdt=date( "Y-m-d",strtotime("last Sunday", $n)); echo 'Calc Last:',$nextdt,$br; //result is 2009-11-29 should be 2009-12-27 ?> Expected result: Should show 2009-12-27 Actual result: -- 2009-11-29 -- Edit this bug report at http://bugs.php.net/?id=50048&edit=1
#50053 [Opn->Bgs]: php always crashes
ID: 50053 Updated by: paj...@php.net Reported By: david at zhang-it dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: windows vista PHP Version: 5.2.11 New Comment: Disable openssl in your php.ini if you don't want to use it. Previous Comments: [2009-11-02 10:57:02] david at zhang-it dot com Description: I download and install the current 5.2.11 php windows installer package. I do not install any extensions. PHP will crash. Only if i install the OpenSSL extension PHP may run. Reproduce code: --- c:\> php any-php-file.php Actual result: -- SSLEAY32.dll not found! -- Edit this bug report at http://bugs.php.net/?id=50053&edit=1
#50053 [NEW]: php always crashes
From: david at zhang-it dot com Operating system: windows vista PHP version: 5.2.11 PHP Bug Type: Reproducible crash Bug description: php always crashes Description: I download and install the current 5.2.11 php windows installer package. I do not install any extensions. PHP will crash. Only if i install the OpenSSL extension PHP may run. Reproduce code: --- c:\> php any-php-file.php Actual result: -- SSLEAY32.dll not found! -- Edit bug report at http://bugs.php.net/?id=50053&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50053&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50053&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50053&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50053&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50053&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50053&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50053&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50053&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50053&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50053&r=support Expected behavior: http://bugs.php.net/fix.php?id=50053&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50053&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50053&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50053&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50053&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50053&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50053&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50053&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50053&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50053&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50053&r=mysqlcfg
#50052 [Fbk]: Crypt - Different Hashes on Windows and Linux on wrong Salt size
ID: 50052 Updated by: paj...@php.net Reported By: otaviodiniz at gmail dot com Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.0 New Comment: Forgot to copy 5.3 output as well: g:\php-sdk\php53\vc9\x86\php53>..\obj\Debug\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF01orVloNmKSLvOeswusE0bY. Previous Comments: [2009-11-02 09:46:31] paj...@php.net Cannot reproduce: g:\php-sdk\php53\vc9\x8\php53>\test\php52ntssnap\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. Please try using VC9-x86 binaries, http://windows.php.net/snapshots/ [2009-11-02 02:39:32] otaviodiniz at gmail dot com Description: The behave of Crypt function on Windows and Linux boxes are different. In the sample function we create a Salt with length of 12 characters. First, the Salt size is incorrect, if i remove one character the Salt, the result will be correct. But with the wrong Salt size the behavior are different: On Windows - The output is incorrect, as it shows the whole Salt without the terminator $... On Linux - PHP strips one character of Salt into it's correct expected size, outputing correctly with the terminator $... Reproduce code: --- md5crypt("test"); function md5crypt($password) { $base64_alphabet='ABCDEFGHIJKLMNOPQRSTUVWXYZ' .'abcdefghijklmnopqrstuvwxyz0123456789+/'; $salt='$1$'; for($i=0; $i<9; $i++) { $salt.=$base64_alphabet[rand(0,63)]; } $salt.='$'; echo ""; echo "Salt: ".$salt."\r\n"; echo "Output: ".crypt($password,$salt); echo ""; } Expected result: Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. //Linux Actual result: -- Salt: $1$XcPmtBmRG$ Output: $1$XcPmtBmRGuM82Sm1HMy0I0lX0P3nAd0 //Windows -- Edit this bug report at http://bugs.php.net/?id=50052&edit=1
#50052 [Opn->Fbk]: Crypt - Different Hashes on Windows and Linux on wrong Salt size
ID: 50052 Updated by: paj...@php.net Reported By: otaviodiniz at gmail dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.0 New Comment: Cannot reproduce: g:\php-sdk\php53\vc9\x8\php53>\test\php52ntssnap\php.exe ..\50052.php Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. Please try using VC9-x86 binaries, http://windows.php.net/snapshots/ Previous Comments: [2009-11-02 02:39:32] otaviodiniz at gmail dot com Description: The behave of Crypt function on Windows and Linux boxes are different. In the sample function we create a Salt with length of 12 characters. First, the Salt size is incorrect, if i remove one character the Salt, the result will be correct. But with the wrong Salt size the behavior are different: On Windows - The output is incorrect, as it shows the whole Salt without the terminator $... On Linux - PHP strips one character of Salt into it's correct expected size, outputing correctly with the terminator $... Reproduce code: --- md5crypt("test"); function md5crypt($password) { $base64_alphabet='ABCDEFGHIJKLMNOPQRSTUVWXYZ' .'abcdefghijklmnopqrstuvwxyz0123456789+/'; $salt='$1$'; for($i=0; $i<9; $i++) { $salt.=$base64_alphabet[rand(0,63)]; } $salt.='$'; echo ""; echo "Salt: ".$salt."\r\n"; echo "Output: ".crypt($password,$salt); echo ""; } Expected result: Salt: $1$f+uslYF01$ Output: $1$f+uslYF0$orVloNmKSLvOeswusE0bY. //Linux Actual result: -- Salt: $1$XcPmtBmRG$ Output: $1$XcPmtBmRGuM82Sm1HMy0I0lX0P3nAd0 //Windows -- Edit this bug report at http://bugs.php.net/?id=50052&edit=1
#49367 [Opn]: Automatic type casting for the variable function name
ID: 49367 User updated by: kexianbin at diyism dot com Reported By: kexianbin at diyism dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux -PHP Version: 5.3.0 +PHP Version: 5.3.1 New Comment: Change expected version to 5.3.1 from 5.3.0 Previous Comments: [2009-08-26 03:02:21] kexianbin at diyism dot com In fact, i make the above request for the "SoWork PHP Framework": val; break; } } $tmp=eval('return defined("'.$fun.'")?constant("'.$fun.'"):"'.$fun.'";'); $this->val=call_user_func_array($tmp, $pars); return $this; } function __toString() {return 'so_work'; } function cls_so_work() {$obj=func_get_args(); $this->val=isset($obj[0])?$obj[0]:null; } } function so_work() {$obj=func_get_args(); if (isset($obj[0])) {return new cls_so_work($obj[0]); } else {if (!isset($GLOABALS['so_work'])) {$GLOABALS['so_work']=new cls_so_work(); } else {$GLOABALS['so_work']->val=null; } return $GLOABALS['so_work']; } } $o=so_work(); define('echo', 'my_echo'); function my_echo($obj) {echo $obj; return $obj; } //$o('abcd')->substr(this, 2, 2)->strlen(this)->echo(this); $o->substr('abcd', 1, 3)->strlen(this)->echo(this); ?> The commented line in the end will raise the error. [2009-08-26 02:57:13] kexianbin at diyism dot com Description: Currently, php 5.3.0 doesn't support automatic type casting for the variable function name, we indeed need it, it could lead to very cool applications. Reproduce code: --- '; $o(); ?> Expected result: so_work hello Actual result: -- so_work Fatal error: Function name must be a string in E:\WWW\PhpApps\test\test.php on line 18 -- Edit this bug report at http://bugs.php.net/?id=49367&edit=1