Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Closed
mvrhov opened this issue Mar 9, 2017 · 13 comments
Closed

[Console] Enhanced stack trace memory problem #21943

mvrhov opened this issue Mar 9, 2017 · 13 comments

Comments

@mvrhov
Copy link

mvrhov commented Mar 9, 2017

Q A
Bug report? yes
Symfony version master

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

@lyrixx
Copy link
Member

lyrixx commented Mar 9, 2017

hello @mvrhov

Do you have a simple reproducer for this bug?

@mvrhov
Copy link
Author

mvrhov commented Mar 9, 2017

Just make a command that throws an exception? The more data in stacktrace the easier this can be spotted.

@lyrixx
Copy link
Member

lyrixx commented Mar 9, 2017

I'm not sure to fully understand your issue.

Your issue is: When a command throw an exception, Symfony use more memory than before?

@mvrhov
Copy link
Author

mvrhov commented Mar 9, 2017

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.

@lyrixx
Copy link
Member

lyrixx commented Mar 9, 2017

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.

@lyrixx
Copy link
Member

lyrixx commented Mar 10, 2017

I just tried to reproduce your issue:

  1. I used symfony-standard.
  2. I created a command, and in this command I just throw an exception.
  3. in bin/console I added: register_shutdown_function(function() { echo memory_get_peak_usage()."\n"; });

I ran this command on master and on 3.2. Symfony uses 2847624 on master and 2746480 on 3.2. So the delta is 101144...

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.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Mar 10, 2017

@mvrhov can you maybe provide also a blackfire memory profile?

@lyrixx
Copy link
Member

lyrixx commented Mar 10, 2017

@mvrhov Don't forget the reproducer please.

@nicolas-grekas
Copy link
Member

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 call_user_func($this->prevErrorHandler,... call.

@lyrixx
Copy link
Member

lyrixx commented Mar 10, 2017

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);
+    }
+}

@nicolas-grekas
Copy link
Member

Could be fixed by #21973, please confirm.

nicolas-grekas added a commit that referenced this issue Mar 11, 2017
…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
@mvrhov
Copy link
Author

mvrhov commented Mar 13, 2017

Yep, down to 21,3M according to blackfire

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants