Subview crashes / backbone / Chorus 2.5.x based code

30 views
Skip to first unread message

Shell (Aridhia Informatics)

unread,
Dec 13, 2013, 9:16:41 AM12/13/13
to choru...@googlegroups.com
Hi all,

Perhaps someone can suggest a solution for an issue we're seeing. This is probably a backbone design pattern question...

A parent view with a template containing three tabs. Each of the tabs has content populated by subviews in the parent.

The problem? User clicking between tabs eventually triggers a dramatic Chrome (30-31, Mac and Windows) crash and simply halts Chrome's v8 engine. Viewing debug profiles, we can see that the keypress event handler has gobbled up 600+Mb of memory.

Mock code follows:

Parent view

setup: function(options) {
 
this.mySubView1 = new chorus.views.mySubViewMaker({ workspace: options.model, mode: ... });
 
this.mySubView2 = new chorus.views.mySubViewMaker({ workspace: options.model, mode: ... });
 
...
}

Each of these subviews contains a CodeMirror editor running in a custom mode. The editors are only initialised when a user clicks a tab in the handlebar below.

Handlebar:

<section>
   
<section class="tab-pane app-tab1 active" id="mySubView1"></section>
    <section class="tab-pane app-tab2" id="mySubView2"></section>
   
...
</section>

We capture the users' clicks...

events: {
   
'click .app-tab1': 'handleClick',
   
...
},

Which is handled...

handleClick: function(e) {
    e
&& e.preventDefault();
   
this.$(".app-tab1").tab('show');
   ... initialize the CodeMirror editor in this subview ...

},
  1. We should probably restructure the subviews so that they load on demand (rather than setup of the parent view). I've not found a clean way of doing this.
  2. In turn we could unload the views while they're not visible, freeing up resource...
  3. Get to the bottom of why the key handler goes haywire and kills Chrome - a conflict between multiple CodeMirrors? Chorus's own key handling?
Suggestions/thoughts are welcomed because while I can see *where* the crash is happening, I'm not sure how we should go about fixing it, or why the crash is quite so dramatic.

S.

Robbie Gill

unread,
Dec 15, 2013, 3:24:02 PM12/15/13
to choru...@googlegroups.com
Not sure I have a concrete answer for you, but maybe some helpful suggestions.

Regarding your numbered points.

2. Depending on how the users will interact with the editors, (tabbing often vs sticking on one tab) it may be worth unloading the non-active tabs. It seems we do not have a great example of this in the chorus codebase, as the sidebar tabs are hidden rather than unloaded. Though we could take that idea and load/unload rather than add/remove 'hidden' class. 




--
You received this message because you are subscribed to the Google Groups "chorus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chorus-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Robbie Gill

unread,
Dec 15, 2013, 3:35:26 PM12/15/13
to choru...@googlegroups.com
Sorry for the multipart response - the 'cmd+enter' send email shortcut got me...

3. As far as the source of the crash, I'm wondering if there is some event loop being triggered with the code mirror editors. Does your custom mode hook into any of the code mirror events such that triggering one of these events gets into a cycle that eventually triggers that event again?  That's my first thought from the 10k meter view. Is it reproducible with code mirror running in a more vanilla mode? 

I suspect that loading/unload these 3 tabs on demand could be a nice optimization but guess that it is not the root cause here. 

Hope this can trigger something to help you get to the bottom of this. 

-Robbie


On Fri, Dec 13, 2013 at 6:16 AM, Shell (Aridhia Informatics) <shell...@gmail.com> wrote:

--

Shell (Aridhia Informatics)

unread,
Dec 17, 2013, 9:16:24 AM12/17/13
to choru...@googlegroups.com
Hi Robbie, thanks for the response.

After some heavy reorganisation of the code in this area we discovered the root cause, so I'll share. It's a combination of plugins, rather than something to do with backbone or our structure of Views.

Tab 1 contains a virtual terminal, using the jqueryTerminal plugin. Tab 2-3 contain CodeMirrors. When a user clicks a CodeMirror tab, the virtual terminal is 'paused' and disabled. However for some reason keydown events still 'leak' into the plugin, causing some rather bizarre behaviour. Basically, there's a method inside jqueryTerminal that chops up output line by line. When a CodeMirror is active, this code still gets run, but on an negative value string length... causing the attached event handler to loop forever (eating up all available memory). From the outside it looks like the View has crashed, but it's the plugin...

We hacked a fix (https://github.com/jcubic/jquery.terminal/issues/131) that's got us up and running for now.

That was a rather painful one to resolve!

S.
Reply all
Reply to author
Forward
0 new messages