too much recursion error on Firefox #3028

dohomi · 2014-11-06T09:17:57Z

Hello,

I curious if the Meteor team is aware of the too much recursion bug in Firefox:
http://autoform.meteor.com/qfdetails
The error mainly occurs because of the usage of https://docs.meteor.com/#/full/template_parentdata Template.parentData. We receive this error on all older Computer/Mac/Linux, the page is not opening at all. On newer Macs the website opens with some minor errors.

Thanks, Dominic

The text was updated successfully, but these errors were encountered:

dohomi · 2014-11-13T12:14:51Z

Any idea on this issue?

brylie · 2014-12-25T10:13:17Z

This is also affecting clients using Firefox 34+ on Ubuntu Linux 14.10.

brylie · 2014-12-25T11:39:00Z

I have experienced this issue with FF 34 using the Iron Router package as well. I get the error:

// Without {{> yield }} in the base template
Too much recursion ejson.js:394

// With {{> yield }} in the base template
too much recursion. underscore:164

I am using Iron Router with one base template, without and with a {{> yield }} statement.

brylie · 2015-01-03T07:10:24Z

For easy reproduction, I have created a minimal example using aldeed:autoform:

<body>
 {{> quickForm id="quickform" schema="schema"}}
</body>

schema = new SimpleSchema({
    name: {
        type: String
    }
});

avital · 2015-01-06T05:32:21Z

Does someone have a simple repro without external packages? That will make it easier to investigate.

lalomartins · 2015-01-12T03:13:25Z

@avital I was trying to write one but a deeper look at Meteor-Community-Packages/meteor-autoform#333 points to this being not really a Meteor bug but rather a question of Firefox having a smaller recursion limit (at least on Linux). I'd wait and see what they end up with as a fix.

darkship · 2015-01-15T16:01:44Z

I just run into this problem. I'm using linux mint
I don't use aldeed/meteor-autoform but I have this error on FF 35 and FF 36 both on linux and it doesn't always happen.

I tried http://adamrich.name/recursion.html on different browsers and here are my results:

Windows 8 firefox 34 : 7k5 to 12k recursions with a peak at 20k
Windows 8 firefox 35 : 8k to 11k recursions with a peak at 18k
Windows 8 firefox 36 (dev edition) : 10k to 13k recursions with a peak at 25k
Windows 8 chrome 39 : 22k to 24k recursions
linux mint 17 firefox 35 : 5k to 6k (sometimes 9K) recursions with a peak at 16k
linux mint 17 firefox 36 (dev edition) : 5k to 6k recursions with a peak at 16k
linux mint 17 chromium 39 : 23k recursions

I thought first that was a bug in Firefox dev edition. I updated to firefox 35 so I have no tests with FF34.

I have something like 15 nested templates in my app and when I remove 1 or 2 of them, the bug doesn't show anymore.

@avital Repo with no package : https://github.com/darkship/test_much_recursion
If you increment 1 by 1, there is no error until a while (tried until 100) but if you increment by 12 it breaks.

brylie · 2015-01-15T17:05:31Z

I ran the browser recursion test too:

Stopped at iteration 7181 with error message: too much recursion

Thanks for the suggestion :-)

brylie · 2015-01-15T17:55:26Z

That is an interesting recursion repo @darkship. How can I track down the recursion in Meteor templates? I would like to help shine some light on this issue, and hopefully improve Meteor's scalability, etc :-)

benjamn · 2015-02-04T03:03:11Z

After some investigation, it appears that a combination of deeply nested template contexts in the quickform package, together with relatively deep call stacks in the Blaze implementation, are conspiring to trigger the RangeError. In other words, the call stacks in question are large, but not infinitely large, so there is probably no single bug here that we can fix to make the problem go away entirely, but many opportunities to alleviate the problem in realistic use cases.

Two opportunities that we've thought about so far:

We can make individual stack frames smaller by moving parameters and other local variables onto the heap. Apparently the number of local variables in a function affects the memory footprint of its stack frames, which limits the total number of stack frames that can be nested. So replacing multiple local variables with a single object whose properties represent the original variables might let us get away with more recursion.
We can reimplement some algorithms that are currently recursive as iterative algorithms, for example HTML.visitor (in the htmljs package), which shows up on call stacks for this reproduction.

