Open sonersivri opened 2 years ago
Hello @sonersivri
What version of memprof are you using ? (you can find it with php -dextension=memprof.so -i | grep memprof
)
Does it crash without the ion cube extension ?
@arnaud-lb I am seeing the same issue on another OS. I am seg faulting in both Apache 2 AND CLI. I am using the PHP 8.1 docker image.
PHP 8.1.1 (cli) (built: Dec 21 2021 19:41:31) (NTS)
memprof support => enabled memprof version => 3.0.2 memprof native malloc support => Yes memprof.output_dir => /tmp => /tmp
Hi @mattrcampbell
Is this happening when profiling a particular script, or on any script ?
How are you enabling profiling ?
Could you post the list of extensions loaded ? (php -m
)
It is happening on a particular script when it hits the memory limit, but it relies on so much in-house code I can't post it here. When I run it on a simple script that does makes too big of a string, I don't get a core.
Modules: [PHP Modules] Core ctype curl date dom fileinfo filter ftp gd hash iconv json ldap libxml mbstring memprof mysqli mysqlnd oci8 openssl pcre PDO pdo_sqlite Phar posix readline Reflection session SimpleXML sodium SPL sqlite3 standard tokenizer xml xmlreader xmlwriter zlib
[Zend Modules]
Thank you. What is the output of var_dump(memprof_enabled_flags());
?
array(3) { ["enabled"]=> bool(true) ["native"]=> bool(false) ["dump_on_limit"]=> bool(true) }
Would you be able to provide a backtrace of the segfault ?
You can get one with gdb:
MEMPROF_PROFILE=dump_on_limit gdb --args php script.php
Type run
on prompt, and then type backtrace
when you see a segfault
Looks like it might be stuck in some sort of loop, this repeats for a very long time
It's possible that there is a very deep recursion in your code, causing this stack overflow (each memprof_zend_execute
and execute_ex
call here is a PHP function call). Without memprof, this recursion would instead cause a memory exhaustion (this may be the cause of the memory exhaustion you are trying to debug).
If you download https://raw.githubusercontent.com/php/php-src/master/.gdbinit
to you current folder and run gdb
again, you can obtain a PHP-level backtrace by running zbacktrace
(instead of backtrace
). This might tell you which code is causing this.
If it's not that, then it could be a bug in get_function_name().
This is very strange, I can't quite figure out why but I am getting this error:
No symbol "basic_functions_module" in current context.
Ok a quick edit of .gdbinit and I was able to get a backtrace.... did find a loop in our code.
Thank you for the details you provided @mattrcampbell, this helped a lot to understand the problem.
I've created a separate issue so that memprof handles this in a better way in the future.