"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

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.

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.

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,...)

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

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;"

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]

That is really weird :(

Can you try again with this debugging patch: 
http://users.telenet.be/patrick_allaert/patches/debug2.patch

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

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...

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

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

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.

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?

Altough its a flaw in XDebug off course. Im just curious if 
this hook can be reused..

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.

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)