At 06:44 AM 12/19/2003 -0500, Rob Richards wrote:
Did the problem end up being due to zend_execute.c 1.566 patch?
Within the zend_assign_to_object function, the temp variable needs to be
free'd, otherwise it needs to be handled within the extensions themselves.
Not sure about the other functions i
Did the problem end up being due to zend_execute.c 1.566 patch?
Within the zend_assign_to_object function, the temp variable needs to be
free'd, otherwise it needs to be handled within the extensions themselves.
Not sure about the other functions in that patch as I only ran into issues
with this f
Hi,
as I wrote in my initial post: Even changing the paramters for
pear/install-pear.php "helps" and I am not able to create a simpler
script reproducing the crash. But meanwhile I've found the time when it
broke:
zend_execute.c,v 1.565 2003/12/14 16:09:07 still works but
zend_execute.c,v 1.566
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
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):
23 matches
Mail list logo
