PHP 5.1

Michael Wallner

21 years ago

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 >

Andi Gutmans

21 years ago

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

Pierre-Alain Joye

21 years ago

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

Wez Furlong

21 years ago

There's a bunch of open PDO bugs that need to be fixed before we go
with 5.1 final.

--Wez.

On 8/29/05, Zeev Suraski <zeev@zend.com> wrote:

Rasmus Lerdorf

21 years ago

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

Rasmus Lerdorf

21 years ago

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 <root>
002- x_default_handler </root>

-Rasmus

Derick Rethans

21 years ago

On Tue, 30 Aug 2005, Rasmus Lerdorf wrote:

> 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

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

Andrei Zmievski

21 years ago

On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote:

> 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

Marcus Börger

21 years ago

Hello Andrei,

Tuesday, August 30, 2005, 10:16:43 PM, you wrote:

> On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote:
>> 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.

In this case at least the result should be WARN instead of FAIL.

Best regards,
Marcus

Jani Taskinen

21 years ago

On Tue, 30 Aug 2005, Andrei Zmievski wrote:

> On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote:
>> 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.

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

Ilia A.

21 years ago

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

Wez Furlong

21 years ago

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.

On 8/30/05, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Andi Gutmans

21 years ago

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:

Derick Rethans

21 years ago

On Tue, 30 Aug 2005, 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.

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

Derick Rethans

21 years ago

On Wed, 31 Aug 2005, Derick Rethans wrote:

> On Tue, 30 Aug 2005, 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.
>
> 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

Jani Taskinen

21 years ago

On Thu, 1 Sep 2005, Derick Rethans wrote:

> On Wed, 31 Aug 2005, Derick Rethans wrote:
>
>> On Tue, 30 Aug 2005, 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.
>>
>> 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?

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

Zeev Suraski

21 years ago

At 11:31 01/09/2005, Derick Rethans wrote:

>On Wed, 31 Aug 2005, Derick Rethans wrote:
>
> > On Tue, 30 Aug 2005, 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.
> >
> > 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?

No, just that nobody got to reply as of yet :)
I agree with Jani, this shouldn't be in 5.1.

Zeev

Sara Golemon

21 years ago

> 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;

Rob Richards

21 years ago

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:

Jani Taskinen

21 years ago

Done. All distros should have at least 2.6.8. Most have 2.6.16 or above..

--Jani

On Wed, 31 Aug 2005, Rob Richards wrote:

Rob Richards

20 years ago

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