Given the exploratory nature of these solutions, I'm not sure when we'll be able to provide real results, but we're very glad to know about the problem, and we acknowledge that fixing it will require optimizations in the Blaze implementation.

levino · 2015-02-04T16:41:31Z

Would love a fix too. We have the issue at coyno.

laurentpayot · 2015-02-10T17:59:46Z

Same autoform issue here with Firefox 35.0.1 and Meteor 1.0.3.1 on Ubuntu 14.10. Works fine with Chromium.

aldeed · 2015-02-12T00:58:31Z

An update from the autoform side: I've done some work in devel branch to remove unnecessary layers of templates. It's helped a bit but it's still pretty easy to reproduce this issue. I think the primary culprit is the way autoform is using parentData. We recurse through a bunch of layers of templates and then look up the tree with parentData. I don't think parentData itself uses much recursion, but it might be resulting in a reactive dependency that leads to recursion upon reruns.

Still pretty much guessing. Hopefully I can figure out a clean reproduction.

brylie · 2015-02-12T08:10:56Z

Thanks for your work on this issue Eric. :-) How can we coordinate efforts to narrow this down?

Edited I thought this was the autoform issue thread.

brylie · 2015-02-12T09:58:26Z

Somewhat off-topic, but interestingly relevant is the paper Natural language – no infinity
and probably no recursion (Luuk and Luuk, 2012).

BradRyan · 2015-02-16T03:36:15Z

I'm getting "Maximum call stack size exceeded" in Chrome when Autovalue is taking another field value, this.siblingField(). I am able to store the field value in a local variable and return a value from the nested array even. The error occurs after I return the value.

My form is somewhat complex (arrays of objects in a few fields). Might have to manually create input fields for my use case since this sounds like a complicated fix. I'm still happy all my other simpler forms are working well!

mxab · 2015-02-27T11:26:49Z

Seems to be worse with the latest Firefox (36) version on Windows 8

mxab · 2015-02-27T17:08:16Z

I made a nested template example which fails in Firefox in Windows 8 (not tested in 7)
it fails as soon if there are more than 23 nested templates, in chrome it still works if you render more than 150 nested templates
see this example:
https://github.com/mxab/meteor-call-stack-exceed

dohomi · 2015-02-28T04:51:53Z

Hi @benjamn
Does anybody use Meteor for a production app, because in my opinion this is a major blocker and Blaze shouldn't call itself stable. I overlooked this issue for too long already, but Meteor is calling itself stable for almost 4 months and the biggest browser Firefox isn't supported yet. How should production apps survive without the 20-40% of visitors who won't be able to use the app?
Would be great to hear any news on this issue. Thanks

lalomartins · 2015-02-28T10:24:22Z

@dohomi it's quite stable; this bug is a corner case that doesn't come up in normal circumstances. You might flip it around and ask if Firefox is stable! (After all it is, technically speaking, a Firefox bug.)

dohomi · 2015-03-01T11:39:19Z

@lalomartins sorry to say but Firefox is one of the major browser at the moment.. Meteor has to adopt its code to Firefox not other way around.. Who can waive all Firefox users on Windows, Linux or older Macs away because you would state its a Firefox bug? Check @mxab simple reproduction package where you see how easy it is to crash your app. In the end as a startup you depend on every single visitor and they won't care who's responsible for the black page they are visiting - they simply never come back.

lalomartins · 2015-03-01T12:00:19Z

@dohomi you're entirely missing the point, so let me spell it out for you.

Coming here to disparage the project with “can you really call yourself stable” FUD is unproductive and not acceptable behaviour in an issue tracker.

Your users are correct if they don't come back, because as a startup neither meteor or firefox is responsible for the black page your visitors see — you are. You're the only one here trying to shift blame and responsibility. As a startup it's your job to test thoroughly, and honestly, working around browser and/or framework bugs is at least 30% of a web developer's job description. It's especially unpleasant to see you disparaging a project which, I'm sure, already saved you weeks, if not months, of development time, compared to developing whatever you have on any other platform.

So really, play nice. This is not the space for this kind of talk. In fact, I don't think anywhere is.

