Maximum call stack size exceeded on Chrome + Windows

[zelite]

When clicking links on the left column (sideNav), nothing happens on the page.

On the browser console there's a message about:

Uncaught RangeError: Maximum call stack size exceeded

I would expect when clicking on, e.g.: "Agile", that the content of the page would change to show me some info about that topic.

I'm using the Chrome browser on windows.

[shovanch]

I can confirm it. Clicking link not working.
Using Chrome on Windows 10.

[Bouncey]

@systimotic do you get it on windows too?

[systimotic]

@Bouncey Absolutely. This is the issue we've been talking about on Gitter for a while, the one that I mentioned we should resolve before launching 😅 In development, it doesn't render at all because of this issue, and on build, it doesn't run any of the Javascript. This issue is specific to Chrome on Windows.

[quantuumsnot]

I can confirm that also (Chrome version 61.0.3163.100 (Official Build) (64-bit)), but found that on SRWare Iron (Portable ver, Chrome based browser) with version 55.0.2900.1 the guide navigation works with the same extensions!

[RubberDuckDestroyer]

@Bouncey I agree with @systimotic . The issue doesn't exist on Chrome's Android app and Firefox though

[Bouncey]

@systimotic can you replace the render method of SideNav with this and try it out?

I cannot reproduce this issue

render() {
  const { expandedState, pages, parents } = this.props;
  const panels = renderPanels(parents, pages.slice(0, Math.floor(pages.length / 2)));
  return (
    <div className='sideNav' id='side-nav'>
      <PanelGroup>
        {
          (!parents || !expandedState) ?
          <NavPanel title={'No Parents Here'}/> :
          panels
        }
      </PanelGroup>
    </div>
  );
}

[Bouncey]

Or anyone that is on windows, is experiencing this issue and is confident with react ☝️

[karuppiah7890]

@Bouncey I am experiencing this on Chrome in Linux (Ubuntu)

[Bouncey]

Hmmmm could it be a memory thing?

Could everyone please comment with your RAM size?

Many thanks

[shovanch]

Using Windows 10. RAM size = 4GB

[raisedadead]

On it.

[zelite]

I have 8Gb on Windows 10.

[Bouncey]

Oh, not a memory issue then 👍

[m-henderson]

anyone else getting a solid white screen when running locally ?

[victorferreira]

I also got 8GB of memory on Win10 and I'm having the issue.

[m-henderson]

@raisedadead you getting anywhere with this one ? I have looked through every peace of code and can't find the error.

[raisedadead]

This may not be a codebase issue.

Okay, so this works fine in Chrome Canary on Windows which is build 63.0.xxxx.x and is broken on Chrome Stable on Windows which is build 61.0.3163.100

I am doing a system update on a Windows machine, so I will get back with more details.

This could be a corner case where we might have found a bug in Chrome that is breaking our render requirements (with such large data set).

Other than that this does mean that it will be auto-fixed in Chrome's next updates.

[raisedadead]

Other than that there is no issue on macOS/Windows or another browser Combination for that matter.

I ran a memory profiling test on Chrome and we peak at about 40 MB which seems okay too.

[m-henderson]

@raisedadead could we submit the bug here ?

[raisedadead]

@m-henderson we could, I would personally wait for being sure that this is not a codebase issue.

[m-henderson]

@raisedadead good idea.

[systimotic]

Hi everyone! I have a lot of info about this bug, and I think I found the cause:

1. A bit more info about what how this bug shows itself. In development mode, everything is loaded with Javascript. Because the Javascript errors out, you only see a white page. In production, the page is pre-rendered, so you will see the initial page. However, the Javascript errors out, so you won't be able to navigate.
2. This is not a memory related issue. It think it's very likely to be related to different maximum call stack sizes across platforms, but I haven't been able to test this yet. Please ping me on Gitter if you'd like to help out with this.
3. @Bouncey's suggested solution did not work, but he's on the right track.
4. @Esslamb was instrumental in finding the source of this issue. He mentioned on Gitter that commenting out this line took away the error, but it still showed a white screen. I had previously done some profiling tests that showed a lot of React lifecycle methods, and @Esslamb's findings made me realise what was going on.

First of all, here are my findings as to what the maximum call stack size is across browser (testing method from Axel Rauschmayer):

• Windows/Firefox: 12383
• Windows/Chrome: 8973
• Windows/Edge: (can't test in a blank tab, can't get accurate result)

This seems to change with how much memory the tab is already consuming. As you can see, the limit in Chrome is quite a bit lower than in Firefox, which would explain why this ceiling is hit only in Chrome. I;d like to see what the results are on Mac/Chrome or Linux/Chrome.

It seems Gatsby mounts every single article as its own component on page load. My suspicions were confirmed by running a test with the exact same code, but only the Bootstrap articles, without any other articles, and using the original navdata.json, so the navigation was still the same. It ran fine.

