php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #59579 Custom internal error callback handlers are ignored by Xdebug
Submitted: 2011-01-14 18:06 UTC Modified: 2020-01-20 17:18 UTC
From: marcodekrijger at gmail dot com Assigned: derick (profile)
Status: Closed Package: Xdebug
PHP Version: 5.3.2 OS: Ubuntu 10.10
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: marcodekrijger at gmail dot com
New email:
PHP Version: OS:

 

 [2011-01-14 18:06 UTC] marcodekrijger at gmail dot com
Description:
------------
Once installed using the manual from 
http://code.google.com/p/peclapm/wiki/Install And 
configuring the php.ini file (see reproduce code block). I 
only get records for the slow pages. When generating an 
error e.g. trigger_error('adsf', E_USER_NOTICE); or throw 
new Exception('asdf') the table events stays empty. I 
tracked the syslog and apache logs, but couldnt find 
anything.

Somehow the db ini setting is ambigious 
apm.sqlite_db_path="/etc/php5/apm/db"
apm.db_path="/etc/php5/apm/d

the db_path directive doesnt work (when reviewing the 
phpinfo page). So I setted both directives to my own path. I 
also tried to use the default path, but that doesnt make any 
difference

Reproduce code:
---------------
extension=apm.so

;;;;;;;;;;;;;;;;;;;
; Module Settings ;
;;;;;;;;;;;;;;;;;;;
[apm]
; Whether the extension is globally active or not (overrides apm.event_enabled and apm.slow_request_enabled)
apm.enabled="1"
; Enable the capture of events such as errors, notices, warnings,...
apm.event_enabled="1"
; Enable the capture of slow requests
apm.slow_request_enabled="1"
; Maximum duration in ms a request can take before it gets recorded
apm.slow_request_duration="101"
; Path to the SQLite DB directory
; Note: the directory should be readable and writable, SQLite needs to be able to create temporary files in this directory
apm.sqlite_db_path="/etc/php5/apm/db"
apm.db_path="/etc/php5/apm/db"
; Maximum time in ms the extension will keep trying to insert an event into the database
; Setting this to high may slow down your application if you have lot of concurrent events.
; Setting this to low, you may loose some of your concurrent events
apm.max_event_insert_timeout="100"

Expected result:
----------------
The events table to be filled

Actual result:
--------------
The slow request table is filled, but the events table not

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-16 13:09 UTC] patrickallaert@php.net
"apm.db_path" is the old configuration entry, it has been renamed 
to "apm.sqlite_db_path". It has been corrected on the mentioned 
URL.

Could you please provide the output of:
$ ls -la /etc/php5/apm/db/events
$ echo ".schema" | sqlite3 /etc/php5/apm/db/events
 [2011-01-16 13:23 UTC] patrickallaert@php.net
Could you also provide the full apm configuration as seen by 
phpinfo() or $ php -i

Both apm.enabled and apm.sqlite_enabled must be enabled.

On a side note, you might want to use another location than /etc/ 
to store the sqlite DB. /etc/ is normally used for configuration 
files according to the Linux Standard Base (LSB), /var/ might be 
more appropriate. But this has no effect regarding this issue.
 [2011-01-17 15:01 UTC] marcodekrijger at gmail dot com
myusername@knutsel:/var/php/apm/db$ ls -la 
/var/php/apm/db/events
-rwxrwxrwx 1 www-data www-data 4096 2011-01-14 22:31 
/var/php/apm/db/event

myusername@knutsel:/var/php/apm/db$ echo ".schema" | sqlite3 
/var/php/apm/db/events
CREATE TABLE event (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    ts TEXT NOT NULL,
    type INTEGER NOT NULL,
    file TEXT NOT NULL,
    line INTEGER NOT NULL,
    message TEXT NOT NULL,
    backtrace TEXT NOT NULL);
