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
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com 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
On Mon, Feb 27, 2012 at 4:31 PM, Laruence larue...@php.net wrote:
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com 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
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
On Mon, Feb 27, 2012 at 4:53 PM, Stas Malyshev smalys...@sugarcrm.com 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
On 02/27/2012 12:37 PM, Laruence wrote:
On Mon, Feb 27, 2012 at 4:31 PM, Laruencelarue...@php.net wrote:
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogovdmi...@zend.com wrote:
Hi Laruence,
The attached patch looks wired. The patch on top of it (r323563) makes it
better. However, in my opinion
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.
On Mon, 27 Feb 2012, Laruence wrote:
On Mon, Feb 27, 2012 at 4:31 PM, Laruence larue...@php.net wrote:
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com wrote:
The attached patch looks wired. The patch on top of it (r323563) makes it
better. However, in my opinion it fixes a
On Mon, Feb 27, 2012 at 11:17 AM, Derick Rethans der...@php.net 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
On Mon, February 27, 2012 2:31 am, Laruence wrote:
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com
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.
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)) {
Sent from my iPad
在 2012-2-28，0:10，Anthony Ferrara ircmax...@gmail.com 写道：
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
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,
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara ircmax...@gmail.com 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
On Tue, Feb 28, 2012 at 10:38 AM, Xinchen Hui larue...@gmail.com wrote:
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara ircmax...@gmail.com 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:
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
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, 15 Feb 2012 10:07:50 +0100, Michael Wallner m...@php.net 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.
On Feb 15, 2012, at 1:07 AM, Michael Wallner m...@php.net 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.
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
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
On Wed, Feb 8, 2012 at 10:57 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On 3 February 2012 12:15, Adam Harvey ahar...@php.net wrote:
On 3 February 2012 12:05, Stas Malyshev smalys...@sugarcrm.com 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
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) == FAILURE) {
On Tue, Feb 7, 2012 at 6:00 PM, Derick Rethans der...@php.net 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
-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:
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
On 8 February 2012 04:09, Stas Malyshev smalys...@sugarcrm.com 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
Hi Derick:
On Sun, Jan 29, 2012 at 1:03 AM, David Soria Parra dso...@gmx.net 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
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
On Tue, Feb 7, 2012 at 1:47 AM, Stas Malyshev smalys...@sugarcrm.com 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
(Resurrecting a very old thread. Sorry about the thread necromancy.)
On 8 September 2011 05:20, Rasmus Lerdorf ras...@lerdorf.com 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
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
On 3 February 2012 12:05, Stas Malyshev smalys...@sugarcrm.com 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
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
-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
Am 27.12.2011 14:53, schrieb Hannes Magnusson:
bjoriTue, 27 Dec 2011 13:53:11 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=321435
Log:
Looks like we need to explicity add libstdc++ on recent linux' too, like
fedora 14 and ubuntu 11
On Tue, Dec 27, 2011 at 16:48, Sebastian Bergmann sebast...@php.net 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
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=revisionrevision=321406
ZTS build is broken (snapshot 201112261030)
Please see trivial attached patch
Regards,
Remi.
diff -up
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
... snip ...
zlib
[Zend Modules]
Program
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 r...@fedoraproject.org
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 -
2011/9/19 Johannes Schlüter johan...@schlueters.de:
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
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
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
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 tyr...@php.net wrote:
tyrael Thu, 22 Sep 2011 20:59:10 +
Revision:
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 tyr...@php.net wrote:
Derick, could you look into this?
I think that the easter_days should take the date.timezone account
when calculating a
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 have to
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 reasonable,
2011/9/15 Hannes Magnusson hannes.magnus...@gmail.com:
On Wed, Sep 14, 2011 at 12:36, Alexey Shein con...@gmail.com wrote:
2011/9/14 Ferenc Kovacs tyr...@gmail.com:
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]
On Wed, Sep 14, 2011 at 12:36, Alexey Shein con...@gmail.com wrote:
2011/9/14 Ferenc Kovacs tyr...@gmail.com:
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] bjori Tyrael: tmp-php.ini is built from the system ini
On Thu, Sep 15, 2011 at 12:07 PM, Hannes Magnusson
hannes.magnus...@gmail.com 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
Hi,
FYI, you might should delete the autom4te.cache folder too :-)
thanks
2011/9/14 Christian Stocker chr...@php.net:
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
./vcsclean ./buildconf --force
On Wed, Sep 14, 2011 at 8:07 AM, Laruence larue...@php.net wrote:
Hi,
FYI, you might should delete the autom4te.cache folder too :-)
thanks
2011/9/14 Christian Stocker chr...@php.net:
Hi
I still have this. even after re-running buildconf (and deleting
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
christian.stoc...@liip.ch wrote:
On 14.09.11 09:00, Ferenc Kovacs wrote:
./vcsclean ./buildconf --force
ok, that helped. Thanks
2011/9/13 Ferenc Kovacs tyr...@gmail.com:
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev smalys...@sugarcrm.com 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
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] bjori Tyrael: tmp-php.ini is built from the system ini
[20:44:45] bjori Tyrael: if he builds php with
--with-config-file-scan-dir=/where/ever/he/has/another/php.ini, then
2011/9/14 Ferenc Kovacs tyr...@gmail.com:
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] bjori Tyrael: tmp-php.ini is built from the system ini
[20:44:45] bjori Tyrael: if he builds php with
On 13 September 2011 17:27, Pierre Joye pierre@gmail.com wrote:
hi,
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
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
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
hi,
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev smalys...@sugarcrm.com 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
On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev smalys...@sugarcrm.com 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,
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,
On Tue, Sep 13, 2011 at 8:23 PM, Stas Malyshev smalys...@sugarcrm.com 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
On Tue, Sep 13, 2011 at 8:23 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
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 larue...@php.net:
Hi:
trunk
Hello, these tests fail for me too, ubuntu 11.04 x86, both trunk and
5.4 branches.
2011/9/12 Ferenc Kovacs tyr...@gmail.com:
On Sun, Sep 11, 2011 at 11:04 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
On 9/11/11 8:44 AM, Ferenc Kovacs wrote:
AFAIK you shoud get it(as I did on my
I forget to reply-all to the list :/
On Mon, Sep 12, 2011 at 7:46 PM, Stas Malyshev smalys...@sugarcrm.com 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
On Sat, Sep 10, 2011 at 8:46 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
On Sun, Sep 11, 2011 at 11:04 PM, Stas Malyshev smalys...@sugarcrm.com 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:
On Wed, Sep 7, 2011 at 14:33, Pierre Joye paj...@php.net wrote:
pajoye Wed, 07 Sep 2011 12:33:22 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=316345
Log:
- reject paths with trainling spaces using the very good new zend arg
Changed
Em Wed, 07 Sep 2011 13:41:45 +0100, Hannes Magnusson
hannes.magnus...@gmail.com escreveu:
On Wed, Sep 7, 2011 at 14:33, Pierre Joye paj...@php.net wrote:
pajoye Wed, 07 Sep 2011 12:33:22 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=316345
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 to the
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
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
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 since
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: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: process timed out
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: process timed out
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
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 should have
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,
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 case:
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
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.
On Wed, Sep 7, 2011 at 11:20 PM, Rasmus Lerdorf ras...@lerdorf.com 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
On 09/06/2011 10:45 AM, Stas Malyshev wrote:
Hi!
On 9/6/11 1:24 AM, Andrey Hristov wrote:
no, it's about consistency, which you want. mysqlnd should behave like
libmysql, and it is a test that can test it. What libmysql returns in
filtered in mysqli, mysqli_num_rows() is a direct wrapper
Hi!
Have you actually checked what libmysql returns??!?
If _you_ just have tried to do it, you might actually find that
libmysql does what mysqlnd did long ago, but mysqli was hiding it.
Here is output from what libmysql does, after removing the following
check from mysqli_api.c:
I checked
On 09/06/2011 11:16 AM, Stas Malyshev wrote:
Hi!
Have you actually checked what libmysql returns??!?
If _you_ just have tried to do it, you might actually find that
libmysql does what mysqlnd did long ago, but mysqli was hiding it.
Here is output from what libmysql does, after removing the
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
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)-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-data
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 ==
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-status
On Sun, Sep 4, 2011 at 22:38, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
On 9/4/11 1:35 PM, Kalle Sommer Nielsen wrote:
But if its possible to always be available in ZTS, what would the
reasoning for it not to be available in NTS? I haven't dug into the
code that deeply so I'm just
Hi,
aside from the actual question: run-tests.php already makes heavy usage
of realpath, so it's impossible to run the tests on a system without
realpath.
$ grep realpath run-tests.php | wc -l
14
johannes
On Sun, 2011-09-04 at 16:41 +0200, Ferenc Kovacs wrote:
Sorry, for the late reply, I
1 - 100 of 284 matches
Mail list logo