Summary

Gatsby creates a component for every single article. Chrome on Windows can't handle this many components being mounted.

Next steps

This error did not exist in older version of Gatsby. My next step is going through older versions that I can get to run and not have this issue. This would be a quick fix. Once that is working, I'll go over to the Gatsby repo to see what can be done about this to fix the recent versions.

---

Sorry for the gigantic and messy post, I had a lot of information I wanted to get out as soon as I could.

[Bouncey]

@systimotic Brilliant thank you!!

gatsby@1.6.6 was our previous version

[Bouncey]

Call stack size in chrome/ubuntu is 8983

[systimotic]

@raisedadead I hadn't seen your comments yet when submitting mine. That's good news, but also really weird 😕
@Bouncey Huh, that's really close. Maybe it decreases faster on Windows? Might also indicate that this is indeed a browser bug as @raisedadead suggested.

[systimotic]

Older versions of Gatsby are showing this error on run (build and dev):

A local install of Gatsby exists but failed to load.
{ Error: Cannot find module 'relay-compiler/lib/RelayCompilerContext'
    at Function.Module._resolveFilename (module.js:489:15)
    at Function.Module._load (module.js:439:25)
    at Module.require (module.js:517:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\Users\Timo\dev\guides\node_modules\gatsby\dist\internal-plugins\query-runner\query-compiler.js:53:29)
    at Module._compile (module.js:573:30)
    at Object.Module._extensions..js (module.js:584:10)
    at Module.load (module.js:507:32)
    at tryModuleLoad (module.js:470:12)
    at Function.Module._load (module.js:462:3)
    at Module.require (module.js:517:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\Users\Timo\dev\guides\node_modules\gatsby\dist\internal-plugins\query-runner\query-watcher.js:36:21)
    at Module._compile (module.js:573:30)
    at Object.Module._extensions..js (module.js:584:10)
    at Module.load (module.js:507:32) code: 'MODULE_NOT_FOUND' }

The latest version throws the by now well-known out-of-memory issue, and gets stuck on the GraphQL queries when I give it more memory.
Does anybody have suggestions on how I can get 1.6.6 to run again? @Bouncey

Edit: so close! I got past that issue, but now having more GraphQL issues. Edit of the edit: those new GraphQL issues are caused by the way I'm trying to get around the original issue. Suggestions are still welcome.

[Bouncey]

I am currently refactoring SideNav to reduce function calls

[systimotic]

@Bouncey Cool 👍 I'm not sure if it'll help though. If I completely remove the SideNav component, I still get the same error

[Bouncey]

Oh...

yes, I read this wrong

It seems Gatsby mounts every single article as its own component on page load. My suspicions were confirmed by running a test with the exact same code, but only the Bootstrap articles, without any other articles, and using the original navdata.json, so the navigation was still the same. It ran fine.

Although I don't understand how you had the nav the same but only had the bootstrap articles?

[m-henderson]

have we looked at all of the recent merged pull request to see if something conflicted there ? When is the last time you guys remember it working on chrome ?

[systimotic]

@Bouncey That's understandable, I made quite a mess there 😅
I created a test-pages directory and copied the Bootstrap directory to it. I changed the gatsby-config to use the test-pages directory as the file source. I didn't change the seed/ folder, so it still generated everything based on the actual pages folder

[systimotic]

@m-henderson The issue was first reported here on Gitter. We've had a similar issue before (gatsbyjs/gatsby#1979), but I believe I recall seeing that in Firefox as well, and @Bouncey had the issue there in Ubuntu/Chrome too. It doesn't show up in either of them anymore. We do have a report of someone who can reproduce this on Ubuntu still, but using an older version of Chrome.

[Bouncey]

Does anybody have suggestions on how I can get 1.6.6 to run again?

All I did was yarn add gatsby@1.6.6

I have it running on 1.6.6

[systimotic]

@Bouncey I don't know what happened, but after three tries, some messing with other modules, rm -rf node_modules, reinstalling, it appears to be working normally. I opened a PR #307

[QuincyLarson]

@Bouncey @systimotic Awesome! Thanks for pushing the hotfix. Have you reached out to the Gatsby team yet? Do you think this is something they can fix on their end?

[systimotic]

We reported it, but it hasn't gotten any attention yet.

[Bouncey]

Just to further this

Firefox Quantum has a frame limit of 5712 on Ubuntu
Where chrome has a limit of 12578

Which make no sense. Chrome still refuses to render anything, but firefox doesn't even blink and carries on as expected

[quantuumsnot]

Can someone check what is the actual call stack limit per browser tab while some other active tabs demand more run-time active handles/threads? Is it possible that freeCodeCamps engine stalls when more resource hungry tab(s) kicks in?