Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
But there is still no reaction at all after 2 years. What else can I do to
get the bug(s) fixed?
https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13
Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
But there is still no reaction at all after 2 years. What else can I do to
get the bug(s) fixed?https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13
bringing that up here can help! :)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I submitted a bugfix patch for this one:
https://bugs.php.net/bug.php?id=63615 on 2012-12-06
and asked for feedback here, to make sure this was intended
functionality. I also have not heard back, and the bug is still
unassigned. It's not something that ever affected me personally, it
was a random bug that I saw and fixed while in the date/time section
of the core.
Thanks in advance :)
Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
But there is still no reaction at all after 2 years. What else can I do to
get the bug(s) fixed?https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13bringing that up here can help! :)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Adding Derick to the loop
I submitted a bugfix patch for this one:
https://bugs.php.net/bug.php?id=63615 on 2012-12-06
and asked for feedback here, to make sure this was intended
functionality. I also have not heard back, and the bug is still
unassigned. It's not something that ever affected me personally, it
was a random bug that I saw and fixed while in the date/time section
of the core.Thanks in advance :)
Hi, there is a bug(s) I'd like to be fixed and even a patch is
available.
But there is still no reaction at all after 2 years. What else can I do
to
get the bug(s) fixed?https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13bringing that up here can help! :)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I submitted a bugfix patch for this one:
https://bugs.php.net/bug.php?id=63615 on 2012-12-06
and asked for feedback here, to make sure this was intended
functionality. I also have not heard back, and the bug is still
unassigned. It's not something that ever affected me personally, it
was a random bug that I saw and fixed while in the date/time section
of the core.
I will have to double check whether this is intended or not. I'm slowly
getting to look at datetime issues again, and will get to it at some
point (soon).
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Hi!
Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
But there is still no reaction at all after 2 years. What else can I do to
get the bug(s) fixed?
Pull request may speed things up, writing to internals might too :)
https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
This patch seems to do only part of the work - it does not add the
option to getTrace, it does not use DEBUG_BACKTRACE_* constants and it
does not have tests. If you are willing to get it to completion and
submit a pull request with complete fix, it can be integrated pretty
quickly,
https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13
This one was waiting for maintainer's input.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I've looked into it and I'm not sure whether an option for getTrace method is the best way to solve this. I mean the trace is created along with the exception so it would have to be generated with the object fields regardless and then filtered if the option is not set. I think it would be better to add new PHP directive for this (disabled by default for back compatibility).
Also what do you mean by DEBUG_BACKTRACE_*?
Dne Fri, 04 Jan 2013 21:59:19 +0100 Stas Malyshev smalyshev@sugarcrm.com napsal(a):
Hi!
Hi, there is a bug(s) I'd like to be fixed and even a patch is available.
But there is still no reaction at all after 2 years. What else can I do to
get the bug(s) fixed?Pull request may speed things up, writing to internals might too :)
https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13
This patch seems to do only part of the work - it does not add the
option to getTrace, it does not use DEBUG_BACKTRACE_* constants and it
does not have tests. If you are willing to get it to completion and
submit a pull request with complete fix, it can be integrated pretty
quickly,https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13
This one was waiting for maintainer's input.
Hi!
I've looked into it and I'm not sure whether an option for getTrace
method is the best way to solve this. I mean the trace is created
along with the exception so it would have to be generated with the
object fields regardless and then filtered if the option is not set.
I think it would be better to add new PHP directive for this
(disabled by default for back compatibility).
No, I don't think it is a good idea. We have too many config directives
already, and behavior-modifying directives is really not a good idea,
since it is a global state with all its problems.
Also what do you mean by DEBUG_BACKTRACE_*?
Constants used for trace parameters.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Are you sure there should be the $options parameter? It would not save any memory because the trace needs to be pregenerated regardless. Back compatibilty clearly doesn't need to be that strict in this case because for example in case of debug_backtrace function the 'object' fields where added in 5.1.1 (not in 5.1.0!) and were enabled by default (there wasn't even a way to disable them - that came with 5.2.5).
With that in mind there is no need for the $options parameter in my opinon. Which meens the only thing missing is the tests, right?
Dne Sat, 05 Jan 2013 23:30:55 +0100 Stas Malyshev smalyshev@sugarcrm.com napsal(a):
Hi!
I've looked into it and I'm not sure whether an option for getTrace
method is the best way to solve this. I mean the trace is created
along with the exception so it would have to be generated with the
object fields regardless and then filtered if the option is not set.
I think it would be better to add new PHP directive for this
(disabled by default for back compatibility).No, I don't think it is a good idea. We have too many config directives
already, and behavior-modifying directives is really not a good idea,
since it is a global state with all its problems.Also what do you mean by DEBUG_BACKTRACE_*?
Constants used for trace parameters.
And by tests I mean fixing all the old tests which use Exception::getTrace(). There is no need to write a new test(s).
Dne Sun, 06 Jan 2013 00:28:17 +0100 Jáchym Toušek enumag@gmail.com napsal(a):
Are you sure there should be the $options parameter? It would not save any memory because the trace needs to be pregenerated regardless. Back compatibilty clearly doesn't need to be that strict in this case because for example in case of debug_backtrace function the 'object' fields where added in 5.1.1 (not in 5.1.0!) and were enabled by default (there wasn't even a way to disable them - that came with 5.2.5).
With that in mind there is no need for the $options parameter in my opinon. Which meens the only thing missing is the tests, right?
Dne Sat, 05 Jan 2013 23:30:55 +0100 Stas Malyshev smalyshev@sugarcrm.com napsal(a):
Hi!
I've looked into it and I'm not sure whether an option for getTrace
method is the best way to solve this. I mean the trace is created
along with the exception so it would have to be generated with the
object fields regardless and then filtered if the option is not set.
I think it would be better to add new PHP directive for this
(disabled by default for back compatibility).No, I don't think it is a good idea. We have too many config directives
already, and behavior-modifying directives is really not a good idea,
since it is a global state with all its problems.Also what do you mean by DEBUG_BACKTRACE_*?
Constants used for trace parameters.
Hi!
Are you sure there should be the $options parameter? It would not
save any memory because the trace needs to be pregenerated
regardless. Back compatibilty clearly doesn't need to be that strict
in this case because for example in case of debug_backtrace function
the 'object' fields where added in 5.1.1 (not in 5.1.0!) and were
enabled by default (there wasn't even a way to disable them - that
came with 5.2.5).
Lacking it will mean that the output of this function will be huge and
frequently impossible to properly display without filtering, as objects
tend to be huge and complex. So you won't be able to do
var_export($e->getTrace()) anymore and get something useful. The whole
point of having those args in other backtrace function is to make them
easily useful in logs, etc. without additional filtering. So yes, I
think the parameter would be useful there. Actually, adding it without a
parameter may very well break some apps that casually do something like:
catch(Exception $e) {
$this->log->debug("Caught exception, backtrace:
".var_export($e->getTrace(), true));
}
Since the whole trace will be loaded into memory and that may cause
out-of-memory condition if the object in question aggregates tons of
other objects.
Besides that, for consistency reasons it may be useful that all
backtrace functions would have the same options.
That may mean we'd have to post-process the result of getTrace, but it
should not be too hard to do...
With that in mind there is no need for the $options parameter in my
opinon. Which meens the only thing missing is the tests, right?
Tests would be good in any case.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I don't understand. There already IS the 'args' field where huge objects also can be (and very often are). The new 'object' field does not make any difference in this regard.
Dne Sun, 06 Jan 2013 00:42:58 +0100 Stas Malyshev smalyshev@sugarcrm.com napsal(a):
Hi!
Are you sure there should be the $options parameter? It would not
save any memory because the trace needs to be pregenerated
regardless. Back compatibilty clearly doesn't need to be that strict
in this case because for example in case of debug_backtrace function
the 'object' fields where added in 5.1.1 (not in 5.1.0!) and were
enabled by default (there wasn't even a way to disable them - that
came with 5.2.5).Lacking it will mean that the output of this function will be huge and
frequently impossible to properly display without filtering, as objects
tend to be huge and complex. So you won't be able to do
var_export($e->getTrace()) anymore and get something useful. The whole
point of having those args in other backtrace function is to make them
easily useful in logs, etc. without additional filtering. So yes, I
think the parameter would be useful there. Actually, adding it without a
parameter may very well break some apps that casually do something like:catch(Exception $e) {
$this->log->debug("Caught exception, backtrace:
".var_export($e->getTrace(), true));
}Since the whole trace will be loaded into memory and that may cause
out-of-memory condition if the object in question aggregates tons of
other objects.
Besides that, for consistency reasons it may be useful that all
backtrace functions would have the same options.
That may mean we'd have to post-process the result of getTrace, but it
should not be too hard to do...With that in mind there is no need for the $options parameter in my
opinon. Which meens the only thing missing is the tests, right?Tests would be good in any case.
Hi!
I don't understand. There already IS the 'args' field where huge
objects also can be (and very often are). The new 'object' field
does not make any difference in this regard.
It adds another place where huge objects can be - and unlike args, it is
guaranteed to be an object, and those tend to be big. So chances to blow
up the memory with this function become higher. That's why other
functions gained parameters to amend this situation some time ago, this
one would be good to add it too.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I agree with you that the parameters would be good. There should also be the limit parameter (same as for debug_backtrace). However I'm afraid I'm not that much familiar with C to actually write it.
It's true that in 'args' there theoretically may not be any object. But as you are surely aware, the probability of that is pretty much zero in a real PHP application. Unless it does not use OOP of course, but in that case the 'object' field would also be empty.
That means it would be good to add the parameters to Exception::getTrace(), but as I'm unable to do so there won't be anything wrong with just adding the 'object' for the timebeeing, don't you think? It would be very helpful for those who use some fancy debugger (see http://blog.juzna.cz/2011/07/tuning-error-reporting-in-php/).
Dne Sun, 06 Jan 2013 00:50:22 +0100 Stas Malyshev smalyshev@sugarcrm.com napsal(a):
Hi!
I don't understand. There already IS the 'args' field where huge
objects also can be (and very often are). The new 'object' field
does not make any difference in this regard.It adds another place where huge objects can be - and unlike args, it is
guaranteed to be an object, and those tend to be big. So chances to blow
up the memory with this function become higher. That's why other
functions gained parameters to amend this situation some time ago, this
one would be good to add it too.
Hi!
I agree with you that the parameters would be good. There should also
be the limit parameter (same as for debug_backtrace). However I'm
afraid I'm not that much familiar with C to actually write it.
There's a bigger problem with this bug. The problem is that if we keep
the object in the exception, we may break some other things. See this
bug: https://bugs.php.net/bug.php?id=29368
The fix for it relies on the fact that if ctor fails, nobody holds the
reference to the object. In the case when we keep the object, this no
longer would be true and this bug would show up again. So before we
change this, we need better solution for #29368.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227