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
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 ma
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 t
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 handl
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, 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 hand
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:
> 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? :)
D
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 thou
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
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 (anothe
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
>
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 er
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
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 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
>
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 w
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 th
Hi:
On Thu, Dec 18, 2003 at 12:08:09PM -0500, Greg Beaver wrote:
> Unless it is possible to turn on E_STRICT without using the
> error_reporting() function
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
es
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 11:44:27
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
http://www.analysisandsolutio
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 cou
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 befo
On Thu, 18 Dec 2003, Daniel Convissor wrote:
> Hi Pierre:
>
> On Thu, Dec 18, 2003 at 12:43:03PM +0100, Pierre-Alain Joye wrote:
> >
> > I got new messages (which where not displayed before):
> > : var: Deprecated. Please use the public/private/protected modifiers in
> > XXX.php on line XX
>
> I n
Hi Pierre:
On Thu, Dec 18, 2003 at 12:43:03PM +0100, Pierre-Alain Joye wrote:
>
> I got new messages (which where not displayed before):
> : var: Deprecated. Please use the public/private/protected modifiers in
> XXX.php on line XX
I noticed the same thing. The new E_STRICT reporting level prod
On Thu, 18 Dec 2003, Pierre-Alain Joye wrote:
> 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
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: Dep
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
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 + s
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):
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
Hav
31 matches
Mail list logo
