-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Console] Enhanced stack trace memory problem #21943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
hello @mvrhov Do you have a simple reproducer for this bug? |
Just make a command that throws an exception? The more data in stacktrace the easier this can be spotted. |
I'm not sure to fully understand your issue. Your issue is: When a command throw an exception, Symfony use more memory than before? |
I had a command where I didn't catch the exception. Instead of getting the stacktrace or just the message that the exception happened, the PHP was killed because of OOM. |
OK, Thanks, I understand now. It will not be easy to reproduce. But indeed the VarCloners take more resources than before. maybe @nicolas-grekas has an idea for that. |
I just tried to reproduce your issue:
I ran this command on master and on 3.2. Symfony uses So for me there are no issue. Could you fork the SE and put a reproducer in it? If you can not provide a reproducer, I will have to close this issue. Thanks. |
@mvrhov can you maybe provide also a blackfire memory profile? |
@mvrhov Don't forget the reproducer please. |
The profile tells that AbstractCloner calls ErrorHandler 2501 times. Can you give us some messages that get there (the most frequent?) They should be in the logs, or maybe you can just "echo $message" in AbstractCloner just before the |
Ok, I found a way to reproduce it. SE on master + diff --git a/app/config/config_dev.yml b/app/config/config_dev.yml
index 3c86425..eb0e83a 100644
--- a/app/config/config_dev.yml
+++ b/app/config/config_dev.yml
@@ -20,7 +20,7 @@ monolog:
channels: ['!event']
console:
type: console
- channels: ['!event', '!doctrine', '!console']
+ channels: ['!event', '!doctrine']
# uncomment to get logging in your browser
# you may have to allow bigger header sizes in your Web server configuration
#firephp:
diff --git a/bin/console b/bin/console
index a908aaa..8d91e56 100755
--- a/bin/console
+++ b/bin/console
@@ -23,6 +23,8 @@ if ($debug) {
Debug::enable();
}
+register_shutdown_function(function() { echo "\n".memory_get_peak_usage()."\n"; });
+
$kernel = new AppKernel($env, $debug);
$application = new Application($kernel);
$application->run($input);
diff --git a/src/AppBundle/Command/LongRunningCommand.php b/src/AppBundle/Command/LongRunningCommand.php
new file mode 100644
index 0000000..2885116
--- /dev/null
+++ b/src/AppBundle/Command/LongRunningCommand.php
@@ -0,0 +1,25 @@
+<?php
+
+namespace AppBundle\Command;
+
+
+use Psr\Log\LogLevel;
+use Symfony\Bundle\FrameworkBundle\Command\ContainerAwareCommand;
+use Symfony\Component\Console\Input\InputInterface;
+use Symfony\Component\Console\Input\InputOption;
+use Symfony\Component\Console\Output\OutputInterface;
+
+class LongRunningCommand extends ContainerAwareCommand
+{
+ protected function configure()
+ {
+ $this
+ ->setName('app:exception')
+ ;
+ }
+
+ protected function execute(InputInterface $input, OutputInterface $output)
+ {
+ throw new \Exception("Error Processing Request", 1);
+ }
+} |
Could be fixed by #21973, please confirm. |
…colas-grekas) This PR was merged into the 3.2 branch. Discussion ---------- [VarDumper] Add missing isset() checks in some casters | Q | A | ------------- | --- | Branch? | 3.2 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #21943 | License | MIT | Doc PR | - As spotted by @lyrixx, this is what's causing high mem use on 3.2. Fix coming to 2.7 (which has very different code base, thus dedicated PR). Commits ------- 8f0edfb [VarDumper] Add missing isset() checks in some casters
Yep, down to 21,3M according to blackfire |
This #21705 seems to introduce a memory hog.
In most occasions you are greeted with php terminating script due to memory exhaustion (128M) instead of getting the stack dump.
I have run the command with time to see the top memory consumption and it was around 150M-160M.
Running same command with 3.2, the memory used is around 50M
ping @lyrixx
The text was updated successfully, but these errors were encountered: