-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11/10/2014 07:37, Remi Collet a écrit :
> I will try to create a patch, for test, as we really need to fix
> this problem, especially it gmp going to go into core (bigint
> patch).
See
https://bugs.php.net/patch-display.php?bug=63595&patch=gmp-mem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11/10/2014 02:24, Rasmus Lerdorf a écrit :
> On 10/10/2014 09:50 AM, Stas Malyshev wrote:
>> Hi!
>>
>>> Can you please elaborate a little ? Doesn't such leak have to
>>> be fixed in ext/gmp ?
>>
>> We clean up the memory at the end of the request.
On 11 October 2014 01:24, Leigh wrote:
> > BC compatibility is easily achieved as variadics (
> > https://wiki.php.net/rfc/variadics) allow for writing cleaner and less
> > complex versions:
> >
>
> True.
>
> So can we make these functions behave as if variadics were used
> without removing them?
On 10 Oct 2014, at 13:08, Remi Collet wrote:
> Le 10/10/2014 12:57, Andrea Faulds a écrit :
>>
>>
>> Can't we just make gnutls use its own (statically-linked?) gmp
>> instance?
>
> Not an option.
> As gnutls change will imply downtream change,
> and downstream doesn't allowed bundled library.
On 10/10/2014 09:50 AM, Stas Malyshev wrote:
> Hi!
>
>> Can you please elaborate a little ?
>> Doesn't such leak have to be fixed in ext/gmp ?
>
> We clean up the memory at the end of the request. But if the request
> ended abnormally and we had some active gmp objects, with gmp data
> allocated
On 11 Oct 2014, at 00:40, Lester Caine wrote:
>> What you want is 64-bit data handling. This is arbitrary-bit data handling.
>> It’s not a “wrong approach”.
>
> So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit
> platforms? BIGINT is a fix length number not a variable one …
On 11/10/14 00:28, Andrea Faulds wrote:
>
> On 10 Oct 2014, at 23:20, Lester Caine wrote:
>
>> Is this the right approach to implement BIGINT?
>> I don't see the use of GMP to implement something as simple as native 64
>> bit numbers on 64 bit platforms as the right base.
>
> Um, we already hav
On 10 Oct 2014, at 23:20, Lester Caine wrote:
> Is this the right approach to implement BIGINT?
> I don't see the use of GMP to implement something as simple as native 64
> bit numbers on 64 bit platforms as the right base.
Um, we already have this since the 64-bit patch.
> All we are missing
On 10 October 2014 21:27, Marco Pivetta wrote:
> Hello folks,
>
> While rambling with some code today, I realized that `call_user_func`
> behaves strangely, appearing and disappearing from stack traces depending
> on versions of PHP. For an example, compare
> http://3v4l.org/fGpIk#vphp7@20140901,
On Fri, 2014-10-10 at 22:53 +0200, Marco Pivetta wrote:
> Assuming PHP 7.0 came out in 2 years from now, I don't expect a decent
> adoption rate anyway for the next 5 years.
So you want to decrease adoption rate even more for a very small win?
Fantastic (irony!)
johannes
--
PHP Internals - PH
On 10/10/14 22:33, Andrea Faulds wrote:
> Since I don’t want this to languish as a ‘Draft’ forever, despite the patch
> being incomplete, I am finally putting the Big Integer Support RFC “Under
> Discussion”.
>
> The RFC can be found here: https://wiki.php.net/rfc/bigint
>
> The patch is, as I
Good evening,
Since I don’t want this to languish as a ‘Draft’ forever, despite the patch
being incomplete, I am finally putting the Big Integer Support RFC “Under
Discussion”.
The RFC can be found here: https://wiki.php.net/rfc/bigint
The patch is, as I mentioned, incomplete. Additionally, th
On 10 Oct 2014, at 17:50, Stas Malyshev wrote:
> Hi!
>
>> Can you please elaborate a little ?
>> Doesn't such leak have to be fixed in ext/gmp ?
>
> We clean up the memory at the end of the request. But if the request
> ended abnormally and we had some active gmp objects, with gmp data
> alloc
On 10 October 2014 22:46, Andrea Faulds wrote:
> PHP 5.6 has been out for *less than two months*. Let’s say PHP 7 comes out
> in 18 months’ time, so June 2016. Even then, PHP 5.6 would have been around
> for less than 20 months. It is incredibly unreasonable to suggest that
> application develope
On 10 Oct 2014, at 21:43, Marco Pivetta wrote:
> On 10 October 2014 22:39, Kris Craig wrote:
> The call_user_func() and call_user_func_array() functions are used all over
> the place. I see absolutely no gain, whatsoever in removing them and forcing
> developers to write their own userland v
On 10 October 2014 22:39, Kris Craig wrote:
> The call_user_func() and call_user_func_array() functions are used all
> over the place. I see absolutely no gain, whatsoever in removing them and
> forcing developers to write their own userland variants instead.
>
> --Kris
>
>
Of course they are, b
On 10 Oct 2014, at 13:31, Patrick Schaaf wrote:
> I would love to be able to catch, at toplevel. with an error handler or
> otherwise, both the memory limits exceeded and time limit exceeded cases.
>
> These two safeguards, by themselves, are not instabilities, right? The
> limits could be set
On 10 October 2014 22:34, Andrea Faulds wrote:
>
> On 10 Oct 2014, at 21:27, Marco Pivetta wrote:
>
> > While rambling with some code today, I realized that `call_user_func`
> > behaves strangely, appearing and disappearing from stack traces depending
> > on versions of PHP. For an example, comp
On Fri, Oct 10, 2014 at 1:34 PM, Andrea Faulds wrote:
>
> On 10 Oct 2014, at 21:27, Marco Pivetta wrote:
>
> > While rambling with some code today, I realized that `call_user_func`
> > behaves strangely, appearing and disappearing from stack traces depending
> > on versions of PHP. For an exampl
On 10 Oct 2014, at 21:27, Marco Pivetta wrote:
> While rambling with some code today, I realized that `call_user_func`
> behaves strangely, appearing and disappearing from stack traces depending
> on versions of PHP. For an example, compare
> http://3v4l.org/fGpIk#vphp7@20140901, http://3v4l.org
Hello folks,
While rambling with some code today, I realized that `call_user_func`
behaves strangely, appearing and disappearing from stack traces depending
on versions of PHP. For an example, compare
http://3v4l.org/fGpIk#vphp7@20140901, http://3v4l.org/fGpIk#v530 and
http://3v4l.org/fGpIk#vhhvm-
Hi!
> When do you plan to release a new 5.4.34 / 5.5.18 version with a fix for
Next week.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> Can you please elaborate a little ?
> Doesn't such leak have to be fixed in ext/gmp ?
We clean up the memory at the end of the request. But if the request
ended abnormally and we had some active gmp objects, with gmp data
allocated outside emalloc we could not clean that and it ends up bein
Patrick wrote:
> I would love to be able to catch, at toplevel. with an error handler or
> otherwise, both the memory limits exceeded and time limit exceeded cases.
+1, as the kids today say.
I don't think that it should require any new code - we already have
the ability to extend the memory limi
Looking at the list of fatal errors Nikita classified as not suitable for
converting to exceptions, I'd like to take exception : ) with two of them:
I would love to be able to catch, at toplevel. with an error handler or
otherwise, both the memory limits exceeded and time limit exceeded cases.
Th
yes, we will need to do something when we will going to freeze future major
development.
https://wiki.php.net/phpng-upgrading is not up to date as well.
Thanks. Dmitry.
On Fri, Oct 10, 2014 at 2:34 PM, Nikita Popov wrote:
> On Fri, Oct 10, 2014 at 12:59 AM, Tjerk Meesters > wrote:
>
>> Hi
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 10/10/2014 12:57, Andrea Faulds a écrit :
>
>> On 10 Oct 2014, at 09:39, Remi Collet
>> wrote:
>>
>> Short, changing gmp memory allocator can cause segfaults in
>> various case where gnutls is used and initialized "before" gmp.
>>
>> - - php + g
Hi,
When do you plan to release a new 5.4.34 / 5.5.18 version with a fix for
those issues ? I'm concerned because our app is just broken with this
issue. Moreover 5.4.33 / 5.5.17 are used in some PHP Buildpack on PAAS
platform like cloudfoundry/pivotal, they are directly affected by the
probl
On Tue, Oct 7, 2014 at 1:07 AM, Stas Malyshev
wrote:
> Hi!
>
> > As such I'm re-proposing this RFC for inclusion in PHP 7:
> >
> > https://wiki.php.net/rfc/engine_exceptions_for_php7
> >
> > The RFC text is essentially the same as previously, with the primary
> > difference being that parse e
W dniu 2014-10-10 13:37, Nikita Popov pisze:
On Fri, Oct 10, 2014 at 1:36 PM, Maciej Sobaczewski wrote:
Hello Nikita,
have you removed first points a-d intentionally?
https://github.com/php/php-src/commit/3efc331701786d7ffd2587013d71a4
dba0070759
Cheers,
Maciej.
Yes, these were leftovers
On Fri, Oct 10, 2014 at 1:36 PM, Maciej Sobaczewski wrote:
> Hello Nikita,
>
> have you removed first points a-d intentionally?
> https://github.com/php/php-src/commit/3efc331701786d7ffd2587013d71a4
> dba0070759
>
> Cheers,
> Maciej.
>
Yes, these were leftovers of the 5.6 changelog.
Nikita
Maintaining php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On 10 Oct 2014, at 09:39, Remi Collet wrote:
>
> Short, changing gmp memory allocator can cause segfaults in various
> case where gnutls is used and initialized "before" gmp.
>
> - - php + gmp + curl => segfaults
> - - apache + mod_php + mod_gnutls + gmp => segfaults
> - - php + gmp + odbc +
On Fri, Oct 10, 2014 at 10:39 AM, Remi Collet
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> See https://bugs.php.net/63595
>
>
> Short, changing gmp memory allocator can cause segfaults in various
> case where gnutls is used and initialized "before" gmp.
>
> - - php + gmp +
On Fri, Oct 10, 2014 at 12:59 AM, Tjerk Meesters
wrote:
> Hi
>
> On 10 Oct 2014, at 03:57, Dmitry Stogov wrote:
>
> > Yeah, JavaBridge used it, but it doesn't means it need it.
> >
> > zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
> > {
> >return java_class;
> > }
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
See https://bugs.php.net/63595
Short, changing gmp memory allocator can cause segfaults in various
case where gnutls is used and initialized "before" gmp.
- - php + gmp + curl => segfaults
- - apache + mod_php + mod_gnutls + gmp => segfaults
-
36 matches
Mail list logo
