1. #1
    Ext JS Premium Member
    Join Date
    Apr 2010
    Location
    Montréal, Canada
    Posts
    221
    Vote Rating
    5
    Christiand is on a distinguished road

      0  

    Default how to: debug Layout run failed

    how to: debug Layout run failed


    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 ?

  2. #2
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,403
    Vote Rating
    147
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      0  

    Default


    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
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  3. #3
    Ext JS Premium Member
    Join Date
    Apr 2010
    Location
    Montréal, Canada
    Posts
    221
    Vote Rating
    5
    Christiand is on a distinguished road

      0  

    Default


    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.

  4. #4
    Sencha User Daniil's Avatar
    Join Date
    Jun 2010
    Location
    Saint-Petersburg, Russia
    Posts
    975
    Vote Rating
    112
    Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all

      0  

    Default


    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:

    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:
    Code:
    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?
    Ext.NET - ASP.NET for Ext JS
    MVC and WebForms
    Examples | Twitter

  5. #5
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,403
    Vote Rating
    147
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      1  

    Default


    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.
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  6. #6
    Sencha User Daniil's Avatar
    Join Date
    Jun 2010
    Location
    Saint-Petersburg, Russia
    Posts
    975
    Vote Rating
    112
    Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all

      0  

    Default


    Quote Originally Posted by dongryphon View Post
    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.

    Quote Originally Posted by dongryphon View Post
    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.

    Quote Originally Posted by Daniil View Post
    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:
    Code:
    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?
    Ext.NET - ASP.NET for Ext JS
    MVC and WebForms
    Examples | Twitter

  7. #7
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,403
    Vote Rating
    147
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      1  

    Default


    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.
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  8. #8
    Sencha User Daniil's Avatar
    Join Date
    Jun 2010
    Location
    Saint-Petersburg, Russia
    Posts
    975
    Vote Rating
    112
    Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all

      0  

    Default


    Quote Originally Posted by dongryphon View Post
    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?

    Quote Originally Posted by dongryphon View Post
    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
    Ext.NET - ASP.NET for Ext JS
    MVC and WebForms
    Examples | Twitter

  9. #9
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,403
    Vote Rating
    147
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      1  

    Default


    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:

    Code:
       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:

    Code:
    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.
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  10. #10
    Sencha User Daniil's Avatar
    Join Date
    Jun 2010
    Location
    Saint-Petersburg, Russia
    Posts
    975
    Vote Rating
    112
    Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all Daniil is a name known to all

      0  

    Default


    Thank you, Don.

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

    Yes, the Page Analyzer output looks much more readable. As far as I can understand with "diag.layout" I just see a layout run tree in the console as text, which I see in Page Analyzer as a tree component. Though with "diag.layout" I see many "[W] Bad" warnings that is probably worth to investigate. Maybe it might be worth to show those warnings in Page Analyzer as well in a separate tab or else? Just a suggestion. Anyway, those warnings seems to be not related to the initial problem. At least, at first glance. Anyway, it is nice to know about the "diag.layout" feature, I can be helpful Thank you for that tip.

    Re: Layout run failed

    I think you are right in your guesses. Overflowing or, to be more precise, vertical scrolling cause a Column layout to be crashed. The calculateOverflow method marks the layout me.done = false and it is not getting done anymore in spite of the fact that the calculate method is called twice after that. It looks a bug. Finally, I were able to strip down the real page to get a more or less simple test case with a bit of layout overnesting.
    http://www.sencha.com/forum/showthread.php?266284

    Avoid vertical scrolling as a possible solution

    As a possible solution for now we can avoid vertical scrolling. For that we are setting flex: 1 for some VBox item instead of explicit height. By the way, VBox seems to require flex or height settings to be explicitly set up for its items. The same with HBox and flex and width settings. Our customers often have issues with theirs layouts if they don't set up these settings. It would be worth to have, at least, a warning in the dev mode with a message like "flex or height settings are missed. You might need to set one" for a VBox and "flex or width settings are missed. You might need to set one" for an HBox. What do you think?
    Ext.NET - ASP.NET for Ext JS
    MVC and WebForms
    Examples | Twitter

Thread Participants: 2