Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.
I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.
Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.
Cheers,
Edward
Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.
You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.
-Rasmus
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.
Yep. If you like, I can make it so that it only applies for CGI
requests, not FastCGI requests.
Cheers,
Edward
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.Yep. If you like, I can make it so that it only applies for CGI
requests, not FastCGI requests.
It should match the dl() SAPI availability.
-Rasmus
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011:
It should match the
dl()SAPI availability.
OK, can do!
Cheers,
Edward
It seems working on my MacBook.
I just tried php-src-5.4 with
$ uname -a
Darwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version 10.8.0: Tue
Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
$./configure && make
and got following result.
$ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v
==63465== Memcheck, a memory error detector
==63465== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==63465== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==63465== Command: ./sapi/cli/php -v
==63465==
--63465-- ./sapi/cli/php:
--63465-- dSYM directory is missing; consider using --dsymutil=yes
PHP 5.4.0RC1-dev (cli) (built: Nov 8 2011 18:19:07)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
==63465==
==63465== HEAP SUMMARY:
==63465== in use at exit: 104,661 bytes in 8 blocks
==63465== total heap usage: 13,688 allocs, 13,680 frees, 2,936,131
bytes allocated
==63465==
==63465== LEAK SUMMARY:
==63465== definitely lost: 0 bytes in 0 blocks
==63465== indirectly lost: 0 bytes in 0 blocks
==63465== possibly lost: 0 bytes in 0 blocks
==63465== still reachable: 104,661 bytes in 8 blocks
==63465== suppressed: 0 bytes in 0 blocks
==63465== Rerun with --leak-check=full to see details of leaked memory
==63465==
==63465== For counts of detected and suppressed errors, rerun with: -v
==63465== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
However, I got this with bash
$ valgrind bash
==63473== Memcheck, a memory error detector
==63473== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==63473== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==63473== Command: bash
==63473==
==63473== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==63473== the SIGUSR2 signal is used internally by Valgrind
--63473:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
--63473:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011:
It should match the
dl()SAPI availability.OK, can do!
Cheers,
Edward
Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):
http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch
The change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.
Edward
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.-Rasmus
The change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.
What about logging a bug for that specific change so it doesn't get lost, and so
it can be tracked?
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Well, I'm kind of hoping this patch will go in, so we don't have to bother
with a bug. I can if you really want me to.
Cheers,
Edward
Excerpts from Christopher Jones's message of Fri Nov 11 14:28:30 -0500 2011:
The change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.What about logging a bug for that specific change so it doesn't get lost, and so
it can be tracked?Chris
You should always tie a patch to a bug/feature request. Need to know/remember why the patch was applied in the first place.
Well, I'm kind of hoping this patch will go in, so we don't have to bother
with a bug. I can if you really want me to.Cheers,
EdwardExcerpts from Christopher Jones's message of Fri Nov 11 14:28:30 -0500 2011:
The change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.What about logging a bug for that specific change so it doesn't get lost, and so
it can be tracked?Chris
Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk
It is short and simple so I could do it manually, of course, but I'd
like to know what you have been testing it against.
Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patchThe change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.Edward
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.-Rasmus
http://svn.php.net/repository/php/php-src/branches/PHP_5_3
r318957
We also applied it to 5.3.8 release, although we had to fix up the patch
for that. I can port it to 5.4.
Edward
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk
It is short and simple so I could do it manually, of course, but I'd
like to know what you have been testing it against.Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patchThe change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.Edward
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.-Rasmus
Well, it is simple enough that we don't really need a patch. However,
generally if you want to submit a patch it needs to be against a current
svn branch and not an old release. You want to minimize the work people
will need to do to look at your suggested change.
The other issue with your patch is that you are enabling this for the
fpm sapi. I thought we agreed that this should only be in the sapis that
supported dl() and those are cgi, cli and embed. And .user.ini doesn't
apply to embed, so it would just be cli and cgi because these are the
non-persistent cases where there is no danger of screwing up the next
request with a bad extension in a .user.ini file.
-Rasmus
http://svn.php.net/repository/php/php-src/branches/PHP_5_3
r318957We also applied it to 5.3.8 release, although we had to fix up the patch
for that. I can port it to 5.4.Edward
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk
It is short and simple so I could do it manually, of course, but I'd
like to know what you have been testing it against.Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patchThe change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.Edward
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.-Rasmus
hi,
The other issue with your patch is that you are enabling this for the
fpm sapi. I thought we agreed that this should only be in the sapis that
supporteddl()and those are cgi, cli and embed. And .user.ini doesn't
apply to embed, so it would just be cli and cgi because these are the
non-persistent cases where there is no danger of screwing up the next
request with a bad extension in a .user.ini file.
Right, that's what I worry about this patch. I would not introduce
this patch for anything but where dl is available.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
Well, it is simple enough that we don't really need a patch. However,
generally if you want to submit a patch it needs to be against a current
svn branch and not an old release. You want to minimize the work people
will need to do to look at your suggested change.
Gotcha.
The other issue with your patch is that you are enabling this for the
fpm sapi. I thought we agreed that this should only be in the sapis that
supporteddl()and those are cgi, cli and embed. And .user.ini doesn't
apply to embed, so it would just be cli and cgi because these are the
non-persistent cases where there is no danger of screwing up the next
request with a bad extension in a .user.ini file.
Hmm, it looks like cli doesn't have .user.ini support at all. Does this
mean we should implement .user.ini for these SAPIs? I'd be in favor.
Edward
-Rasmus
http://svn.php.net/repository/php/php-src/branches/PHP_5_3
r318957We also applied it to 5.3.8 release, although we had to fix up the patch
for that. I can port it to 5.4.Edward
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk
It is short and simple so I could do it manually, of course, but I'd
like to know what you have been testing it against.Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patchThe change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix regardless
of what you think of the feature change.Edward
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
Hello all,
My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.You are aware that these extensions can't be unloaded, right? So one
user loading an extension will potentially be stepping on another user
and breaking their code.-Rasmus
The other issue with your patch is that you are enabling this for the
fpm sapi. I thought we agreed that this should only be in the sapis that
supporteddl()and those are cgi, cli and embed. And .user.ini doesn't
apply to embed, so it would just be cli and cgi because these are the
non-persistent cases where there is no danger of screwing up the next
request with a bad extension in a .user.ini file.Hmm, it looks like cli doesn't have .user.ini support at all. Does this
mean we should implement .user.ini for these SAPIs? I'd be in favor.
Yes, that's on our todos :)
The idea is to take all the code out of fcgi or fpm and shares it
across all (relevant) SAPIs.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
Well, it is simple enough that we don't really need a patch. However,
generally if you want to submit a patch it needs to be against a current
svn branch and not an old release. You want to minimize the work people
will need to do to look at your suggested change.Gotcha.
The other issue with your patch is that you are enabling this for the
fpm sapi. I thought we agreed that this should only be in the sapis that
supporteddl()and those are cgi, cli and embed. And .user.ini doesn't
apply to embed, so it would just be cli and cgi because these are the
non-persistent cases where there is no danger of screwing up the next
request with a bad extension in a .user.ini file.Hmm, it looks like cli doesn't have .user.ini support at all. Does this
mean we should implement .user.ini for these SAPIs? I'd be in favor.
Hmh.
Whats the difference between .user.ini and -dextension=?
I hate it when bucketloads of .ini files are picked up when I run PHP via cli
-Hannes
Excerpts from Hannes Magnusson's message of Fri Nov 11 18:54:27 -0500 2011:
Hmh.
Whats the difference between .user.ini and -dextension=?
I hate it when bucketloads of .ini files are picked up when I run PHP via cli
The idea would be to make it easy to simulate the same configuration as
when you run from the web as when you run from the command line, since
scripts might be sensitive to those parameters.
Edward
Excerpts from Hannes Magnusson's message of Fri Nov 11 18:54:27 -0500 2011:
Hmh.
Whats the difference between .user.ini and -dextension=?
I hate it when bucketloads of .ini files are picked up when I run PHP via cliThe idea would be to make it easy to simulate the same configuration as
when you run from the web as when you run from the command line, since
scripts might be sensitive to those parameters.
I'm not sure it makes to have .user.ini support in CLI as you can
simply do php -c .user.ini and that's it. I was more thinking of doing
it in web servers related SAPIs only.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org