[Isomorphic]

Sorry about that - I somehow missed the whole second page of posts :(.

I'm not reproducing this problem, but I think there must be a version mismatch occurring here - despite the fact that you cleared the cache.

I notice that the modules referenced in your Developer Console debugger have the isc_version query param, but those in your test case do not. In theory, with a clear cache, this shouldn't matter, but I think there must be a caching layer somewhere (possibly a level 4 switch?) that is paying attention to these different URIs and possibly serving stale files.

As a sanity check, can you point your browser directly at the ISC_Core.js file - once with and once without the isc_version query param and take a look at the copyright header in that file - the version and date are right there near the top. Do they both say 10.0p 9/21/2014?

[claudiobosticco]

As a sanity check, can you point your browser directly at the ISC_Core.js file - once with and once without the isc_version query param and take a look at the copyright header in that file - the version and date are right there near the top. Do they both say 10.0p 9/21/2014?

yes, they do - both - as you could see in the attachment

but, out of curiosity, by version mismatch did you refer to a client/server mismatch? That kind of mismatch is normally logged by the server, it's one of the first things I've checked.

[claudiobosticco]

The problem is reproducible also using the online feature explorer:
1. open the URL:
http://www.smartclient.com/devcenter..._Explorer.html
2. open the developer console
3. open the browser debugger on the developer console page
4. refresh the feature explorer

tested with Chrome, Safari on Mac OSX, Chrome on Win7

you could see the sequence in this video: https://www.youtube.com/watch?v=o1x3NY--C30

[Isomorphic]

Ok, I've reproduced it on the public site with the steps you described - thanks. Will look into this right away.

Re: the version mismatch - glad you checked the server logs - and yes, we do report that in the server logs, but the situation I was imagining was a mismatch between the client version of the Developer Console and the application by way of e.g the app seeing stale versions of the SmartClient modules.

[Isomorphic]

A fix for this will be in tonight's patch build (will be dated 9/25). Please let us know how that goes! Thanks for your patience.

[claudiobosticco]

from a first test with SmartClient Version: v10.0p_2014-09-25/EVAL Deployment (expires 2014.11.24_09.18.09) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)
the problem seems still there (see attachment)

[Isomorphic]

Hmm - this problem requires a threshold amount of latency to the server to occur. I am not reproducing it with the latest build (which you do seem to be using) in an analogous setup that was definitely crashing yesterday.

Can you double check caches etc to make sure you're definitely running the latest? My retest was on the latest Chrome and Safari on OSX. Maybe you have a different config?

[claudiobosticco]

Hmm - this problem requires a threshold amount of latency to the server to occur.

Sorry, I don't understand what you mean here.

Actually in this moment I'm testing the build in my project through a VPN. Tomorrow I'll test without VPN.

Can you double check caches etc to make sure you're definitely running the latest?

yes, I am, checked by pointing the browser directly to ISC_Core and in the 'resource' section of the Safari Inspector, opener window and also developer console window

My retest was on the latest Chrome and Safari on OSX. Maybe you have a different config?

Safari Version 7.1 (9537.85.10.17.1) on OSX 10.9.5

Actually the problem seems a little less severe: it seems that after the error the developer console remains functional for RPC tracking and 'Last Mouse Target' functionality.

Actually I've asked senordhuff about his problem http://forums.smartclient.com/showthread.php?t=31335 because after the error on the developer console window, with RPC tracking active, after some refresh of the opener window, I got a 'Maximum call stack size exceeded' as in the attachment - in the opener window. So I've got to do 'Reset Safari' and restart.

[Isomorphic]

Re the statement about latency: what I meant is that the problem never occurs for me when loading pages from a fast local server. I needed to access a remote server that introduced some delay in the page load to get the issue to show up at all.

I haven't been able to reproduce the issue since the fix has gone in and I'm having trouble seeing how the exact same error can still occur with the change that went into the 9/25 build.

Still, you're seeing it, so we need to figure out what's going on. As an additional sanity check, can you please open the ISC_Core.js as loaded by your browser and search for this string:

for(var i=0;this.sockets&&i<this.sockets.length;i++){

Does your copy have this?

[claudiobosticco]

Re the statement about latency: what I meant is that the problem never occurs for me when loading pages from a fast local server. I needed to access a remote server that introduced some delay in the page load to get the issue to show up at all.

ok, now I got it

Still, you're seeing it, so we need to figure out what's going on. As an additional sanity check, can you please open the ISC_Core.js as loaded by your browser and search for this string:

for(var i=0;this.sockets&&i<this.sockets.length;i++){

Does your copy have this?

9/26 build has got it.

9/25 (which I was testing yesterday) has got this string, instead:

for(var i=0;i<this.sockets.length;i++){

[claudiobosticco]

Now i'm testing SmartClient Version: v10.0p_2014-09-26/EVAL Deployment (expires 2014.11.25_09.27.48) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)

and actually the error in the developer console window doesn't show.
So far so good.

But I've got another error.
If I open the developer console, check track RPCs, then refresh the opener window, for about a minute the developer console isn't responsive.
When I finally succeeded in switching to the dev console, in the opener window I've got a 'Maximum call stack size exceeded' error very similar to that occured to senordhuff http://forums.smartclient.com/showpo...22&postcount=1

[Error] RangeError: Maximum call stack size exceeded.
	isc_c_Class_fireCallback (ISC_Core.js, line 287)
	isc_c_Timer__fireTimeout (ISC_Core.js, line 1261)
	(funzione anonima) (ISC_Core.js, line 1259)

you could see the sequence in this video https://www.youtube.com/watch?v=j7StDyKvAeY
and please note: no RPCs shows in the developer console (and there are three or four of them)

[Isomorphic]

I am still having trouble reproducing this - can you get this to happen with any of the examples in the Feature Explorer that come with the SDK? That would be ideal as we would then have a common frame of reference...

[claudiobosticco]

Finally, I've found the culprit, in my code.

I was doing something like:

....
isc.DataSource.getDataSource("TREE_MENU").fetchData(
            criteria,
            function (response, data, request) {
                var tree = isc.Tree.create({
                    ID: "treePadreMenu",
                    parentIdField: "ID_VOCE_PADRE",
                    idField: "ID_REC",
                    modelType: "parent",
                    data: data
                });
....

simply using isc.clone(data) instead of directly 'data' solves the problem.

But with 9.1 it was working.
Is it an error to use 'data' to create the tree like in the code above?

Or is it a framework bug?
Recall that the error in the Safari Console happens only if the developer console is open and Track RPCs is enabled.

Please let me know if a standalone test case may help (I can't get this to happen in the Feature Explorer because when reloading the page it doesn't retain code modifications)

[Isomorphic]

Thanks for the effort in tracking this down. This does look like a bug related to the Remote Debugging feature.

We will investigate further and fix (hopefully in the next few days). I'll update this post once that's done.

[Isomorphic]

Thanks for your patience - this has now been fixed and will appear in the next nightly patch build (will be dated October 15th 2014).

Once you install this build, you can get rid of the isc.clone() workaround.