# How to get a PHP bug fixed? - Thread: https://externals.io/message/64526 - Original archive: https://news-web.php.net/php.internals/64526 - Started by Enumag on 2013-01-04T17:33:14+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64526 — Enumag — 2013-01-04T17:33:14+00:00 URL: https://externals.io/message/64526#64526 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 --- ## #64527 — Ferenc Kovacs — 2013-01-04T17:36:59+00:00 URL: https://externals.io/message/64526#64527 · In reply to: #64526 > 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 --- ## #64528 — Paul Taulborg — 2013-01-04T19:22:58+00:00 URL: https://externals.io/message/64526#64528 · In reply to: #64527 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 :) > > > > […] > > bringing that up here can help! :) > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #64529 — Pierre Joye — 2013-01-04T19:35:43+00:00 URL: https://externals.io/message/64526#64529 · In reply to: #64528 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 :) > > > > […] > available. > > […] > to > > […] --- ## #64530 — Stas Malyshev — 2013-01-04T20:59:19+00:00 URL: https://externals.io/message/64526#64530 · In reply to: #64526 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 --- ## #64531 — Derick Rethans — 2013-01-04T21:20:43+00:00 URL: https://externals.io/message/64526#64531 · In reply to: #64528 > 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 --- ## #64561 — enumag@gmail.com — 2013-01-05T22:20:11+00:00 URL: https://externals.io/message/64526#64561 · In reply to: #64530 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 napsal(a): > Hi! > > > […] > > Pull request may speed things up, writing to internals might too :) > > > […] > > 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, > > > […] > > This one was waiting for maintainer's input. --- ## #64563 — Stas Malyshev — 2013-01-05T22:30:55+00:00 URL: https://externals.io/message/64526#64563 · In reply to: #64561 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 --- ## #64567 — enumag@gmail.com — 2013-01-05T23:28:17+00:00 URL: https://externals.io/message/64526#64567 · In reply to: #64563 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 napsal(a): > Hi! > > > […] > > 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. > > > […] > > Constants used for trace parameters. --- ## #64574 — enumag@gmail.com — 2013-01-05T23:41:56+00:00 URL: https://externals.io/message/64526#64574 · In reply to: #64567 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 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 napsal(a): > > > […] --- ## #64575 — Stas Malyshev — 2013-01-05T23:42:58+00:00 URL: https://externals.io/message/64526#64575 · In reply to: #64567 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 --- ## #64578 — enumag@gmail.com — 2013-01-05T23:47:20+00:00 URL: https://externals.io/message/64526#64578 · In reply to: #64575 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 napsal(a): > Hi! > > > […] > > 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... > > > […] > > Tests would be good in any case. --- ## #64579 — Stas Malyshev — 2013-01-05T23:50:22+00:00 URL: https://externals.io/message/64526#64579 · In reply to: #64578 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 --- ## #64581 — enumag@gmail.com — 2013-01-06T00:08:34+00:00 URL: https://externals.io/message/64526#64581 · In reply to: #64579 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 napsal(a): > Hi! > > > […] > > 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. --- ## #64597 — Stas Malyshev — 2013-01-06T04:16:16+00:00 URL: https://externals.io/message/64526#64597 · In reply to: #64581 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