Maximum Call Stack Exceeded When Destroying a nested model

[daffl]

As reported by @thecountofzero here issue #324 doesn't seem to be completely fixed. Demos:

http://jsfiddle.net/thecountofzero/a2b3S/
http://jsfiddle.net/thecountofzero/8KX4N/7/

Here is the post on the forum:

http://forum.javascriptmvc.com/#Topic/32525000001308005

[andykant]

This seems to be an issue with the can.Observe attributes serialize method conflicting with can.Observe.List's serialize method. When attributes get serialized, they're checked against a stack of already serialized observes to prevent infinite loops, but can.Observe.List.prototype.serialize seems to bypass this.

[daffl]

Wouldn't this just be solvable by using the same stack?

[andykant]

Yeah, I think this could be easily fixed simply by having can/observe/attributes also override can.Observe.List.prototype.serialize in addition to can.Observe.prototype.serialize. I don't have time at the moment to take care of this but I'll fix it soon.

[daffl]

I guess I can give it a shot, too if I have time.

[daffl]

Odd, now I'm not getting an error in the Fiddles. Could possibly be related with the fact that I forgot to update the release folder with 1.1.7 and only did it a week or two ago. Or am I missing something @thecountofzero?

[thecountofzero]

@daffl, Which fiddle?

When I use the following fiddle:

http://jsfiddle.net/thecountofzero/a2b3S/

And then enter v.destroy() in the console I get the "RangeError: Maximum call stack size exceeded"

[andykant]

It's reproducible with this fiddle: http://jsfiddle.net/a2b3S/5/

[thecountofzero]

Are you saying doing something like this in attributes.js ?

can.Observe.prototype.serialize = can.Observe.List.prototype.serialize = function(attrName, stack) {

[thecountofzero]

If I enter "can.Observe.List.prototype.serialize = can.Observe.prototype.serialize" in the console of the fiddle, it no longer throws the error.

[daffl]

I just tried that, too and it seems to work: http://jsfiddle.net/a2b3S/6/
Could you maybe verify that it also destroys properly?

[andykant]

Yeah, that should fix it, but like you mentioned, need to verify that it destroys properly as well as serializes lists properly.

[justinbmeyer]

Anyway someone can reduce this to something I can add as a test?

[thecountofzero]

Try typing "v.attr()" in the console. This will generate the maximum callstack error even with the above proposed fix

[daffl]

Is this fixed in 2.0.0-pre?

[daffl]

Closing this. Please reopen if it is still happening in the current release (2.0.2).

[thecountofzero]

This issue has resurfaced in 2.0.3 (or earlier).

Help me Obi-bitovi...

[thecountofzero]

This should be re-opened

[justinbmeyer]

@thecountofzero if you can reduce those fiddles into something testable by Monday of next week, I'll fix it. Thanks!

[thecountofzero]

See my comments on the forum. I reduced it a bit, but not much. Globals are needed for associations (attributes plugin) and the rest is the bare minimum to exhibit the issue.

[thecountofzero]

@justinbmeyer here is a reduced fiddle.

http://jsfiddle.net/thecountofzero/JTa2M/

[scorphus]

I'm digging this one too, and in the meanwhile I found out something at least interesting. I'm not sure as to how this adds for the discussion, but anyway, If one deferred FOO is resolved after another BAR, FOO just gets serialized and BAR makes the exception to be thrown. See http://jsfiddle.net/scorphus/ARTQ5/ for a brief demo. Hope it helps.

[justinbmeyer]

It's possible to use attributes / converters without adding to the window.

[daffl]

The interesting thing is that it worked when just passing the instances but the stack overflow happens when it is on the window using the string notation (Game.model, Game.models).

[justinbmeyer]

@thecountofzero checkout that last commit that shows how to avoid globals and use attributes.