And it's not the point how easy it is to crash it. The point is, it doesn't happen under normal usage. Yes, there are big production apps out there. You could easily find out by doing a little research instead of asking here. None of those ran into this bug. I have deployed a few production apps myself and only recently I ran into this. That's the definition of a corner case. It's like saying Windows is not stable because it can bluescreen on occasion. Well d'oh. Software fails. Welcome to real life.

brylie · 2015-03-01T18:58:54Z

Hey all. Please consider continuing this discussion on the Meteor forums. At this point it is neither constructive nor salient.

On 1 March 2015 14:01:06 EET, Lalo Martins notifications@github.com wrote:

@dohomi you're entirely missing the point, so let me spell it out for
you.

Coming here to disparage the project with “can you really call yourself
stable” FUD is unproductive and not acceptable behaviour in an issue
tracker.

Your users are correct if they don't come back, because as a startup
neither meteor or firefox is responsible for the black page your
visitors see — you are. You're the only one here trying to shift blame
and responsibility. As a startup it's your job to test thoroughly, and
honestly, working around browser and/or framework bugs is at least 30%
of a web developer's job description. It's especially unpleasant to see
you disparaging a project which, I'm sure, already saved you weeks, if
not months, of development time, compared to developing whatever you
have on any other platform.

So really, play nice. This is not the space for this kind of talk. In
fact, I don't think anywhere is.

Reply to this email directly or view it on GitHub:
#3028 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

mxab · 2015-03-04T02:19:08Z

@lalomartins I would not specify the error as a bug of firefox since I am not aware of any html/js specification about max callstack / recursion limitations ( but also I haven't googled for it hardcore)

I would neither call it a meteor "bug" if you do not take any recursion limitations into account it works as expected, further I think this issue has not surfaced more as there is not official windows development support

due to the tree structured nature of my mini cms I cannot avoid deep nesting of templates

as soon have you have some more "complex" nesting this problem occurs faster
https://github.com/mxab/meteor-call-stack-exceed/tree/more-samples

so I think as @benjamn said, blaze/htmljs needs to be tuned. I tried some peeking in blaze / htmljs parts and was printing out the stack size but I haven't found the point where it "explodes". So if someone could point me in the right direction I really would like to find some workarrounds for this issue

mxab · 2015-03-05T12:41:11Z

Hi @stbaer and I did some more research on the blaze package, after inserting the "catch" statement to log the errors at
master...stbaer:ff_recursion_testing#diff-61be8b0b328aaf8a6ae2f89b67662389R416
and
master...stbaer:ff_recursion_testing#diff-52584623fe717d42fab5db3d19d9a498R481
we noticed several accesses on undefineds, after preventing theses errors at

The original example allow the Win8/Firefox 36 to easily nest more then 300 templates
see https://github.com/mxab/meteor-call-stack-exceed/tree/with-undefined-catches

@benjamn could this be a possible optimisation or are the undefined access in these cases expected or should be handled differently
I haven't tested it against any other packages like @aldeed autoform

aldeed · 2015-03-05T15:32:03Z

@mxab, sounds promising! I will try to find some time to test those changes against autoform recursion errors.

stbaer · 2015-03-11T02:01:52Z

Hi @aldeed, like @mxab said, the changes work very well for the https://github.com/mxab/meteor-call-stack-exceed example. But in our project with autoform included firefox shows an 'unresponsive script' popup.

@avital or anybody from the meteor team, any thoughts on this?

shtefcs · 2015-03-20T02:36:59Z

To much people have problem with it Meteor-Community-Packages/meteor-autoform#333, can you guys @mdg give us some updates on it plsss ?

lalomartins · 2015-03-20T02:43:53Z

Here's the thing though. When I say it's a Firefox issue, I'm not arguing about blame assignment, because that doesn't help solve the problem. What I'm saying is, it's not clear there's anything autoform or meteor can do to fix it. That doesn't mean it's not worth trying, but ultimately, the best fix just might end up being a pull request to Mozilla (or whatever the Mercurial equivalent is).

tl;dr chill

dgreensp · 2015-03-26T00:42:03Z

Fixed on devel. Thanks for your patience, everyone.

mquandalle · 2015-03-26T00:54:15Z

wow!

benjamn · 2015-03-26T02:54:25Z

Awesome!

ripdog · 2015-03-26T03:12:55Z

Yes, thank you! Now Firefox can once again be a first class citizen of
my app! :)