CREATE TABLE slow_request (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    ts TEXT NOT NULL,
    duration FLOAT NOT NULL,
    file TEXT NOT NUL


PHPinfo page:

apm

APM support     enabled
Version 1.0.0beta2

Directive       Local Value     Master Value
apm.deffered_processing On      On
apm.enabled     On      On
apm.event_enabled       On      On
apm.slow_request_duration       100     100
apm.slow_request_enabled        On      On
apm.sqlite_db_path      /var/php/apm/db /var/php/apm/db
apm.sqlite_enabled      On      On
apm.sqlite_error_reporting      no value        no value
apm.sqlite_max_event_insert_timeout     100     100
apm.stacktrace_enabled  On      On

Note that php -i didnt return any results because I have 2
environments a PHP cli env and a PHP web env under Apache. 
This seems
to be separated by having two php.ini files. Above config is 
from the
php.ini file under apache. Under the command line php doesnt 
have APM
enabled

In included the screenshot which says the db is empty for 
events (not
for slow requests)
Also tried:

db = new SQLite3(ini_get('apm.sqlite_db_path').'/events');
$result = $db->query('SELECT * FROM event;');

while ($row = $result->fetchArray())
{
   var_dump($row);
}

But that didnt yield any results as well

Hope I have given some leads to shed some light into this 
case.
 [2011-01-18 05:11 UTC] patrickallaert@php.net
Looks like the problem comes from:
apm.sqlite_error_reporting      no value        no value

This configuration works in a similar way to error_reporting.
I haven't tested, but I think that having apm.sqlite_error_reporting with no value is similar to 
having it set to "0" which means collecting no errors at all.

If you want to collect, e.g., warnings and errors, use:
apm.sqlite_error_reporting = E_WARNING | E_ERROR
(note that this will not catch other warnings/errors types like: E_USER_WARNING, E_USER_ERROR,...)
 [2011-01-19 06:52 UTC] marcodekrijger at gmail dot com
I tried it, by setting int to E_ALL, but unfortunately no 
results.

apm

APM support	enabled
Version	1.0.0beta2

Directive	Local Value	Master Value
apm.deffered_processing	On	On
apm.enabled	On	On
apm.event_enabled	On	On
apm.slow_request_duration	100	100
apm.slow_request_enabled	On	On
apm.sqlite_db_path	/var/php/apm/db	/var/php/apm/db
apm.sqlite_enabled	On	On
apm.sqlite_error_reporting	30719	30719
apm.sqlite_max_event_insert_timeout	100	100
apm.stacktrace_enabled	On	On
 [2011-01-19 07:33 UTC] patrickallaert@php.net
Can you please patch APM with the patch available at http://users.telenet.be/patrick_allaert/patches/debug.patch

$ cd /path/to/apm/sources
$ curl -s http://users.telenet.be/patrick_allaert/patches/debug.patch | patch -p1
# or if you have downloaded the patch:
$ patch -p1 < /path/to/debug.patch

Then, build APM again:
$ make

Install it:
$ (sudo) make install

and finally, post the output of the following commands:

# with stacktrace enabled:
$ php -c /path/to/your/apache/php.ini -d apm.enabled=1 -d apm.deffered_processing=1 -d apm.event_enabled=1 -d 
apm.sqlite_db_path=/var/php/apm/db -d apm.sqlite_enabled=1 -d apm.sqlite_error_reporting=30719 -d apm.stacktrace_enabled=1 -r "doesNotExist();"

# with stacktrace disabled:
$ php -c /path/to/your/apache/php.ini -d apm.enabled=1 -d apm.deffered_processing=1 -d apm.event_enabled=1 -d 
apm.sqlite_db_path=/var/php/apm/db -d apm.sqlite_enabled=1 -d apm.sqlite_error_reporting=30719 -d apm.stacktrace_enabled=0 -r "doesNotExist();"

# content of table event:
sqlite3 /var/php/apm/db/events "SELECT * FROM event;"
 [2011-01-21 05:05 UTC] marcodekrijger at gmail dot com
I patched the file, built it, and restarted apache just to 
be sure. But somehow it can't even get to the patched code, 
because it didnt printf the comment in the patch.

$ php -c /etc/php5/apache2/php.ini -d apm.enabled=1 -d 
apm.deffered_processing=1 -d apm.event_enabled=1 -d 
apm.sqlite_db_path=/var/php/apm/db -d apm.sqlite_enabled=1 -
d apm.sqlite_error_reporting=30719 -d 
apm.stacktrace_enabled=1 -r "doesNotExist();"

PHP Fatal error:  Call to undefined function doesNotExist() 
in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0

$ php -c /etc/php5/apache2/php.ini -d apm.enabled=1 -d 
apm.deffered_processing=1 -d apm.event_enabled=1 -d 
apm.sqlite_db_path=/var/php/apm/db -d apm.sqlite_enabled=1 -
d apm.sqlite_error_reporting=30719 -d 
apm.stacktrace_enabled=0 -r "doesNotExist();"

PHP Fatal error:  Call to undefined function doesNotExist() 
in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0

$ sqlite3 /var/php/apm/db/events "SELECT * FROM event;"
$
[doesnt return any record]
 [2011-01-21 06:24 UTC] patrickallaert@php.net
That is really weird :(

Can you try again with this debugging patch: 
http://users.telenet.be/patrick_allaert/patches/debug2.patch
 [2011-01-21 07:51 UTC] marcodekrijger at gmail dot com
Tried it with the new patch, and got some additional debug 
info here. Both (stacktrace enabled or disabled gave same 
results below):

apm_driver_sqlite3_minit: entering
apm_driver_sqlite3_rinit: entering
apm_driver_sqlite3_rinit: leaving SUCCESS
PHP Fatal error:  Call to undefined function doesNotExist() 
in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0
PHP_RSHUTDOWN_FUNCTION: entering
PHP_RSHUTDOWN_FUNCTION: apm is enabled
PHP_RSHUTDOWN_FUNCTION: leaving

With no records in event table
 [2011-01-21 10:29 UTC] patrickallaert@php.net
Looks like you have an issue with the deffered processing.

I'm sorry to say I won't be able to investigate that before 
February 31st.

You might give a try by disabling deffered processing:
apm.deffered_processing=0

This will directly store the events in the DB instead of pushing 
it into a queue which is emptied at the end of the request.
This might introduce some performance penalty in the case you 
have *HUGE* load + many page generating 
notices/warnings/errors...
 [2011-01-21 13:13 UTC] marcodekrijger at gmail dot com
Disabled deferred_processing, but that doesnt make any 
difference. 

We're all having problems with time :-), np, it can wait. 
Please let me know if there are any updates, Im ready to try 
it again in a later stage. Thnx so far
 [2011-01-22 10:27 UTC] marcodekrijger at gmail dot com
I couldn;t just sit and do nothing, but Im not really a C 
kind of person. But your patch gave me some clues about how 
to debug. I added some php_printf statements to see where it 
comes, and where it can't reach. This is wat I discovered.

With deffered processing enabled:
It gets to the PHP_RSHUTDOWN_FUNCTION but at the if 
statement at line 268 (if (APM_G(deffered_processing) && 
APM_G(events) != *APM_G(last_event)) {) It says that the 
outcome is false, which results in NOT entering this block. 
I checked the APM_G(events) and *APM_G(last_event), and they 
seem to be identical which is the cause of not entering this 
block. I tried disabling this check, but somehow it can't 
loop this APM_G(events) and I do not fully understand is 
technical workings.

With deffered processing disabled:
on init of this module in "PHP_RINIT_FUNCTION" it overrides 
the zend_error_cb with apm_error_cb;. Although it should, 
because the block is never reached because of if 
(APM_G(enabled)) results false???? I tried disabling this 
check to see if it works, but somehow the "apm_error_cb" 
method is never called, which left me clueless about what to 
do.

Maybe this information is a little bit more helpfull
 [2011-01-30 10:29 UTC] patrickallaert@php.net
What are the loaded extensions?

print_r(get_loaded_extensions());

If you have xdebug, can you try disabling it?
AFAIR, xdebug also overrides zend_error_cb with its own error 
callback handler, for this reason, the one of APM is never called 
which might explain why the events are not stored.
 [2011-02-01 13:29 UTC] marcodekrijger at gmail dot com
That makes sense, thnx. I disabled Xdebug, and everyhting is 
working now! For a live env this is really great! However on 
a dev env it would be nice to have XDebug enabled as well. 
Any chance that this will be added as a feature in a future 
release?
 [2011-02-01 13:32 UTC] marcodekrijger at gmail dot com
Altough its a flaw in XDebug off course. Im just curious if 
this hook can be reused..
 [2012-05-13 11:40 UTC] patrickallaert@php.net
-Summary: Events table not filled +Summary: Custom internal error callback handlers are ignored by Xdebug -Package: APM +Package: Xdebug -Assigned To: patrickallaert +Assigned To: derick
 [2012-05-13 11:40 UTC] patrickallaert@php.net
Hi Marco!

If you want Xdebug to be compatible with APM, you might want to take a look at:
https://github.com/derickr/xdebug/pull/24

Basically, Xdebug replaces the error handler and doesn't call the one it replaces, which makes sense, but only if 
this is the original PHP one.

I'm changing the properties of this bug and reassigning it to Derick.
 [2017-10-24 07:58 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: derick +Assigned To:
 [2020-01-20 17:18 UTC] derick@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: derick
 [2020-01-20 17:18 UTC] derick@php.net
If this is Xdebug related, please file a bug report at https://bugs.xdebug.org (but only if you use a supported version of PHP and Xdebug)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 22:01:27 2024 UTC