On Tue, Feb 28, 2012 at 10:38 AM, Xinchen Hui wrote:
> On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
>> I initially looked at the final fix when I discovered the issue.
>> Follow me out on this. This is the current code as-implemented in
>> r323563:
>>
>> 265 zval *o
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
> I initially looked at the final fix when I discovered the issue.
> Follow me out on this. This is the current code as-implemented in
> r323563:
>
> 265 zval *obj;
> 266 MAKE_STD_ZVAL(obj);
> 267
I initially looked at the final fix when I discovered the issue.
Follow me out on this. This is the current code as-implemented in
r323563:
265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
Sent from my iPad
在 2012-2-28，0:10，Anthony Ferrara 写道：
> Out of curiosity, why are you changing it to copy the object for the
> result of the cast operation? cast_object should init the result
> zval, so why go through the step of copying the starting object to
plz look at the final fix： r32356
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
On Mon, February 27, 2012 2:31 am, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
> wrote:
>> Hi Laruence,
>>
>> The attached patch looks wired. The patch on top of it (r323563)
>> makes it
>> better. However, in my opinion it fixes a common problem just in a
>> single
>> place.
On Mon, Feb 27, 2012 at 11:17 AM, Derick Rethans wrote:
> You can't break extension APIs between 5.4.0 and 5.4.1 either, API
> changes can only into trunk.
And ABI neither.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mai
On Mon, 27 Feb 2012, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:31 PM, Laruence wrote:
> > On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov wrote:
> >>
> >> The attached patch looks wired. The patch on top of it (r323563) makes it
> >> better. However, in my opinion it fixes a common problem just
On 02/27/2012 12:53 PM, Stas Malyshev wrote:
Hi!
so I think, maybe it's okey for a temporary fix :)
what I mean temporary is, apply this fix to 5.3 and 5.4
Don't apply anything to 5.4 now, please.
No, we are thinking about the trunk, and "temporary" fix for 5.4 is
delayed.
Thanks. Dmitr
On 02/27/2012 12:37 PM, Laruence wrote:
On Mon, Feb 27, 2012 at 4:31 PM, Laruence wrote:
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov wrote:
Hi Laruence,
The attached patch looks wired. The patch on top of it (r323563) makes it
better. However, in my opinion it fixes a common problem just
On Mon, Feb 27, 2012 at 4:53 PM, Stas Malyshev wrote:
> Hi!
>
>
>>> so I think, maybe it's okey for a temporary fix :)
>>
>> what I mean temporary is, apply this fix to 5.3 and 5.4
>
>
> Don't apply anything to 5.4 now, please.
Sure, won't do it without your permission. :)
thanks
>
> --
> Stan
Hi!
so I think, maybe it's okey for a temporary fix :)
what I mean temporary is, apply this fix to 5.3 and 5.4
Don't apply anything to 5.4 now, please.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Deve
On Mon, Feb 27, 2012 at 4:31 PM, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov wrote:
>> Hi Laruence,
>>
>> The attached patch looks wired. The patch on top of it (r323563) makes it
>> better. However, in my opinion it fixes a common problem just in a single
>> place. Each call
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov wrote:
> Hi Laruence,
>
> The attached patch looks wired. The patch on top of it (r323563) makes it
> better. However, in my opinion it fixes a common problem just in a single
> place. Each call to __toString() that makes "side effects" may cause the
Hi Laruence,
The attached patch looks wired. The patch on top of it (r323563) makes
it better. However, in my opinion it fixes a common problem just in a
single place. Each call to __toString() that makes "side effects" may
cause the similar problem. It would be great to make a "right" fix in
Dmitry:
you might want to review this fix.
let me explain why crash before this fix.
when doing parse_parameter, then convert the object to string by
calling the ce->cast_object,
and passed the same pointer(although there was a separation), to
the cast_object..
then if __toStrin
On Wed, 2012-02-15 at 07:09 -0800, Christopher Jones wrote:
> Of course it warrants a NEWS entry. Unless no one in the world was
> using it (in which case why have any code there?), a news entry will
> help explain a behavior difference, or identify when something broke
> (if you just accidentally
On Feb 15, 2012, at 1:07 AM, Michael Wallner wrote:
> On Tue, 14 Feb 2012 12:50:40 -0800, Christopher Jones wrote:
>
>> It would be great to have a NEWS entry and a testcase and a bug number.
>>
>
> Definitely.
>
> Seriously, there's no code in core using it, so there's no test case.
> ...a
On Wed, 15 Feb 2012 10:07:50 +0100, Michael Wallner wrote:
On Tue, 14 Feb 2012 12:50:40 -0800, Christopher Jones wrote:
It would be great to have a NEWS entry and a testcase and a bug number.
Definitely.
Seriously, there's no code in core using it, so there's no test case.
...and it's bee
On Tue, 14 Feb 2012 12:50:40 -0800, Christopher Jones wrote:
> It would be great to have a NEWS entry and a testcase and a bug number.
>
Definitely.
Seriously, there's no code in core using it, so there's no test case.
...and it's been reported on internals@ not bugs.php.net, so there's no
bug
On Wed, Feb 8, 2012 at 10:57 AM, Stas Malyshev wrote:
> Hi!
>
>
> We're in violent agreement. I don't think it's the right approach at
>> all — the right fix is to either fall back on ITIMER_REAL or come up
>> with some other approach on OS X — but I'm trying to come up with a
>> stopgap for 5.4.
Hi!
We're in violent agreement. I don't think it's the right approach at
all — the right fix is to either fall back on ITIMER_REAL or come up
with some other approach on OS X — but I'm trying to come up with a
stopgap for 5.4.0 to make sure the test is XFAILed where we already
know it fails as p
On 8 February 2012 04:09, Stas Malyshev wrote:
>> Specifically, how about the attached patch (also available at
>> http://www.adamharvey.name/patches/osx-max_execution_time-test-patch.diff,
>> in case the mailing list decides to strip it)? This only patches the
>> test to XFAIL this test on OS X,
Hi!
Specifically, how about the attached patch (also available at
http://www.adamharvey.name/patches/osx-max_execution_time-test-patch.diff,
in case the mailing list decides to strip it)? This only patches the
test to XFAIL this test on OS X, which makes the PHP_5_4 test suite
run without any un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> This following patch looks good to me:
> Derick, thanks ,
>
> Stas, should I commit this into 5.4 now or hold from ci until the
> release of 5.4?
Please wait for stas okay, but personally I want to see this committed.
>
> thanks
>>
>>> Index:
On Tue, Feb 7, 2012 at 6:00 PM, Derick Rethans wrote:
> On Mon, 6 Feb 2012, Laruence wrote:
>
>> there comes a new bug relate to this change, #60978, in php_cli.c
>>
>> case PHP_MODE_CLI_DIRECT:
>> cli_register_file_handles(TSRMLS_C);
>> if (zend_eval_string_ex(ex
On Mon, 6 Feb 2012, Laruence wrote:
> there comes a new bug relate to this change, #60978, in php_cli.c
>
>case PHP_MODE_CLI_DIRECT:
> cli_register_file_handles(TSRMLS_C);
> if (zend_eval_string_ex(exec_direct, NULL, "Command line
> code", 1 TSRMLS_CC) == FAILUR
On 3 February 2012 12:15, Adam Harvey wrote:
> On 3 February 2012 12:05, Stas Malyshev wrote:
>>> For me at least, tests/func/005a.phpt is the last failing test on
>>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>>> pre-5.4.0 to help get cleaner test suite results.
>>
>
On Tue, Feb 7, 2012 at 1:47 AM, Stas Malyshev wrote:
> Hi!
>
>
>> there comes a new bug relate to this change, #60978, in php_cli.c
>
>
> I'm not sure this bug is critical enough to keep messing with the code base
> this close to the release. Could you please describe what is the current
> stat
Hi!
there comes a new bug relate to this change, #60978, in php_cli.c
I'm not sure this bug is critical enough to keep messing with the code
base this close to the release. Could you please describe what is the
current status, what was before the fix and what exactly the problems
are her
Hi Derick:
On Sun, Jan 29, 2012 at 1:03 AM, David Soria Parra wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thank you for catching that. Please go ahead and commit!.
>
> Thanks
>
> On 01/28/2012 04:00 PM, Derick Rethans wrote:
>> Hi David,
>>
>> When I was just checking PHP 5.4 com
On 3 February 2012 12:05, Stas Malyshev wrote:
>> For me at least, tests/func/005a.phpt is the last failing test on
>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>> pre-5.4.0 to help get cleaner test suite results.
>
>
> I really wouldn't want to hold the release for an
Hi!
I've been trying to run down tests/func/005a.phpt failing this
morning, and obviously this is the cause. I don't have a Lion machine
to hand to test this there, but it does look like ITIMER_PROF is
completely broken on OS X 10.6.7 and 10.6.8.
Yes, this test is broken and looks like somethi
(Resurrecting a very old thread. Sorry about the thread necromancy.)
On 8 September 2011 05:20, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you for catching that. Please go ahead and commit!.
Thanks
On 01/28/2012 04:00 PM, Derick Rethans wrote:
> Hi David,
>
> When I was just checking PHP 5.4 compatibility with Xdebug I ran
> into the case where zend_eval_string() no longer would
Hi David,
When I was just checking PHP 5.4 compatibility with Xdebug I ran into
the case where zend_eval_string() no longer would bail out when you'd
evalulate something that doesn't work (like a standalone
"$this->property;" without being in a class scope).
Xdebug has code (simplified) like t
On Tue, Dec 27, 2011 at 16:48, Sebastian Bergmann wrote:
> Am 27.12.2011 16:36, schrieb Sebastian Bergmann:
>> And PHP_5_3 does not need this?
>
> I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16.
Hmh. Do they not ship with PHP5.3?
I would have expect them to submit a build
Am 27.12.2011 16:36, schrieb Sebastian Bergmann:
> And PHP_5_3 does not need this?
I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://t
Am 27.12.2011 14:53, schrieb Hannes Magnusson:
> bjoriTue, 27 Dec 2011 13:53:11 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=321435
>
> Log:
> Looks like we need to explicity add libstdc++ on recent linux' too, like
> fedora 14 and ubun
Le 26/12/2011 14:09, Pierre Joye a écrit :
> Attached patch should fix this problem but I'm not sure if we have to
> do it in RINIT instead. The handler is set to NULL on dtor, so it
> could be enough already to do it once in MINIT.
At least, it fix the build/run issue.
Thanks.
--
PHP Internals -
hi Remi!
Thanks for the headup!
Attached patch should fix this problem but I'm not sure if we have to
do it in RINIT instead. The handler is set to NULL on dtor, so it
could be enough already to do it once in MINIT.
Cheers,
On Mon, Dec 26, 2011 at 1:52 PM, Remi Collet wrote:
> With 321411 appl
With 321411 applied
(gdb) run -n -m
Starting program: /dev/shm/php5.4-201112261030/build-zts/sapi/cli/php -n -m
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[PHP Modules]
bz2
calendar
Core
... ...
zlib
[Zend Modules]
Program received
Le 26/12/2011 09:29, Stanislav Malyshev a écrit :
> stas Mon, 26 Dec 2011 08:29:11 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=321406
ZTS build is broken (snapshot 201112261030)
Please see trivial attached patch
Regards,
Remi.
diff -
On Wed, 7 Dec 2011, Pierre Joye wrote:
> pajoye Wed, 07 Dec 2011 09:03:07 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=320564
>
> Log: - print_r seems to display 0 or nothing for days, let make that
> test works in both cases, that's not
seems to be due to partially generated global table, clean build and I
cannot reproduce the crash anymore. Sorry for the noise :)
On Wed, Dec 7, 2011 at 12:20 PM, Pierre Joye wrote:
> this patch is not correct, php crashes on startup when a request is
> initialized.
--
Pierre
@pierrejoye | h
this patch is not correct, php crashes on startup when a request is initialized.
==7872==at 0x816204B: php_auto_globals_create_request (php_variables.c:804)
==7872==by 0x818E564: zend_auto_global_init (zend_compile.c:6694)
==7872==by 0x81BB0CE: zend_hash_apply (zend_hash.c:716)
==7872=
2011/9/19 Johannes Schlüter :
> On Mon, 2011-09-19 at 12:25 +0200, Ferenc Kovacs wrote:
>> >
>> > Good point, are you proposing to change code and make libmysql 5.0+ a
>> > requirement? If so, several changes should be made to ext/mysql, ext/mysqli
>> > and PDO_MySQL.
>> >
>>
>> I think that it is
I've just noticed that we had a related bugreport, I thought that I
should mention it:
https://bugs.php.net/bug.php?id=55479
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ext/intl/tests/dateformat_parse.phpt
seems also affected by this:
http://news.php.net/php.cvs/66617
On Thu, Sep 22, 2011 at 11:06 PM, Ferenc Kovacs wrote:
> Derick, could you look into this?
> I think that the easter_days should take the date.timezone account
> when calculating a timestamp
>
> On
Derick, could you look into this?
I think that the easter_days should take the date.timezone account
when calculating a timestamp
On Thu, Sep 22, 2011 at 10:59 PM, Ferenc Kovacs wrote:
> tyrael Thu, 22 Sep 2011 20:59:10 +
>
> Revision: http://svn.php.net/view
I just stumbled upon on this test as it timed out for me(my test vm
started swapping, so run-tests.php terminated after 60 sec).
I think it would be good if we could somehow check the available ram,
and skipif if it isn't enough, and I think we could also save off an
str_repeat call:
each str_repea
On Mon, 2011-09-19 at 12:25 +0200, Ferenc Kovacs wrote:
> >
> > Good point, are you proposing to change code and make libmysql 5.0+ a
> > requirement? If so, several changes should be made to ext/mysql, ext/mysqli
> > and PDO_MySQL.
> >
>
> I think that it is your call, but yes, I think it would r
>
> Good point, are you proposing to change code and make libmysql 5.0+ a
> requirement? If so, several changes should be made to ext/mysql, ext/mysqli
> and PDO_MySQL.
>
I think that it is your call, but yes, I think it would reasonable,
and it would make our/your work much easier if we would hav
2011/9/15 Hannes Magnusson :
> On Wed, Sep 14, 2011 at 12:36, Alexey Shein wrote:
>> 2011/9/14 Ferenc Kovacs :
Why do we even have this tmp-php.ini? Why not just make test without
any .ini files, i.e. just with -n option?
>>>
>>> [20:44:09] Tyrael: tmp-php.ini is built from the sys
On Thu, Sep 15, 2011 at 12:07 PM, Hannes Magnusson
wrote:
> Running tests exclusively in an environment known to work doesn't help us.
It indeed does, and much more than random failures in random environments.
However it is not about one or the other, it is about both and about
having as much t
On Wed, Sep 14, 2011 at 12:36, Alexey Shein wrote:
> 2011/9/14 Ferenc Kovacs :
>>>
>>> Why do we even have this tmp-php.ini? Why not just make test without
>>> any .ini files, i.e. just with -n option?
>>
>> [20:44:09] Tyrael: tmp-php.ini is built from the system ini
>> [20:44:45] Tyrael: if he
On 13 September 2011 17:27, Pierre Joye wrote:
> hi,
>
> On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
>> Hi!
>>
>> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>>
>>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>>> The make test should create tmp-php.ini for y
2011/9/14 Ferenc Kovacs :
>>
>> Why do we even have this tmp-php.ini? Why not just make test without
>> any .ini files, i.e. just with -n option?
>
> [20:44:09] Tyrael: tmp-php.ini is built from the system ini
> [20:44:45] Tyrael: if he builds php with
> --with-config-file-scan-dir=/where/ever/he
>
> Why do we even have this tmp-php.ini? Why not just make test without
> any .ini files, i.e. just with -n option?
[20:44:09] Tyrael: tmp-php.ini is built from the system ini
[20:44:45] Tyrael: if he builds php with
--with-config-file-scan-dir=/where/ever/he/has/another/php.ini, then
it will u
2011/9/13 Ferenc Kovacs :
> On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
>> Hi!
>>
>> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>>
>>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>>> The make test should create tmp-php.ini for you (and copy your
>>
>> Everyb
no problem, I just mentioned because it is easier to remember, and it
should take care of the similar problems.
On Wed, Sep 14, 2011 at 9:08 AM, Christian Stocker
wrote:
>
>
> On 14.09.11 09:00, Ferenc Kovacs wrote:
>> ./vcsclean && ./buildconf --force
>
> ok, that helped. Thanks a lot and I shou
On 14.09.11 09:00, Ferenc Kovacs wrote:
> ./vcsclean && ./buildconf --force
ok, that helped. Thanks a lot and I should have known that
chregu
>
> On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote:
>> Hi,
>> FYI, you might should delete the autom4te.cache folder too :-)
>>
>> thanks
>>
>> 2011
./vcsclean && ./buildconf --force
On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote:
> Hi,
> FYI, you might should delete the autom4te.cache folder too :-)
>
> thanks
>
> 2011/9/14 Christian Stocker :
>> Hi
>>
>> I still have this. even after re-running buildconf (and deleting
>> configure before)
Hi,
FYI, you might should delete the autom4te.cache folder too :-)
thanks
2011/9/14 Christian Stocker :
> Hi
>
> I still have this. even after re-running buildconf (and deleting
> configure before)
>
> On OS X and x86_64 Linux
>
> chregu
>
> On 14.09.11 05:31, Laruence wrote:
>> Hi:
>> after
Hi
I still have this. even after re-running buildconf (and deleting
configure before)
On OS X and x86_64 Linux
chregu
On 14.09.11 05:31, Laruence wrote:
> Hi:
> after I re-run buildconf, error has gone
>
> sorry for mis-report.
>
> thanks
>
> 2011/9/14 Laruence :
>> Hi:
>>trunk build
Hi!
On 9/13/11 1:11 PM, Ferenc Kovacs wrote:
Stas, I commited my patch again with the addition --INI-- setting:
http://news.php.net/php.cvs/66511
could you test it?
Passes for me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Intern
On Tue, Sep 13, 2011 at 8:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 11:04 AM, Ferenc Kovacs wrote:
>>
>> as I mentioned before, make test (at least it should) passes the -n -c
>> argument to run-tests.php
>> see
>> http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104
On Tue, Sep 13, 2011 at 8:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 11:04 AM, Ferenc Kovacs wrote:
>>
>> as I mentioned before, make test (at least it should) passes the -n -c
>> argument to run-tests.php
>> see
>> http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104
Hi!
On 9/13/11 11:04 AM, Ferenc Kovacs wrote:
as I mentioned before, make test (at least it should) passes the -n -c
argument to run-tests.php
see http://svn.php.net/viewvc/php/php-src/trunk/Makefile.global?view=markup#l104
which means if you run make test that can produce different result,
than
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>
>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>> The make test should create tmp-php.ini for you (and copy your
>
> Everybody has custom php.ini, what do you
hi,
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
>>
>> Stas, I still don't know why do have a custom php.ini, and why is it used.
>> The make test should create tmp-php.ini for you (and copy your
>
> Everybody has custom php.ini, what do
Hi!
On 9/13/11 7:49 AM, Ferenc Kovacs wrote:
Stas, I still don't know why do have a custom php.ini, and why is it used.
The make test should create tmp-php.ini for you (and copy your
Everybody has custom php.ini, what do you mean "why"? Nobody uses just
defaults. It is used because -n -c is n
After a discussion on irc, I was thinking about something similar:
adding my patch back, but adding -error-log to the --INI--
Stas, I still don't know why do have a custom php.ini, and why is it used.
The make test should create tmp-php.ini for you (and copy your
additional ini files there if you p
Just wanted to say, that I managed to reproduce your results for
./PHP_5_4/ext/session/tests/rfc1867_invalid_settings.phpt by adding
date.timezone=UTC
error_log=file
settings into --INI-- section, this way test passes. I.e. logged
message should go into the file and do not mess the output which is
I forget to reply-all to the list :/
On Mon, Sep 12, 2011 at 7:46 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/12/11 3:14 AM, Ferenc Kovacs wrote:
>>
>> you should pass both -n and -c as the make test pass those to the
>> run-tests.php AFAIK, see:
>
> That's not what I see happening.
>
>> as I mention
Hello, these tests fail for me too, ubuntu 11.04 x86, both trunk and
5.4 branches.
2011/9/12 Ferenc Kovacs :
> On Sun, Sep 11, 2011 at 11:04 PM, Stas Malyshev
> wrote:
>> Hi!
>>
>> On 9/11/11 8:44 AM, Ferenc Kovacs wrote:
>>>
>>> AFAIK you shoud get it(as I did on my debian machines), as both
>>
On Sun, Sep 11, 2011 at 11:04 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/11/11 8:44 AM, Ferenc Kovacs wrote:
>>
>> AFAIK you shoud get it(as I did on my debian machines), as both
>> display_startup_errors and error_reporting is force enabled for the
>> tests:
>> http://svn.php.net/viewvc/php/php-src/
Hi!
On 9/11/11 8:44 AM, Ferenc Kovacs wrote:
AFAIK you shoud get it(as I did on my debian machines), as both
display_startup_errors and error_reporting is force enabled for the
tests:
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l232
http://svn.php.net/viewvc/php/php-src
On Sat, Sep 10, 2011 at 8:46 PM, Stas Malyshev wrote:
> Hi!
>>
>> care to comment?
>
> It looks like neither me nor others (inluding gcov machine) are getting that
> message.
>
AFAIK you shoud get it(as I did on my debian machines), as both
display_startup_errors and error_reporting is force enab
On Wed, Sep 7, 2011 at 11:20 PM, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8.
>> Didn't try it on Lion, maybe the have updated/
On 09/07/2011 02:12 PM, Stas Malyshev wrote:
> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8.
> Didn't try it on Lion, maybe the have updated/fixed it.
Right, so we need to decide what to do about that.
Hi!
On 9/7/11 2:01 PM, Rasmus Lerdorf wrote:
I am curious, what do you see when you strace it?
On Linux you get:
Darwin has no strace. dtruss is not very helpful:
83310/0x43ee45: 32798 11 7 munmap(0x208B000, 0x11E)
= 0 0
83310/0x43ee45: 32805 9 6 close_n
On 09/07/2011 01:32 PM, Stas Malyshev wrote:
> Hi
>
> On 9/7/11 1:17 PM, Rasmus Lerdorf wrote:
>>
>> Interesting that this is different on Darwin. That doesn't seem like
>> something that should be OS-specific unless Darwin's itimer
>> implementation is messed up.
>
> Looks like it might be the c
Hi
On 9/7/11 1:17 PM, Rasmus Lerdorf wrote:
Interesting that this is different on Darwin. That doesn't seem like
something that should be OS-specific unless Darwin's itimer
implementation is messed up.
Looks like it might be the case:
http://openradar.appspot.com/9336975
REAL timer works, o
On 09/07/2011 01:04 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:43 PM, Rasmus Lerdorf wrote:
>> Actually, it seems to be more than that. That set_time_limit() just
>> speeds up the test. Since we have a default max_execution_time you
>> should still have hit that and the shutdown function shou
Hi!
On 9/7/11 12:43 PM, Rasmus Lerdorf wrote:
Actually, it seems to be more than that. That set_time_limit() just
speeds up the test. Since we have a default max_execution_time you
should still have hit that and the shutdown function should have been
called. But your other max_execution_time-rel
On 09/07/2011 12:28 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
>>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
>>> fails. It's on Darwin.
>>
>> That one doesn't fail for me. What's your diff?
>
> 002+
> 002- Shutdown
> 003+ ** ERROR: pro
On 09/07/2011 12:28 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
>>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
>>> fails. It's on Darwin.
>>
>> That one doesn't fail for me. What's your diff?
>
> 002+
> 002- Shutdown
> 003+ ** ERROR: pro
Hi!
On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
fails. It's on Darwin.
That one doesn't fail for me. What's your diff?
002+
002- Shutdown
003+ ** ERROR: process timed out **
It looks like set_time_limit(1) doesn't work.
--
On 09/07/2011 12:16 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 11:54 AM, Rasmus Lerdorf wrote:
>> Please help me figure out if this fix causes any weird side-effects
>> anywhere. Essentially the problem is that the new deferred signals
>> patch ignores signals when running signal handlers. But s
Hi!
On 9/7/11 11:54 AM, Rasmus Lerdorf wrote:
Please help me figure out if this fix causes any weird side-effects
anywhere. Essentially the problem is that the new deferred signals
patch ignores signals when running signal handlers. But since
register shutdown functions are called by the signal
Please help me figure out if this fix causes any weird side-effects
anywhere. Essentially the problem is that the new deferred signals
patch ignores signals when running signal handlers. But since
register shutdown functions are called by the signal handler they
won't time out anymore. By pretendin
hi,
the main problem is that the (stupid) windows filesystem APIs consider
" foo", "foo " as being the same than "foo". It has caused all kind of
bad effects and we added checks in some areas already in 5.3.
Now that 5.4 has a "p" parameter we can simply cleanup the given paths
before passing it
Em Wed, 07 Sep 2011 13:41:45 +0100, Hannes Magnusson
escreveu:
On Wed, Sep 7, 2011 at 14:33, Pierre Joye wrote:
pajoye Wed, 07 Sep 2011 12:33:22 +
Revision: http://svn.php.net/viewvc?view=revision&revision=316345
Log:
- reject paths with trainling spa
On Wed, Sep 7, 2011 at 14:33, Pierre Joye wrote:
> pajoye Wed, 07 Sep 2011 12:33:22 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=316345
>
> Log:
> - reject paths with trainling spaces using the very good new zend arg
>
> Changed paths:
>
On 09/06/2011 09:54 PM, Andrey Hristov wrote:
On 09/06/2011 09:08 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 11:05 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it
looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->stat
On 09/06/2011 09:08 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 11:05 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it
looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->data ==
Hi!
On 9/6/11 11:05 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->data == NULL))
When I step through your code, r->dat
Stas,
On 09/06/2011 06:55 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 2:46 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->da
Hi!
On 9/6/11 2:46 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)->handle&& (r)->handle->status == MYSQL_STATUS_USE_RESULT) ||
((r)->data == NULL))
When I step through your code, r->data
1 - 100 of 294 matches
Mail list logo