On Thu, Mar 26, 2015, at 03:55 PM, Ben Newman wrote:

Awesome!

— Reply to this email directly or view it on GitHub[1].

Links:

too much recursion error on Firefox #3028 (comment)

boustanihani · 2015-03-26T09:59:59Z

COOL :) When will the fix get published ?

aldeed · 2015-03-26T13:35:09Z

@dgreensp, hoping you can sneak this into 1.1 or a patch soon after.

This way we don't get a stack overflow when materializing nested Views. Certain browser/OS combinations seem to have particularly low budgets (especially Firefox/Windows apparently). Verified by running https://github.com/mxab/meteor-call-stack-exceed on Chrome/Mac. Nesting limit used to be about 160, but now you get unlimited nesting (tried up to 10,000, which renders in about 7-8 seconds). Tested for correctness by running all package tests.

avital · 2015-03-28T07:36:12Z

Yup, this is in 1.1-rc.1

aldeed · 2015-03-30T23:52:10Z

Seems to have fixed the autoform issues. Thanks!

shtefcs · 2015-03-31T00:01:15Z

Awesome, tnx guys!

dohomi · 2015-04-01T05:28:23Z

Thanks guys!

darkship · 2015-04-01T07:29:38Z

This is definitely much, much better, thanks !

I updated my repo https://github.com/darkship/test_much_recursion. I could go from 1 to 457 (instead of 1 to 12) recursions. Some errors remains when I go back to 1 but it doesn't seem to be bothering.

This way we don't get a stack overflow when materializing nested Views. Certain browser/OS combinations seem to have particularly low budgets (especially Firefox/Windows apparently). Verified by running https://github.com/mxab/meteor-call-stack-exceed on Chrome/Mac. Nesting limit used to be about 160, but now you get unlimited nesting (tried up to 10,000, which renders in about 7-8 seconds). Tested for correctness by running all package tests.

dohomi mentioned this issue Nov 6, 2014

Firefox: Exception from Tracker recompute function: too much recursion using quickForm Meteor-Community-Packages/meteor-autoform#333

Closed

yourcelf mentioned this issue Nov 11, 2014

Settings page is blank on fresh install VulcanJS/Vulcan#500

Closed

glasser added the Blaze label Dec 3, 2014

benjamn self-assigned this Feb 4, 2015

shkomg mentioned this issue Feb 23, 2015

Bug in Meteor and autoform package which causes App not working on FireFox CEFware/HostApp#1

Closed

dgreensp closed this as completed in 28c760e Mar 26, 2015

benjamn removed their assignment Mar 26, 2015

too much recursion error on Firefox #3028

too much recursion error on Firefox #3028

Comments

dohomi commented Nov 6, 2014

dohomi commented Nov 13, 2014

brylie commented Dec 25, 2014

brylie commented Dec 25, 2014

brylie commented Jan 3, 2015

avital commented Jan 6, 2015

lalomartins commented Jan 12, 2015

darkship commented Jan 15, 2015

brylie commented Jan 15, 2015

brylie commented Jan 15, 2015

benjamn commented Feb 4, 2015

levino commented Feb 4, 2015

laurentpayot commented Feb 10, 2015

aldeed commented Feb 12, 2015

brylie commented Feb 12, 2015

brylie commented Feb 12, 2015

BradRyan commented Feb 16, 2015

mxab commented Feb 27, 2015

mxab commented Feb 27, 2015

dohomi commented Feb 28, 2015

lalomartins commented Feb 28, 2015

dohomi commented Mar 1, 2015

lalomartins commented Mar 1, 2015

brylie commented Mar 1, 2015

mxab commented Mar 4, 2015

mxab commented Mar 5, 2015

aldeed commented Mar 5, 2015

stbaer commented Mar 11, 2015

shtefcs commented Mar 20, 2015

lalomartins commented Mar 20, 2015

dgreensp commented Mar 26, 2015

mquandalle commented Mar 26, 2015

benjamn commented Mar 26, 2015

ripdog commented Mar 26, 2015

boustanihani commented Mar 26, 2015

aldeed commented Mar 26, 2015

avital commented Mar 28, 2015

aldeed commented Mar 30, 2015

shtefcs commented Mar 31, 2015

dohomi commented Apr 1, 2015

darkship commented Apr 1, 2015