[Question] Memory cannot be read from inside the container

[LikeToStudy]

I started two containers, the first container running my php application and the second container running reli-prof

The namespace "--pid=container:<container_name>" is shared with the container. And I can see my php process in the reli container

Run "./reli i:trace -p "

Error "failed to read memory. target_pid=, remote_address=0x55555681f420, errno=38"

Is there currently no support for tracking between containers?

Or is it because the php program is running in a container and cannot be traced back to the host's memory information?

Hope to get your reply, thank you very much

[LikeToStudy]

[sj-i]

@LikeToStudy
Hi!

Is there currently no support for tracking between containers?

It's a supported use of Reli.

errno=38

38 is ENOSYS. I guess some security feature in linux like seccomp prevents Reli from calling a syscall which reads the memory of the target process.
You can try --security-opt="seccomp=unconfined" for an option to your docker command.

[LikeToStudy]

@sj-i
Hi

Thanks for your reply. After a series of attempts, reli-prof can be used normally now

Would you like to ask whether reli-prof currently supports the tracking of coroutines?

[sj-i]

@LikeToStudy Hi!

Sorry for the late reply. I'm dead busy now... as usual.

whether reli-prof currently supports the tracking of coroutines?

I can say it has limited support.
Only one context (callstack) currently executed at the time of tracing is analyzed.
Reli currently doesn't track callstacks of suspended Generators or Fibers, or Swoole Coroutines.
Either the memory profiling mode doesn't extract callstacks from suspended croutines.
They are listed on my todos.

In my previous attempt, for Swoole, the executing call stack could be analysed when Swoole is installed as an extension. For swoole-cli, the official binary distribution of Swoole, I doubt it's possible to analyze it without modification currently.

[LikeToStudy]

@sj-i Hi!
I have disturbed you many times, you can reply when you have time, thank you very much

Now the bad thing is, if you install php through the installation tool, you can run the trace command,
but compiled php, can not trace, will show that it can not access memory.

I don't know why?

I have opened the access restriction of the containe.

look forward to your reply

[LikeToStudy]

@sj-i Hi!
After trying and trying, I found two problems

1. In the case of a compiled version of PHP, it seems appropriate to turn on the PIE option and compile PHP to DYN mode instead of EXEC mode, which would result in untraceable memory

The command is: "readelf -h /usr/bin/php"

2. In PHP-FPM mode, if opcache.huge_code_pages = 1 is enabled, memory tracing cannot be performed

I can't explore the related principles of influence, but it has these problems, I wonder if you have encountered, and can know why?

Looking forward to your reply

[LikeToStudy]

@sj-i Hi

When I was doing a memory trace of the PHP-FPM process, I found a problem.

Is there currently no memory tracking support for PHP-FPM?

When PHP-FPM receives the request, another error is displayed

Version information is as follows

• sh-4.4# php -v
  PHP 8.1.9 (cli) (built: Sep 14 2024 07:32:53) (NTS)
  Copyright (c) The PHP Group
  Zend Engine v4.1.9, Copyright (c) Zend Technologies
  with Zend OPcache v8.1.9, Copyright (c), by Zend Technologies
• sh-4.4# php-fpm -v
  PHP 8.1.9 (fpm-fcgi) (built: Sep 14 2024 07:32:54)
  Copyright (c) The PHP Group
  Zend Engine v4.1.9, Copyright (c) Zend Technologies
  with Zend OPcache v8.1.9, Copyright (c), by Zend Technologies

Looking forward to your reply