What revision/commit ID are you using?

Note that apm_get_mysql_events() doesn't return anything, it prints data 
directly so var_dump() on it is irrelevant.

I am able to call thousands of times apm_get_mysql_events() without any 
segfault, nor from apache, nor from CLI.

Valgrind doesn't report any memory leak as well.

I upgraded to the latest version from svn, but I still get it.

php -r "apm_get_mysql_events();"

shows the errors from the newest to the oldest.
then the end looks like this:

{id:"1", cell:["1", "2012-06-11 09:18:32", "E_PARSE", "http:\/\/<i>[unknown]
<\/i>", "Command line code", "1", "0.0.0.0", "syntax error, unexpected end of 
file, expecting \u0027,\u0027 or \u0027;\u0027"]},
Segmentation fault

Hmm, I think I have something.

php -r "echo apm_get_mysql_events_count();"

returns 23. However there are only 22 rows in the database, thus it segfaults 
trying to access the non-existing 23rd row.

This is extremely weird!

apm_get_mysql_events_count() only returns as an int what: "SELECT COUNT(*) FROM 
event" returns.

The things you can do to help me resolve this issue is:
* dumping the database and attach it here or send it to me
* Run "SELECT COUNT(*) FROM event"/"SELECT * FROM event" and tell me what you 
have

The most helpful thing would be to get a backtrace from gdb.

For this you need to compile APM with:
$ export CFLAGS='-ggdb -O0'
$ ./configure [rest of your configure options] 

and run:
$ gdb php

at the gdb prompt, enter:
(gdb) run  -r "apm_get_mysql_events();"

This should run the function, output the result and crash with a segfault as you 
have it.
At this moment, ask for the backtrace to gdb:
(gdb) bt

An give me the generated output.

Thanks in advance

Ok, more info.
When compiling with -O0 or -O1 I don't get the segfault, only with -O2
I have the backtrace, but it doesn't look very useful to me. Anyway:

Program received signal SIGSEGV, Segmentation fault.
0x00000000006b1245 in ?? ()
(gdb) bt
#0  0x00000000006b1245 in ?? ()
#1  0x000000000066b25f in execute ()
#2  0x00000000005ffa46 in zend_eval_stringl ()
#3  0x00000000005ffb19 in zend_eval_stringl_ex ()
#4  0x00000000006b3b4d in ?? ()
#5  0x000000000042e28f in ?? ()
#6  0x00007ffff5b06aa5 in __libc_start_main () from /lib64/libc.so.6
#7  0x000000000042e325 in _start ()

I'll send you the db dump via email.

And you can disregard the mismatch of count and output, it's fine. I merely 
compared with out-of-date data. Sorry about that.

ok, not an easy one :-\

The backtrace is indeed useless.

Some questions:

May I have your precise version of gcc?

Are you running 32 or 64 bits?

Do you have the same problem with apm_get_sqlite_events() or with the _count 
version of them?

Do you have this problem with -Os and -O3 as well?

I doubt I can really fix anything here, however I can prevent -O2/-Os/-O3 to be 
used by dynamically replacing those flags with -O1.

The best thing however would be to know which exact optimization flag enabled by 
O2 is causing this issue by actively disabling it with -fno...

This is something that you can maybe do on your side:
compare the flags that are active with -O1 vs the ones active with -O2.
You can save that list with:
$ gcc -c -Q -O1 --help=optimizers > O1
$ gcc -c -Q -O2 --help=optimizers > O2

and:
$ diff O1 O2

to see what is the difference between those.

Next step would be to test with -O2 but with disabling one of the optimization 
at 
a time: e.g.:

$ for opt in noalign-functions noalign-jumps noalign-labels noalign-loops 
noreorder-blocks [... other noXXX flags] ; do CFLAGS="-O2 -f$opt" ./configure 
[rest of your configure options] &&  make clean && make && sudo make install && 
php -r "apm_get_mysql_events();" &> output-$opt; done

Then try to grep / grep -v on output-* to figure out which one is causing 
issues.

My output of gcc -v:

hwiesinger@callisto:~$ gcc -v
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.7.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/4.7.0/lto-wrapper
Target: x86_64-slackware-linux
Configured with: ../gcc-4.7.0/configure --prefix=/usr --libdir=/usr/lib64 --
mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-
languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-
checking=release --enable-objc-gc --with-system-zlib --with-python-
dir=/lib64/python2.6/site-packages --disable-libunwind-exceptions --enable-
__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --enable-java-
home --with-java-home=/usr/lib64/jvm/jre --with-jvm-root-dir=/usr/lib64/jvm --
with-jvm-jar-dir=/usr/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-
antlr-jar=/home/slackware/slackbuilds/gcc/antlr-runtime-3.4.jar --enable-
multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --
host=x86_64-slackware-linux
Thread model: posix
gcc version 4.7.0 (GCC)

I do have the same problem with -Os and -O3.
I don't have it with sqlite or the count methods

I tried tracking down the exact optimization but none of the ones I identified 
causes the issue, not even all of them combined, so I'm pretty much at a loss 
here. Given however that this can be easily solved by using -O1 instead of -O2 
I'm fine with this solution (at least for me personally) as well.

Suspending since you have found a solution that works for you.

I won't filter C flags for now but will not hesitate to reopen this one if I get 
some other feedback.

Thanks for all the effort you made investigating that issue.

Closing the bug, apm_get_mysql_events() is not implemented in the extension anymore.