how to: debug Layout run failed

[Christiand]

Just trying the new 4.2rc and much of my application just don't load (upgrade from 4.13)

On the initial load, I have a bunch of "Layout run failed". What is causing this and how to debug / fix this ?

[dongryphon]

Can you run your app inside the page analyzer example? It can capture all the details of the layout runs and I could look at the data it produces.

That example is just a page with an iframe so you would need to host the example on your server for it to work. It is discussed here - http://www.sencha.com/blog/optimizin...d-applications

[Christiand]

Excellent. The page Analyser load fine. I'll need to dig into this to find what's wrong. I'll report back if there is anything interesting.

[Daniil]

Hi Don,

Thank you for the suggestion, but does Page Analyzer really allow to catch what exactly layout causes "Layout run failed"? If so, it is really nice. But what about to log a message about a crashed layout to the console?

Firstly, some details how I came up with a solution for my current problem. If you do not want to read all the details, please follow almost to the end, where I am talking about the concrete suggestion.

Recently, I was investigating the page of our customer. The page throws "Layout run failed" and consists of ~1500 code lines in Ext.onReady. There is a very tiny chance to catch the problem point just investing/looking at this script. Also it might require some time trying to simplify the page step by step.

So, I tried to debug. A "Layout run failed" stack trace allowed me to find the place where the error is logged, but, unfortunately, it gives no clue what is the container and layout that the error happens with. The only thing I can see there is the Ext.remainingLayouts is more than 0, so, it means there was unsuccessful layout. But, as I said, no information about what the failed layout was. Resolving such issues can make the developers crazy (especially, not so experienced). Debugging the code I got the idea after looking at this code:

handleFailure: function () {
    // This method should never be called, but is need when layouts fail (hence the
    // "should never"). We just disconnect any of the layouts from the run and return
    // them to the state they would be in had the layout completed properly.
    var layouts = this.layouts,
        layout, key;

    Ext.failedLayouts = (Ext.failedLayouts || 0) + 1;

    for (key in layouts) {
        layout = layouts[key];

        if (layouts.hasOwnProperty(key)) {
            layout.running      = false;
            layout.ownerContext = null;
        }
    }

Generally, as said in the comment, it just flushes all layouts including a crashed one (-s). The idea is simple: if a successful layout should have "running: false", so, a crashed one (-s) has, probably, "running: true". So, I put a conditional breakpoint layout.running == true (using Chrome built-in developer tools) on the red line above. Bingo, I got the crashed layout and its owner (layout.ownerContext).

I think it should not be a problem to add the following in the handleFailure method:

if (layout.running === true) {
    Ext.log(Ext.String.format("The '{0}' layout has been crashed. Its owner container is {1}.", layout.type, layout.ownerContext.id))
}

What do you think, Don?

[dongryphon]

I believe what you will see in the Page Analyzer is a red icon next to such layouts... unfortunately when a layout run fails it is likely that multiple layouts are not finished.

Knowing which layout is the culprit can be difficult because we cannot automatically know which of the incomplete layouts is broken. Generally the process of finding the root cause is to look at any unfinished layout and try to see if the information it needs is available - indicating that this layout should have been able to finish and is possibly the root of the problem.

From the Page Analyzer you can also export the layout run in JSON to share with others or post here. It often time contains enough information to narrow things down a lot.

[Daniil]

I believe what you will see in the Page Analyzer is a red icon next to such layouts...

Really, it does. I just tried it. And it is cool. I feel Page Analyzer went quite far since I tried it the previous time.

unfortunately when a layout run fails it is likely that multiple layouts are not finished.

Knowing which layout is the culprit can be difficult because we cannot automatically know which of the incomplete layouts is broken. Generally the process of finding the root cause is to look at any unfinished layout and try to see if the information it needs is available - indicating that this layout should have been able to finish and is possibly the root of the problem.

From the Page Analyzer you can also export the layout run in JSON to share with others or post here. It often time contains enough information to narrow things down a lot.

Yes, I understand this technique, thanks. Generally, knowing a container where the layout is actually failed might be just enough to resolve the problem. And Page Analyzer allows to know it, great. If go ahead, can Page Analyzer give any more clue what exactly the reason of failure? Seems, I can't see any. Can you?

Failed layout.jpg

Finally, could you comment this, please? The idea is providing a developer with a possibility to see a failed layout and its container in the log without a necessity to run Page Analyzer.

But what about to log a message about a crashed layout to the console?

I think it should not be a problem to add the following in the handleFailure method:

if (layout.running === true) {
    Ext.log(Ext.String.format("The '{0}' layout has been crashed. Its  owner container is {1}.", layout.type, layout.ownerContext.id))
}

What do you think, Don?

[dongryphon]

The original layout diagnostics provided by Ext.diag.layout.Context (normally excluded) are based on logging but became pretty useless when there was more than one or a few things reported (which was most of the time). You can try these diagnostic overrides and see if they help you - they may in this case.

It looks like the layout has no data on which it is waiting (that would appear in the Triggers column). I would imagine some logic issue that caused the layout to not complete perhaps based on some combination of configuration options. Just a guess there. If you want to post the JSON I can take a closer look.

[Daniil]

The original layout diagnostics provided by Ext.diag.layout.Context (normally excluded) are based on logging but became pretty useless when there was more than one or a few things reported (which was most of the time). You can try these diagnostic overrides and see if they help you - they may in this case.

Fair enough. Thank you for the Ext.diag.layout.Context tip. Is it excluded from ext-all.js or from the library at all? I searched for the "Ext.diag.layout.Context" text in the entire 4.2.1 build: "not found". Could you, please, clarify, where I can take it?

It looks like the layout has no data on which it is waiting (that would appear in the Triggers column). I would imagine some logic issue that caused the layout to not complete perhaps based on some combination of configuration options. Just a guess there. If you want to post the JSON I can take a closer look.

I want to understand better how useful can be such a log to resolve such issues. So, it would be nice if you can look at the log. A formatted version of the layout log is 5729 lines. So, I am attaching it as a file. Oops, the size limit. So,
http://pastebin.com/wU2nEajs

[dongryphon]

The diag namespace is in the src folder of the SDK but not in the builds. You can require it in dev mode if you want:

   Ext.require('Ext.diag.layout.ContextItem');

You can check out the source:

http://cdn.sencha.com/ext/gpl/4.2.1/...out/Context.js
http://cdn.sencha.com/ext/gpl/4.2.1/...ContextItem.js

In this case, the Show All Triggers shows that the failing layout requested 3 properties:

portalpanel-1020-body.height:dom
portalpanel-1020-body.width:dom
portalpanel-1020.containerChildrenSizeDone:dom

That is, the column layout needed the panel body dimensions to be in the DOM (because these effect overflow) as well as waiting for the child items to perform their layouts and have their results flushed (again because this effects overflow). All of these conditions are met, so I am not sure why the column layout is still running.

To debug in to this you could add a if/debugger (the "if" testing for the id of the one column layout) to the calculate method of Ext.layout.container.Auto to see what is preventing the layout from completing. It will probably run more than once as it waits for data that it needs but its last call should return without setting "me.done = false".

Looking at the code there, the only conditions are that calculateItems returns true and the containerChildrenSizeDone be in the DOM (meaning results of child layouts are flushed). Both look like they should be true.