# PHP 5.1 - Thread: https://externals.io/message/18543 - Original archive: https://news-web.php.net/php.internals/18543 - Started by Zeev Suraski on 2005-08-30T02:06:07+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #18543 — Zeev Suraski — 2005-08-30T02:06:07+00:00 URL: https://externals.io/message/18543#18543 For those of you who submitted patches to 5.1 since RC1 - do you believe that we need another RC or can we go ahead and roll 5.1 final and run a sanity test for 24 hours? I went over the patches, none of them appears to be too dangerous, but if any of you thinks differently, let me know. Zeev --- ## #18548 — Michael Wallner — 2005-08-30T06:58:49+00:00 URL: https://externals.io/message/18543#18548 · In reply to: #18543 Hi Zeev Suraski, you wrote: > For those of you who submitted patches to 5.1 since RC1 - do you believe > that we need another RC or can we go ahead and roll 5.1 final and run a > sanity test for 24 hours? I went over the patches, none of them appears > to be too dangerous, but if any of you thinks differently, let me know. Well, I don't know if there has been any progress for static properties of internal classes. I can understand if there has not been yet, but it would be a pity to leave that out for 5.1 though. I know, unfortunately I'm the only one bashing on this piece of the engine :) Additionally I didn't see the instanceof change comitted to 5.1 as Andi suggested, so is this gonna happen? Thanks a lot, -- Michael - < mike(@)php.net --- ## #18549 — Pierre-Alain Joye — 2005-08-30T07:28:25+00:00 URL: https://externals.io/message/18543#18549 · In reply to: #18543 On Tue, 30 Aug 2005 05:06:07 +0300 zeev@zend.com (Zeev Suraski) wrote: > For those of you who submitted patches to 5.1 since RC1 - do you > believe that we need another RC or can we go ahead and roll 5.1 > final and run a sanity test for 24 hours? I went over the > patches, none of them appears to be too dangerous, but if any of > you thinks differently, let me know. At least one patch has to be MFH'ed, the new instanceof commited by Dmitri last week. Besides that, a last RC is a safe choice, quiet a lot of commits have been done since RC1. Regards, --Pierre --- ## #18564 — Wez Furlong — 2005-08-30T13:39:35+00:00 URL: https://externals.io/message/18543#18564 · In reply to: #18543 There's a bunch of open PDO bugs that need to be fixed before we go with 5.1 final. --Wez. > For those of you who submitted patches to 5.1 since RC1 - do you believe > that we need another RC or can we go ahead and roll 5.1 final and run a > sanity test for 24 hours? I went over the patches, none of them appears to > be too dangerous, but if any of you thinks differently, let me know. > > Zeev --- ## #18570 — Rasmus Lerdorf — 2005-08-30T17:30:56+00:00 URL: https://externals.io/message/18543#18570 · In reply to: #18564 Wez Furlong wrote: > There's a bunch of open PDO bugs that need to be fixed before we go > with 5.1 final. Do you have some sort of plan/timeline for these getting fixed? Do you need some help? We can't wait indefinitely on PDO. If you have a list of outstanding issues I can throw some resources at it. Also, I see the following 6 failed test cases on my Linux box: -Bug #33414 [2] (Comprehensive list of incorrect days returned after strotime() / `date()` tests) [ext/date/tests/bug33414-2.phpt] -Bug #16069 [ext/iconv/tests/bug16069.phpt] -iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt] -Bug #31142 test #2 (imap_mail_compose() generates incorrect output) [ext/imap/tests/bug31142_2.phpt] -various `fputcsv()` functionality tests [ext/standard/tests/file/fputcsv.phpt] -Bug #27908 (default handler not being called) [ext/xml/tests/bug27908.phpt] -Rasmus --- ## #18571 — Rasmus Lerdorf — 2005-08-30T18:14:11+00:00 URL: https://externals.io/message/18543#18571 · In reply to: #18570 Would probably help if I included the diffs: > -Bug #33414 [2] (Comprehensive list of incorrect days returned after > strotime() / `date()` tests) [ext/date/tests/bug33414-2.phpt] 033+ result=Wednesday 1970-01-07 00:00:00 PST 0 033- result=Wednesday 1970-01-06 00:00:00 PST 0 > -Bug #16069 [ext/iconv/tests/bug16069.phpt] 001+ ????????????????????????????????????????(?맥??) 001- ?ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С??? ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ? С???ߥ?С???ߥ?С???(?맥??) > -iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt] (related to the last one it looks like) 007+ string(20) "1b244f24332466245824" 008+ string(10) "4e24421b28" 009+ string(2) "4f" 007- 008- Warning: `fread()`: iconv stream filter ("ISO-2022-JP"=>"EUC-JP"): invalid multibyte sequence in %s on line %d 009- string(0) "" 010- string(0) "" 011- string(0) "" > -Bug #31142 test #2 (imap_mail_compose() generates incorrect output) > [ext/imap/tests/bug31142_2.phpt] This one is caused by a segfault. bt is: #0 0x407545c8 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x40906dd8 in free () from /lib/libc.so.6 #2 0x40073d93 in fs_give () from /usr/lib/libc-client.so.2001 #3 0x40070b5b in mail_free_body_parameter () from /usr/lib/libc-client.so.2001 #4 0x40070a5c in mail_free_body_data () from /usr/lib/libc-client.so.2001 #5 0x40070996 in mail_free_body () from /usr/lib/libc-client.so.2001 #6 0x080f797f in zif_imap_mail_compose (ht=2, return_value=0x84b3ebc, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/rasmus/php51/ext/imap/php_imap.c:3240 #7 0x08276526 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffd6f0) at zend_vm_execute.h:184 #8 0x08275d49 in execute (op_array=0x84af31c) at zend_vm_execute.h:87 #9 0x0825540c in zend_execute_scripts (type=8, retval=Variable "retval" is not available. ) at /home/rasmus/php51/Zend/zend.c:1078 #10 0x0821eb1b in php_execute_script (primary_file=0xbffffaac) at /home/rasmus/php51/main/main.c:1675 #11 0x082dd78a in main (argc=3, argv=0xbffffb64) at /home/rasmus/php51/sapi/cli/php_cli.c:1039 Probably do to a bogus pthread-enabled libc-client on this Debian box. > -various `fputcsv()` functionality tests > [ext/standard/tests/file/fputcsv.phpt] 040+ 16 => 'aaa,"\\"bbb",ccc', 041+ 17 => 'aaa"\\"a""","bbb"', 042+ 18 => '"\\""","aaa"""', 043+ 19 => '"\\"""",aaa 044+ ', 040- 16 => 'aaa,"\\"bbb,ccc', 041- 17 => 'aaa"\\"a","bbb"', 042- 18 => '"\\"","aaa"', 043- 19 => '"\\""",aaa', > -Bug #27908 (default handler not being called) [ext/xml/tests/bug27908.phpt] 001- x_default_handler 002- x_default_handler -Rasmus --- ## #18572 — Andi Gutmans — 2005-08-30T18:30:52+00:00 URL: https://externals.io/message/18543#18572 · In reply to: #18548 At 11:58 PM 8/29/2005, Michael Wallner wrote: >Additionally I didn't see the instanceof change comitted to 5.1 as Andi >suggested, so is this gonna happen? That was commited. Did you check HEAD? Andi --- ## #18579 — Andrei Zmievski — 2005-08-30T20:16:43+00:00 URL: https://externals.io/message/18543#18579 · In reply to: #18570 > Also, I see the following 6 failed test cases on my Linux box: > > -Bug #16069 [ext/iconv/tests/bug16069.phpt] According to the last two comments in that bug report, glibc `iconv()` does not support CP932 and this test should be skipped instead of failing. No idea how to check for that in the test system, so I'll leave it to Jani or someone else. > -iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt] This test exhibits wildly different behavior depending on the platform and/or version of iconv library. On BSD the last portion of it fails with "unknown error" instead of "invalid multibyte sequence". On Linux (with glibc iconv) it moronically goes ahead and actually decodes the ROT-13 "encrypted" data without outputting any errors. I don't think there's much we can do here unless we're willing to invest an inordinate amount of effort into tracking down specific `iconv()` versions and making allowances for them everywhere. -Andrei --- ## #18580 — Derick Rethans — 2005-08-30T21:10:39+00:00 URL: https://externals.io/message/18543#18580 · In reply to: #18571 > Would probably help if I included the diffs: > > > […] > > 033+ result=Wednesday 1970-01-07 00:00:00 PST 0 > 033- result=Wednesday 1970-01-06 00:00:00 PST 0 I already had a look at this, but am not totally done implementing a fix. Will try to do this ASAP. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #18581 — Marcus Boerger — 2005-08-30T21:32:00+00:00 URL: https://externals.io/message/18543#18581 · In reply to: #18579 Hello Andrei, Tuesday, August 30, 2005, 10:16:43 PM, you wrote: > > > […] > According to the last two comments in that bug report, glibc `iconv()` > does not support CP932 and this test should be skipped instead of > failing. No idea how to check for that in the test system, so I'll > leave it to Jani or someone else. > > […] > This test exhibits wildly different behavior depending on the platform > and/or version of iconv library. On BSD the last portion of it fails > with "unknown error" instead of "invalid multibyte sequence". On Linux > (with glibc iconv) it moronically goes ahead and actually decodes the > ROT-13 "encrypted" data without outputting any errors. I don't think > there's much we can do here unless we're willing to invest an > inordinate amount of effort into tracking down specific `iconv()` > versions and making allowances for them everywhere. In this case at least the result should be WARN instead of FAIL. Best regards, Marcus --- ## #18584 — Ilia Alshanetsky — 2005-08-30T22:08:57+00:00 URL: https://externals.io/message/18543#18584 · In reply to: #18570 Rasmus Lerdorf wrote: > -Bug #31142 test #2 (imap_mail_compose() generates incorrect output) > [ext/imap/tests/bug31142_2.phpt] This bug was just fixed. Ilia --- ## #18590 — Wez Furlong — 2005-08-31T03:33:38+00:00 URL: https://externals.io/message/18543#18590 · In reply to: #18570 http://bugs.php.net/search.php?cmd=display&status=Open&bug_type%5B%5D=PDO+related http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name%5B%5D=PDO&package_name%5B%5D=PDO_FIREBIRD&package_name%5B%5D=PDO_MYSQL&package_name%5B%5D=PDO_OCI&package_name%5B%5D=PDO_ODBC&package_name%5B%5D=PDO_PGSQL&package_name%5B%5D=PDO_SQLITE They sound pretty straight-forward (although #33707 and #34233 sound a bit harder), so if you do have some resources to throw at them, I'd really appreciate it--I've just been too damned busy lately, and don't forsee having the time to sit down and get it done for a week or so. --Wez. > Wez Furlong wrote: > > […] > > Do you have some sort of plan/timeline for these getting fixed? Do you > need some help? We can't wait indefinitely on PDO. If you have a list > of outstanding issues I can throw some resources at it. --- ## #18591 — Jani Taskinen — 2005-08-31T07:15:13+00:00 URL: https://externals.io/message/18543#18591 · In reply to: #18579 > > > […] > > According to the last two comments in that bug report, glibc `iconv()` does not > support CP932 and this test should be skipped instead of failing. No idea how > to check for that in the test system, so I'll leave it to Jani or someone > else. That test HAS a check for it but it doesn't work. :) I don't know how you should test if you have the support or not so I leave that to someone else. --Jani --- ## #18592 — Derick Rethans — 2005-08-31T07:15:59+00:00 URL: https://externals.io/message/18543#18592 · In reply to: #18543 > For those of you who submitted patches to 5.1 since RC1 - do you believe that > we need another RC or can we go ahead and roll 5.1 final and run a sanity test > for 24 hours? I went over the patches, none of them appears to be too > dangerous, but if any of you thinks differently, let me know. Should I also commit: http://files.derickrethans.nl/patches/e_recoverable_error-php-5.1-20050826.diff.txt ? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #18608 — Sara Golemon — 2005-08-31T14:44:23+00:00 URL: https://externals.io/message/18543#18608 · In reply to: #18543 > For those of you who submitted patches to 5.1 since RC1 - do you believe > that we need another RC or can we go ahead and roll 5.1 final and run a > sanity test for 24 hours? I went over the patches, none of them appears > to be too dangerous, but if any of you thinks differently, let me know. > Never got a clear response on whether or not that zend_shutdown_constants(TSRMLS_C);/zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC); patch (ZTS leak thread) could be committed. I realized I might've been misleading when I said I'd "temporarily plugged that leak" I meant in my own local checkout, not in CVS. As it's a general bug I'd like to spread it across stable branches 4.4/5.0 and dev branches 5.1/HEAD (with proper timing given RC cycles of course). Index: Zend/zend.c =================================================================== RCS file: /repository/ZendEngine2/zend.c,v retrieving revision 1.308 diff -u -r1.308 zend.c --- Zend/zend.c 3 Aug 2005 13:30:45 -0000 1.308 +++ Zend/zend.c 31 Aug 2005 14:39:28 -0000 @@ -486,6 +486,8 @@ static void executor_globals_dtor(zend_executor_globals *executor_globals TSRMLS_DC) { zend_ini_shutdown(TSRMLS_C); + zend_shutdown_constants(TSRMLS_C); + zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC); } @@ -706,11 +708,9 @@ zend_shutdown_extensions(TSRMLS_C); free(zend_version_info); - zend_shutdown_constants(TSRMLS_C); free(GLOBAL_FUNCTION_TABLE); free(GLOBAL_CLASS_TABLE); #ifdef ZTS - zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC); zend_hash_destroy(GLOBAL_CONSTANTS_TABLE); free(GLOBAL_CONSTANTS_TABLE); GLOBAL_FUNCTION_TABLE = NULL; --- ## #18630 — Rob Richards — 2005-08-31T23:58:25+00:00 URL: https://externals.io/message/18543#18630 · In reply to: #18543 I would suggest bumping up the libxm2 minimum version to 2.6.8. Had forgotten about this until a recent bug, but 2.6.6 and 2.6.7 can cause memory corruption thats fixed in 2.6.8. Rob Zeev Suraski wrote: > For those of you who submitted patches to 5.1 since RC1 - do you > believe that we need another RC or can we go ahead and roll 5.1 final > and run a sanity test for 24 hours? I went over the patches, none of > them appears to be too dangerous, but if any of you thinks > differently, let me know. > > Zeev --- ## #18634 — Andi Gutmans — 2005-09-01T03:14:23+00:00 URL: https://externals.io/message/18543#18634 · In reply to: #18590 Rasmus, please send an update what you think you can do on your side... Thanks, Andi At 08:33 PM 8/30/2005, Wez Furlong wrote: >http://bugs.php.net/search.php?cmd=display&status=Open&bug_type%5B%5D=PDO+related >http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name%5B%5D=PDO&package_name%5B%5D=PDO_FIREBIRD&package_name%5B%5D=PDO_MYSQL&package_name%5B%5D=PDO_OCI&package_name%5B%5D=PDO_ODBC&package_name%5B%5D=PDO_PGSQL&package_name%5B%5D=PDO_SQLITE > >They sound pretty straight-forward (although #33707 and #34233 sound a >bit harder), so if you do have some resources to throw at them, I'd >really appreciate it--I've just been too damned busy lately, and don't >forsee having the time to sit down and get it done for a week or so. > >--Wez. > > > > […] --- ## #18638 — Jani Taskinen — 2005-09-01T08:26:38+00:00 URL: https://externals.io/message/18543#18638 · In reply to: #18630 Done. All distros should have at least 2.6.8. Most have 2.6.16 or above.. --Jani > I would suggest bumping up the libxm2 minimum version to 2.6.8. Had forgotten > about this until a recent bug, but 2.6.6 and 2.6.7 can cause memory corruption > thats fixed in 2.6.8. > > Rob > > Zeev Suraski wrote: > > > […] --- ## #18639 — Derick Rethans — 2005-09-01T08:31:48+00:00 URL: https://externals.io/message/18543#18639 · In reply to: #18592 > > > > […] > > Should I also commit: > http://files.derickrethans.nl/patches/e_recoverable_error-php-5.1-20050826.diff.txt > ? Should I assume that if nobody replies, there are no objections? Derick --- ## #18641 — Jani Taskinen — 2005-09-01T08:38:45+00:00 URL: https://externals.io/message/18543#18641 · In reply to: #18639 > > > > […] > > Should I assume that if nobody replies, there are no objections? I'm replying now and I don't want to see something like this in 5.1. This is new stuff, new stuff goes to HEAD.. --Jani --- ## #18679 — Rob Richards — 2005-09-05T14:48:31+00:00 URL: https://externals.io/message/18543#18679 · In reply to: #18543 Zeev Suraski wrote: > For those of you who submitted patches to 5.1 since RC1 - do you > believe that we need another RC or can we go ahead and roll 5.1 final > and run a sanity test for 24 hours? I went over the patches, none of > them appears to be too dangerous, but if any of you thinks > differently, let me know. Is it possible to add a small feature to the xml stuff prior to 5.1 release as I assume an RC2 is going to go out. http://www.ctindustries.net/patches/xmldiff.txt (made against HEAD) I know its late in the game, but need to be able to perform some Canonicalization on XML, but until I have time to implement it, it has to be done manually but need to be able to support empty tags serialized to include both the start and end tags. Change also removes some libxml version checks no longer needed and a couple of new flags - 2 for canonicalization and 1 for better memory optimization. Rob