SOL Error when Saving Files

[teward]

Discovered this yesterday, and this is only a 58kB SOL file...

Uncaught RangeError: Maximum call stack size exceeded
(http://apps.coursevector.com/minerva/js/parsers/SOLWriterWorker.js:2)

[gmariani]

Doesn't really matter the size of the file, depends on how nested the objects are. People think they can make it 24523452345234 layers deep and wonder why it doesn't work. If you could attach the file you tested I can take a look at whats going on.

[teward]

is six nested layers really that huge?

I have to pull the SOL off another computer but can't for a few hours. I'll provide it here in a few hours.

[teward]

So, apparently, GitHub won't permit me to upload the SOL file.

Any other options for getting it to you?

[gmariani]

Can you put it up on dropbox or something? I'm honestly surprised GitHub doesn't allow you, Google Code never cared. If not see if you can just rename the file and I'll rename it back.

[teward]

@gmariani This is the file: [DEADLINK]

(I'm deleting it in the next 48 hours, by the way, because I have limited dropbox space, in < 1MB of space already)

[teward]

(Regarding it not being able to upload, it may be because it's a binary format...)

[gmariani]

I downloaded the file, you can recover your limited space. =)

On Wed, Sep 30, 2015 at 11:53 AM, Thomas Ward notifications@github.com
wrote:

@gmariani https://github.com/gmariani This is the file:
https://www.dropbox.com/s/pub7vudemjbah6p/TiTs_6.sol?dl=0

(I'm deleting it in the next 48 hours, by the way, because I have limited
dropbox space, in < 1MB of space already)

—
Reply to this email directly or view it on GitHub
#62 (comment).

[teward]

@gmariani done, please let me know if you can figure out why exactly it fails to be saved.

[gmariani]

Opening the file and hitting save worked (although it took a bit). Using Chrome 45.0.2454.101 m worked without error. Now, I realize my system is not like the average user (i have 32gb of ram) butI do that so I can develop without limitations. But the tab only reached 15% cpu usage and about 230-250mb of ram used. What browser are you using and what type of performance hit is it doing on your system? I've seen lots of these files from this game and it's complicated format has caused many issues over the years. Yes it's not many levels deep, but there s hundreds of items per level. For an SOL i have to track a lot of metadata per item since i'm translating between ActionScript and JavaScript so it quickly eats up memory. Let me know, thanks.

[teward]

Google Chrome, on Ubuntu 14.04. 8GB RAM in this system.

[gmariani]

Could you tell me what kind of CPU usage and ram usage you're getting when it tries to save? ALso what version of Chrome. Thanks

[teward]

Before running: PRIV: 476.6 MiB SHARED: 99.8 MiB TOTAL: 576.4 MiB
During run, peaks at 1GB total.
Right before the error: 899.1 MiB total.

CPU usage isn't trackable on a realtime basis, but not heavy according to htop.

Chrome version: Version 45.0.2454.101 (64-bit)

[teward]

Additional testing: One CPU core is pegged at 100%, but the other 3 (7 according to the CPU because of hyperthreading) are not really in use.

[teward]

Almost a year later. I think I tracked the problem down, after a long long time of stabbing things infrequently.

I dug into this a little in Chrome. The JavaScript Array for this and similar SOL files for the same application are of (approximately) a size of 83681 by the time the SOL writer gets to it. This expands to about 83681 arguments, theoretically, which Array.apply will have to handle. Chrome as of 33.0.1750.154 has a max acceptable limit of 65535 apparently, which results in the call stack being overloaded (based on http://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept/22747272#22747272)

It would appear that this is a limitation of this browser. Firefox may yield me better results, due to a larger call stack. I'll have to spin up Firebug there though to see whether that remains the case. (To Firefox Dev Edition I go!)

[teward]

_BEHOLD!_ Chrome was the cause!

Firefox's limits, as of 27.0.1 has a cap on the call stack of '262143', which is more than large enough to include this.

I think a better-caught exception error would be prudent here, but at least the core cause was NOT your application, and instead the execution environment in which it was run. Looks like someone needs to yell at Google's devs.

[gmariani]

teward,

I applaud your investigative skills! I ran into a similar issue with Chrome and it's array handling abilities: https://bugs.chromium.org/p/chromium/issues/detail?id=252492

This one was related to the Int8Arrays in the webworkers, but apparently similar issue with the Array.apply. I honestly haven't touched .minerva in some time since everyone is trying to kill Flash. I may add that try/catch sometime though. Thanks for the insight!