I'm not able to reproduce the issue. I've tried with current Symfony 2.1 and a simple controller like what you describe. You have something else going on. Here is what I've done on a clean Symfony SE: https://github.com/fabpot/symfony-standard/compare/symfony:2.1...fabpot:PR6227.patch

ok .. after a while of debugging i found that the issue was caused by FOSRestBundle and I fixed the issue with:
FriendsOfSymfony/FOSRestBundle@4601376

however i am not sure why this is causing an issue. i guess it must be related to this line here https://github.com/symfony/HttpFoundation/blob/master/Response.php#L143 being undone.

hmm no .. when i was cleaning up my setup the issue returned .. debugging this again.

i tried everything to isolate the issue in my project or reproduce it in your SE fork .. i still dont know what is causing this.

I have the same bug, I indeed found that since Symfony 2.1, ESI (with standalone true) can't get along with a main cached action (with public shared cache)...

This bug doesn't exist in the previous SF versions (work fine on 2.0.11) !

Remark @fabpot : the bug only appears when returning on the page plural times (the first time, all is well displayed, the page and ESI work fine ! The second or third time, design is broken and the error displayed)

Example when the bug appeared:

Main action:

   /**
     * @Route("/", name="sybiowebsite_main_index")
     * @Cache(smaxage="100")
     * @Template()
     */
    public function indexAction()
    {
        return array();
    }

template -> SybioWebsiteBundle:Main:index.html.twig:

   {% render "SybioWebsiteBundle:Category:listEsi" with {}, {'standalone': true} %}

The error, it appears only if standalone is set to true:

LogicException: The section "50cb77cfaf8eb" has been started at an other level and can not be opened.

This is a problem because I can't cache (http cache) entirely my websites :s

@Sybio habe you managed to setup an SE fork where this issue is reproducable?

@Sybio That would help a lot if you give us a fork of the Symfony Standard Edition with code that exhibit the issue (like I did above in a previous comment).

LogicException: The section "50ffddbd7d7cf" has been started at an other level and can not be opened.

Getting this on every app_dev.php page after running composer update for master branch today.

@NihilNovi: I've just tried with master and I still don't have the issue. Can you list the bundles you are using?

"require": {
    "php": ">=5.3.3",
    "symfony/symfony": "2.2.*",
    "doctrine/orm": ">=2.2.3,<2.4-dev",
    "doctrine/doctrine-bundle": "1.2.*",
    "twig/extensions": "1.0.*",
    "symfony/assetic-bundle": "2.1.*",
    "symfony/swiftmailer-bundle": "2.2.*",
    "symfony/monolog-bundle": "2.2.*",
    "sensio/distribution-bundle": "2.2.*",
    "sensio/framework-extra-bundle": "2.2.*",
    "sensio/generator-bundle": "2.2.*",
    "jms/security-extra-bundle": "1.4.*",
    "jms/di-extra-bundle": "1.3.*",
    "jms/serializer-bundle": "0.9",
    "friendsofsymfony/rest-bundle": "0.10.0"
},

I manged to make it go away by disabling the profiler, clearing cache and enabling it again after building the cache.

I have the same issue when I enable profiler and turn on debug. I suspect it's because of my specific setup however. I'm running it on a very old system (hybrid) so I suspect that I missed some dispatches which causes the total number of stopwatch start+stop to mis-match?

I have the same issue, unfortunately I can't reproduce this in a sandbox app...

I can confirm it's because of an esi, for example this makes the error appear :

{% render(controller("MyMainBundle:Menu:main")), { strategy: 'esi' } %}

And switching to "inline" fixes it, I've also made the action in quesiton only returning a 200 'Hello' response and the bug is still here so I don't think it's because of something wrong at action level.

Are we all using vagrant in here? I've just noticed it doesn't occur with wamp.

yes. I was using vagrant in this setup

I'm using 64bit wamp running php 5.4.3.

@lsmith77 @NihilNovi : #7033 should do the trick :)

i am no vacation this week ..

@lsmith77 nevermind, it has been closed anyway, @fabpot is working on a fix, just enjoy your holidays ;)

For the record, I'm not working on a fix, I was just saying that your PR was not good.

@fabpot : ok, just FYI, and if someone wants to take a look at this, the patch you've previously made (https://github.com/fabpot/symfony-standard/compare/symfony:2.1...fabpot:PR6227.patch) was correct, it makes this issue reproductible.

You probably didn't see the exception because it occurs on kernel.terminate event, when the response has already been sent, you couldn't see it in the logs neither because currently symfony can't log fatal errors (it's an uncaught exception), only display them.