Hello,
I'm trying to see why $ make install-pear-packages segfaults with HEAD.
I hope I'll commit the fixes today. I suspect references problem...
I got new messages (which where not displayed before):
: var: Deprecated. Please use the public/private/protected modifiers in
XXX.php on line XX
On Thu, 18 Dec 2003 12:43:03 +0100
Pierre-Alain Joye [EMAIL PROTECTED] wrote:
Hello,
I'm trying to see why $ make install-pear-packages segfaults with
HEAD. I hope I'll commit the fixes today. I suspect references
problem...
I got new messages (which where not displayed before):
: var:
On Thu, 18 Dec 2003, Pierre-Alain Joye wrote:
Ok segfault is on line pear/PEAR/Registry.php line 345.
This is a call to unserialize. I do not know yet why it fails. Maybe
(again) the serialized data is corrupted. Anyway unserialize should
never segfault.
Can you put the datafile + serialize
On Thu, 18 Dec 2003 13:50:10 +0100 (CET)
Derick Rethans [EMAIL PROTECTED] wrote:
On Thu, 18 Dec 2003, Pierre-Alain Joye wrote:
Ok segfault is on line pear/PEAR/Registry.php line 345.
This is a call to unserialize. I do not know yet why it fails. Maybe
(again) the serialized data is
Hello Pierre-Alain,
Thursday, December 18, 2003, 12:43:03 PM, you wrote:
Hello,
I'm trying to see why $ make install-pear-packages segfaults with HEAD.
I hope I'll commit the fixes today. I suspect references problem...
I got new messages (which where not displayed before):
: var:
On Thu, 18 Dec 2003 14:44:29 +0100 (CET)
Derick Rethans [EMAIL PROTECTED] wrote:
Guesso... can you try to run it in valgrind, it should show all memory
overruns etc..
Already done, no overuns, and obviously non freed mem after the crash ;)
Important note (dunno why I did not say that before
The only call to error_reporting() is in pearcmd.php:
error_reporting(E_ALL ~E_NOTICE);
I added a var_dump(error_reporting()); and got 2039 out, as expected,
but I am still getting E_STRICT warnings galore. I wonder if E_STRICT
is on no matter what in head? I added ~E_STRICT (which of
On Thu, Dec 18, 2003 at 11:44:27AM -0500, Greg Beaver wrote:
I wonder if E_STRICT is on no matter what in head?
It's not. Something in the pear install scripts is turning it on.
--Dan
--
FREE scripts that make web and database programming easier
Unless it is possible to turn on E_STRICT without using the
error_reporting() function, then this is not true - there is only 1
error_reporting() in all of the .php files that make up the PEAR core,
try grep if you don't believe me.
Greg
Daniel Convissor wrote:
On Thu, Dec 18, 2003 at
Daniel Convissor wrote:
It's the custom error handler in pearcmd.php. PHP doesn't pay attention
to any error_reporting() settings when a custom error handler is
established. Then, error_handler() doesn't account for the new warning
level.
Is it just me or is this undesired behaviour? I noticed
Personally, I both like and dislike this behavior. I like it for debugging
purposes, since it allows me full control over whether I ignore
error_reporting level or perhaps just log disabled levels instead of
displaying them, etc. On the other hand, there is a minor performance issue,
but if you
On Thu, 18 Dec 2003, Christian Schneider wrote:
Daniel Convissor wrote:
It's the custom error handler in pearcmd.php. PHP doesn't pay attention
to any error_reporting() settings when a custom error handler is
established. Then, error_handler() doesn't account for the new warning
level.
At the least, this needs to be added to the thin-changes file, as it
will bork any script that uses a custom error handler and has PHP 4 objects.
Thanks for the catch Dan, that fixes it.
Greg
Christian Schneider wrote:
Daniel Convissor wrote:
It's the custom error handler in pearcmd.php. PHP
On Thursday 18 December 2003 18.25, Christian Schneider wrote:
Daniel Convissor wrote:
It's the custom error handler in pearcmd.php. PHP doesn't pay attention
to any error_reporting() settings when a custom error handler is
established. Then, error_handler() doesn't account for the new
On Thu, 18 Dec 2003, Greg Beaver wrote:
At the least, this needs to be added to the thin-changes file, as it
will bork any script that uses a custom error handler and has PHP 4 objects.
It won't bork all scripts with a custom errorhandler if their default
action is to ignore core and other
Any chance you can dissect it to the smallest piece of code that still
produces the crash?
At 14:46 18/12/2003, Pierre-Alain Joye wrote:
On Thu, 18 Dec 2003 12:43:03 +0100
Pierre-Alain Joye [EMAIL PROTECTED] wrote:
Hello,
I'm trying to see why $ make install-pear-packages segfaults with
Derick Rethans wrote:
It won't bork all scripts with a custom errorhandler if their default
action is to ignore core and other errors but only handle the ones they
should handle. I do agree that it should be mentioned in the changes
file though.
On the other hand you have to be very careful
Greg:
On Thu, Dec 18, 2003 at 12:48:01PM -0500, Greg Beaver wrote:
Thanks for the catch Dan, that fixes it.
But your fix uses the E_STRICT constant, which of course doesn't exist in
PHP 4, so an undefined constant notice gets produced.
I'm wondering why there's even a custom error handler
At 07:20 PM 12/18/2003 +0100, Christian Schneider wrote:
Derick Rethans wrote:
It won't bork all scripts with a custom errorhandler if their default
action is to ignore core and other errors but only handle the ones they
should handle. I do agree that it should be mentioned in the changes
file
On Thu, 18 Dec 2003, Andi Gutmans wrote:
In any case, I do think that the custom error handler being called for any
error is bogus. Why should E_STRICT or E_NOTICES be sent to the handler if
they are off?
So you're suggesting to add another BC break here, without a really
good reason? :)
At 10:24 PM 12/18/2003 +0100, Derick Rethans wrote:
On Thu, 18 Dec 2003, Andi Gutmans wrote:
In any case, I do think that the custom error handler being called for any
error is bogus. Why should E_STRICT or E_NOTICES be sent to the handler if
they are off?
So you're suggesting to add another
On Thu, 18 Dec 2003, Andi Gutmans wrote:
At 10:24 PM 12/18/2003 +0100, Derick Rethans wrote:
On Thu, 18 Dec 2003, Andi Gutmans wrote:
In any case, I do think that the custom error handler being called for any
error is bogus. Why should E_STRICT or E_NOTICES be sent to the handler if
Andi Gutmans wrote:
At 10:24 PM 12/18/2003 +0100, Derick Rethans wrote:
On Thu, 18 Dec 2003, Andi Gutmans wrote:
In any case, I do think that the custom error handler being called
for any
error is bogus. Why should E_STRICT or E_NOTICES be sent to the
handler if
they are off?
So you're
On Thu, 2003-12-18 at 20:35, Andi Gutmans wrote:
At 07:20 PM 12/18/2003 +0100, Christian Schneider wrote:
Derick Rethans wrote:
It won't bork all scripts with a custom errorhandler if their default
action is to ignore core and other errors but only handle the ones they
should handle. I do
On Thu, 2003-12-18 at 22:56, Andi Gutmans wrote:
At 10:24 PM 12/18/2003 +0100, Derick Rethans wrote:
On Thu, 18 Dec 2003, Andi Gutmans wrote:
In any case, I do think that the custom error handler being called for any
error is bogus. Why should E_STRICT or E_NOTICES be sent to the handler
Stig S. Bakken wrote:
Good question. Having an error handling function becomes really
expensive if your code is not E_ALL-clean in a loop or something.
if you set a custom error handler you know what you are doing
and probably don't have such places in the code :)
IMHO the error_reporting
On Thu, 18 Dec 2003, Stig S. Bakken wrote:
Anyway, I'm holding off with Beta 3 until we fix the
--install-pear-packages problem. I'd call that a showstopper because it's
something pretty basic.
Has anyone managed to create a reproducing script or backtrace?
It doesn't crash on my box :(
27 matches
Mail list logo
