If I throw an exception somewhere deep in my php code, it is printed by xdebug in front with this default orange layout, if you know what i mean. Problem is, that the call stack or stack trace there is too short. It shows only the first 5 steps.
If I catch the exception directly after throwing and print the ->xdebug_message variable out, it shows the complete call stack / stack trace, which has 14 steps.
Do anybody has an idea what could cause this problem? I'm searching already the whole day for a solution.
Versions:
PHP 5.3.6
Xdebug 2.2.3
xdebug.show_exception_trace
Type: integer, Default value: 0
When this setting is set to 1, Xdebug will show a stack trace whenever an exception is raised - even if this exception is actually caught.
Related
I cannot seem to locate the source of this issue. I actually have nearly the same Docker container and Exception handler lib running in another app. However, for some reason, I'm getting duplicate log entries in the error log file.
The issue is that it's not just duplicate entries that are the same (that'd be another interesting issue). It's the same Exception being logged and the same stack trace, but one is from my custom Exception handler (JSON), and the other is the default PHP error log handler (or so it seems - tested with CLI SAPI as well as PHP-FPM).
I was under the assumption that PHP wouldn't write to the log file if an exception handler was set. I'm also executing die(1) at the end of the callback function for the Exception handler.
Again, all of the Exception handling code seems to be working well. It's just that PHP is still logging the Exception. Is there a setting or something else that I'm missing here needing to be done on the PHP config side?
Below is a copy of the error log output:
[24-Nov-2018 02:20:11 UTC] PHP Exception: Testing in /srv/www/boot/common.php on line 65
[24-Nov-2018 02:20:11 UTC] PHP Stack trace:
[24-Nov-2018 02:20:11 UTC] PHP 1. {main}() /srv/www/public/index.php:0
[24-Nov-2018 02:20:11 UTC] PHP 2. require() /srv/www/public/index.php:13
{"timestamp":"2018-11-24 02:20:11 UTC","level":"critical","message":"Testing","app_version":{},"environment":"dev","class":"Exception","file":"\/srv\/www\/boot\/common.php","line":65,"code":0,"previous":null,"trace":[{"file":"\/srv\/www\/public\/index.php","line":13,"function":"require"}],"user":[],"tags":[],"extra":[],"output_buffers":[]}
Going to leave this here for anyone that might come across this. The issue turned out to be XDebug which hijacks your Exceptions. It was enabled on this particular app in our dev env.
I recently installed xdebug, and now stack traces are printed to my apache error.log:
PHP Fatal error: Call to a member function get_upload() on null in /var/www/html/template/user/post-single.php on line 10
PHP Stack trace:
PHP 1. {main}() /var/www/html/index.php:0
PHP 2. include() /var/www/html/index.php:19
I dont like them, as they clutter my log, and if i need them i will get them from my debugging client. Is there any way i can disable them?
EDIT: To be clear, i do not want to disable Xdebug, I just want it to not print the stack traces.
While migrating to a new host with PHP 5.4.x from old host with 5.3.x. I'm stumbling into a problem with E_STRICT.
I know that E_STRICT became part of E_ALL as of PHP 5.4, thus I have disabled it in php.ini.
But I still get an error in combination with Zend_Session, meaning the first page load is ok, I get the frontpage. If I refresh or go to another subpage I get the following error:
Fatal error: Uncaught exception 'Zend_Session_Exception' with message
'Zend_Session::start() -
/var/www/vhost/dev3_domain_com/httpdocs/application/models/someapi.php(
Line:4): Error #2048 Declaration of Someapi::getBeverageSizes() should
be compatible with
My_Service_Someapi::getBeverageSizes($storenumber, $ordertype)
/var/www/vhost/dev3_domain_com/httpdocs/application/models/someapi/Order
.php(Line:1039): Error #2 Creating default object from empty value
/var/www/vhost/dev3_domain_com/httpdocs/application/models/someapi/Order
.php(Line:1039): Error #2 Creating default object from empty value' in
/var/www/vhost/dev3_domain_com/httpdocs/library/Zend/Session.php:490
Stack trace: #0
/var/www/vhost/dev3_domain_com/httpdocs/library/Zend/Session/Namespace.
php(143): Zend_Session::start(true) #1
/var/www/vhost/dev3_domain_com/httpdocs/application/Bootstrap.php(213):
Zend_Session_Namespace->__construct('someapi') #2
/var/www/vhost/dev3_domain_com/httpdocs/library/Zend/Application/
Bootstrap/BootstrapAbstract.php(669): Bootstrap->_initO in
/var/www/vhost/dev3_domain_com/httpdocs/library/Zend/Session.php on line 490
I know I could/should fix my code, but it's quite tedious. The "Someapi" class is extended from "My_Service_Someapi" which in turn is extended from "Zend_Rest_Client" - to handle the webservice from our backend system.
Could it be that Zend Framework sets it's own error reporting? I know from other SO-posts that CakePHP does that.
I am developing a website using PHP and mongodb. I access the mongodb with PECL-mongo, and have run into an annoyance. Every now and then, I get an error like this (I've anonymized the paths)
Fatal error: Uncaught exception 'MongoCursorException' with message 'couldn't get response header' in
/PATH/index.php:38 Stack trace: #0
/PATH/index.php(38): MongoCursor->rewind() #1
/PATH/template.inc(29): get_sidebar() #2
/PATH/index.php(13):
require_once('PATH/...') #3 {main} thrown in PATH/index.php on line 38
According to the documentation, this means:
The driver could not fetch a reply header from the database, so it
gave up. Check if the database is still up and the network is
connected and try the query again.
But I know that the database is up because I am doing this locally on my own machine over loopback. No connection is made to the outside world.
Simply trying again often works. Is this a possibly a bug in PHP's driver for mongo? Could this be a "miscompile" issue (I compiled from source, but with very benign flags, -march=native -O2)?
Has anyone seen this before?
Searching around, I only see references to some stupid facebook game having the same error.
EDIT: I just downgraded my PECL driver to version 1.1.4 and so far, the problem seems have gone away. So this may simply be a bug in the 1.2.x series. If anyone can shed any light on it, that would be great.
EDIT: I am not doing anything complex here, the code that is having the issue litterally looks like this:
$m = new Mongo();
$collection = $m->my_db->collection;
$results = $collection->find(array("favorite"=>true))->limit(5);
i solved this problem with get new version mogodb.dll
you can see http://www.mongodb.org/display/DOCS/PHP+Language+Center
I get this error randomly when using Zend_Search_Lucene.
Exception thrown without a stack frame in Unknown on line 0
Has anybody ran into this who can help?
Thank you.
Zend_Search_Lucene commits data within destructor.
Static variables are destructed later and exception handling engine may be already unloaded.
Use $index->commmit(); before end of script.