Hi all!
Are there any objections if I disable E_DEPRECATED notice in dl() for FPM SAPI?
The notice is already disabled for CGI/FastCGI, CLI and Embed SAPIs.
I believe there's no reason for this notice in case of FPM, too.
Patch: http://dev.daylessday.org/diff/fpm_dl_notice.diff
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Hi all!
Are there any objections if I disable
E_DEPRECATEDnotice indl()for FPM SAPI?
The notice is already disabled for CGI/FastCGI, CLI and Embed SAPIs.
I believe there's no reason for this notice in case of FPM, too.
I think it can be quite dangerous if you have extensions living shorter
than the PHP process. Not only might dlclose() cause some leaks but
there are a few extensions playing with function pointers or opcode
handlers which aren't properly reset so a following request might try to
jump to invalid memory.
Additionally there's no restriction on this once safe_mode is gone, so
anybody could load any C extension - while that can be fixed by
advertising disable_function=dl
johannes
I think it can be quite dangerous if you have extensions living shorter
than the PHP process. Not only might dlclose() cause some leaks but
there are a few extensions playing with function pointers or opcode
handlers which aren't properly reset so a following request might try to
jump to invalid memory.
dlclose()? I can assure you I'm not going to call dlclose() on each request shutdown.
Yes, that means once an extension is loaded it'll stay till the death of this particular child process).
But it does work here for the last 5 or 6 years this way and this is indeed what I want.
TBH I'm not even sure dlclose() is called at all since I wasn't able to track
this call down through all the handlers, destructors and so on in 5 min I spent on this..
Additionally there's no restriction on this once safe_mode is gone, so
anybody could load any C extension - while that can be fixed by
advertising disable_function=dl
That's right, disabling it is not a problem.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
I think it can be quite dangerous if you have extensions living shorter
than the PHP process. Not only might dlclose() cause some leaks but
there are a few extensions playing with function pointers or opcode
handlers which aren't properly reset so a following request might try to
jump to invalid memory.dlclose()? I can assure you I'm not going to call dlclose() on each request shutdown.
Yes, that means once an extension is loaded it'll stay till the death of this particular child process).
But it does work here for the last 5 or 6 years this way and this is indeed what I want.
TBH I'm not even sure dlclose() is called at all since I wasn't able to track
this call down through all the handlers, destructors and so on in 5 min I spent on this..
module_destructor() calls it and expected it to be hit on rshutdown,
else has really weird behavior - for some processes an extension would
be loaded, for others not which results in non-deterministic behavior
for the outside.
http://lxr.php.net/opengrok/xref/PHP_5_3/Zend/zend_API.c#2120
johannes
Are there any objections if I disable
E_DEPRECATEDnotice indl()for FPM SAPI?
The notice is already disabled for CGI/FastCGI, CLI and Embed SAPIs.
I believe there's no reason for this notice in case of FPM, too.
IMO, it should be disabled in fastcgi too. Ages ago we came to the
conclusion it was dangerous/annoying/broken to have dl() work with
processes that run multiple-requests.
cheers,
Derick