Maximum call stack size exceeded #692
Comments
|
Pardon I can't give more information than that. It's either an issue of not pulling/pushing with git properly or it really doesn't like my collections I'm using here: https://github.com/MassDistributionMedia/arkivum.docpad/blob/master/docpad.coffee#L79 |
|
I had the same error message a couple of days ago but it was appearing just after docpad reported "Shutting down... cya next time!" (during a "docpad generate") I believe this may of been because one of my plugins wasn't calling next() at the right time during the renderAfter event. I'm not sure if this has fixed the problem because it was intermittently happening but I haven't seen it come back since so I guess time will tell. |
|
Hey @pflannery, thanks for your instance of the issue. |
|
Seems if I make minor changes to the files that use the new collections, save, and then |
|
Actually these files have to be modified and saved over every time a change is made to any other file so this is a rather crippling issue in my instance. |
|
I get the "stack size exceeded" error with your repo and found that if I make the default.html.eco layout blank the error goes away. So i put the default.html.eco back to its original state and then put a try catch in to the eco-plugin.js file (in node_modules) and this is what it spat out I've not yet looked at the reason why these duplicate messages are happening but it seems this is why docpad is quitting with the "stack size exceeded".. |
|
I've found that this Item Duplicate message is thrown by the method called @generateMenu in the partial called left-sidebar.html.eco...that method itself is from the docpad-plugin-menu... |
|
last but not least, this is the line of code that is blowing up docpad's asynchronous rendering - https://github.com/sergeche/docpad-plugin-menu/blob/master/src/menu.plugin.coffee#L45 It seems that the throw command is killing docpad without letting it know first... I believe it maybe better for this plugin to bubble the error up to docpad so it can quit the asynchronous render call stack, clean up resources and display the error it generated (would have to confirm this with Mr @balupton ) |
|
I'd raise it with the author, seems that the purpose there is to just not add duplicate menu entries, in which case that throw should just be a break. No need to throw if a duplicate is found, just don't add it. @sergeche can you look into this? |
|
Out of curiosity Is their a way to bubble up exceptions during render from inside a template. For instance if someone is using docpad generate during deployment and they detect an eco sidebar has an issue can we tell docpad to spit out a message, halt processing and fail the build? In this current case the build would fail but we don't know why it failed on the other hand we could instead write out a duplicate item message for each failure but the build wouldn't fail and docpad would generate missing content leaving us to manually determine something went wrong. |
|
I'm getting this too on the bevry website all of a sudden... |
|
Try this: |
|
The debug stops and the node error outputs at the Which the file is not seemingly unique: |
|
DocPad.org doesn't use the menu plugin so what's your debug telling you @balupton? |
|
Just had access to a variable of an undefined object. Fixing that fixed the maximum call stack size exceeded. |
|
@balupton, Good to hear. @pflannery, any top-of-the-hat ideas on how to patch menu? |
|
Encountered this again. Running in Node v0.8.26 instead of v0.10.21 gave a more useful error message. Perhaps that will help. |
|
I believe you could utilize the add event in your left_sidebar_menu collection code and then make sure that each url is unique something like this (i've not tried this code) |
|
Thanks @pflannery for the lead. I'll work with this today. @balupton, if the error is showing again for another issue, maybe it's also something to do with DocPad@6.54.1 which is when it seems to have started showing up (Is this when it first showed for you too @pflannery?). It's good that this is telling use to debug and fix things but having DocPad send out a message as @pflannery was saying giving us more information about the issue as well as stepping around it may be the way to go. |
|
first time I saw this was in v6.53.4 |
|
Yes. Having a message caught is the ideal. Node 0.8 catches the message successfully, but for some reason Node 0.10 doesn't. I'll be looking into this more tomorrow. |
|
Just thought I'd chime in here to mention that there seem to be a couple of other scenarios that also cause the (With a line break in there) And When |
|
Yeah "Maximum call stack size exceeded." seems to happen with any unhandled error.. |
|
I made this change to taskgroup recently, however I don't see any change there that could cause such an issue: |
|
From stepping through the code with node-inspector, it seems to be cyclically handling then re-emitting the error event in the taskgroup module. Specifically https://github.com/bevry/taskgroup/blob/master/src/lib/taskgroup.coffee In my test, it was in the TaskGroup constructor, and in the bubbleEvents code for addTask and addItem. My test used the 3.2.4 version of taskgroup though. You changed some of that in 3.3.0, so I'll see if it's fixed. |
|
Is it possible for you to add a test case that reproduces the issue within taskgroup? That would be sweet! From there, we can work together on fixing the issue. |
|
This tiny docpad project recreates the error - https://github.com/pflannery/docpad-callstack-err The error occurs in the "docpad\node_modules\event-emitter-grouped\node_modules\taskGroup@3.2.4" It seems to be repeatedly going through these steps: |
|
Sweet thanks. Will look into it tomorrow. In say 12 hours. By all means, keep looking into it in the meantime. TraceGL or Webkit Inspector should help. |
|
So far I see that when this me.emit('error', err) is called the me._events object doesn't contain an "error" function so this causes events.js to throw an error which in turn causes the uncaughtExceptionCallback to fire again thus the loop... so if we give TaskGroup an "error" event it should stop this loop. |
|
Was able to finally reproduce this today, looking into it now: |
|
Making good progress. |
|
Got the fix ready, but the jade plugin is failing with the changes. Debugging. |
|
Will pick this up tomorrow, got late here. Pushed my changes up to the issue-692 branch. If someone would like to debug the failing tests of the jade plugin, that would be great. |
|
Fix released to DocPad v6.54.5. Thanks everyone for your assistance and help on this! Great team effort! :) Be sure to run |
|
👍 |
|
Cheers! 👍 |
|
I haven't managed to come up with a simple test case yet using only taskgroup. Since you seem to have this issue figured out already, I won't look into it anymore. |
|
The crux of the issue was in two parts:
|
|
@balupton you mentioned Webkit Inspector, how are you using this with nodejs? is it via the webkit-devtools-agent? I cant seem to connect when trying to run this. |
I introduced multiple collections that use the findAll $exists and then this error came around. Our local DocPad projects get past the error sometimes but then whenever anyone new pulls down from git the issue emerges again. The project in question:
https://github.com/MassDistributionMedia/arkivum.docpad
Running Node@0.10.21 and DocPad@6.54.2
(The node error was seen in node@0.10.7 as well)
The text was updated successfully, but these errors were encountered: