ChromeStackTrace issue

[Sanmargar]

MacOS Ventura 13.2.1,
Chrome 123.0.6312.86
SmartGWT 13.0
GWT 2.11

When I have developer tools enabled in browser, an error occurs with every DMI.call()
Even when this is single line application with DMI.Call() invocation, the error still occurs.



I tried disabling

RPCRequest req = new RPCRequest();
req.setAttribute("doNotTrackRPC", true);
DMI.call(GWT.getModuleName(), "com.example.app", "test",  callback, param, req);

It works in most cases except for loading the datasource, which uses DMI.Call().

I found some incorrect code that prevents passing parameters to the DMI.call function.

DataSource.load()

it is:

combinedRequestProps = isc.combineObjects(
      isc.addProperties({}, combinedRequestProps), requestProps);

isc.combineObjects method doesn't return any value, hence combinedRequestProps is always empty.

should be:

combinedRequestProps = isc.addProperties({}, combinedRequestProps);
isc.combineObjects(combinedRequestProps, requestProps);

In the end, I can call DataSource.load and apply the setting

DSLoadSettings settings = new DSLoadSettings();
RPCRequest req = new RPCRequest();
req.setAttribute("doNotTrackRPC", true);
settings.setAttribute("requestProps", req);
settings.setForceReload(true);
DataSource.load(dsID, callback, settings);

By the way, the DSLoadSettings class could have a setter to configure this parameter in a more elegant way.

[Isomorphic]

We're not seeing any issue like you mention loading DataSources in SmartGWT 13.0 on Mac OS + Chrome 123. In fact, loading DataSources via DataSource.load() in SmartClient/SmartGWT doesn't use DMIs, so we're not sure why you mention that. We do agree about the problem with isc.combineObjects() and we'll fix that.

In your screenshot it appears to report a NullPointerException arising in GWT-generated JS executed by echoLeaf() while trying to grab a stack trace, but we don't hit any similar issues while using DataSources, or running SmartGWT Showcase samples. Do you have "SmartClient Developer Console" open as well as the browser developer tools?

Can you give us a modified version of the sample project BuiltInDS or a modified SmartGWT Showcase sample that reproduces your issue? You'll need to provide instructions if we must do more than just load the sample.

[Sanmargar]

Unfortunately, despite numerous attempts, I haven't been able to precisely identify the cause of this error and create code for reproduction. The error only occurs in my larger project.
It's very possible that the size of the project is the problem itself.

It occurs regardless of whether I have the 'SmartClient Developer Console' open or not.

The issue is not in sendRequest, but in the getStackTrace method. Specifically, in that line:

"" + obj

When obj is Window and the Window contains thousands of elements.
As you can see, the error is handled here, but it only makes debugging other errors more difficult.
Probably one of the thousands (over 10,000 at the root) of elements cannot be converted to a string. Unfortunately, Object.toString is an internal method, and I don't know how to find out which one. (Any hints?)

By the way, is this not a performance issue when, with each RPC call, this very large object tries to be converted to a string and invokes all internal toString methods just to return the text [object object] in the end?

If I proceed one step further in the program, I'll be here.
name is undefined, so now the program will throw an exception.
Unfortunately, I don't see any clues about which Enum it refers to.





I'll try to write a scanner to find the faulty element, but wouldn't it still be worth removing that piece of code (""+obj) ?

[Isomorphic]

There's nothing faulty shown here: this is diagnostic code that is trying the best possible fallback to give a String representation of whatever is passed to it.

Calling toString on Window (or on any part of the DOM) normally does not produce a super-long String consisting of the entire contents of the browser. It's normally neither expensive, nor does it crash.

The last time we saw a problem where toSting() would crash, it was in Netscape Navigator 4 circa 2002 (not kidding).

The most likely scenario, given what you have shared so far, is that you have installed a faulty browser extension (possibly some kind of custom development tool). If you’ve only ever seen this error while developing and it hasn’t been reported by an end user, then that’s a strong indication that something like this is the problem.

If it’s somewhat reproducible but intermittent, you might set a breakpoint to trap the condition and wait for it happen.

Finally, you can completely ignore the idea that this would happen for large applications. SmartClient has been repeatedly used for applications with absolutely spectacularly large DOMs. That is not the problem, and can eliminated as an area to possibly investigate.

[Sanmargar]

First of all, thank you for all the feedback and it's obviously not a critical issue. The fact that I talk about such a minor detail means that other more important things in SmartGWT are working like clockwork. :)

I've checked the execution time of the code "" + window compared to window.toString(). The latter is consistently several to a thousand times faster for me. Moreover, "" + window sometimes causes an exception when one of the elements cannot be converted to text. That's why I suggested rewriting this code fragment differently.

private native JavaScriptObject concatOperatorVsToString()/*-{
         var obj = window;
         console.log('"" + obj;');
         var startTime = performance.now();
         for (var i = 0; i< 10000; i++) {
             try {
               var s = "" + obj;
             } catch (e) {}
         }
         var elapsedTime1 = performance.now() - startTime;
        console.log("Execution time: "+ elapsedTime1 + " milliseconds");
         console.log('obj.toString()');
         startTime = performance.now();
         for (var i = 0; i< 10000; i++) {
            try { //This try-catch block is not necessary in my case. I added it to make the comparison more fair.
                 var s = obj.toString();
            } catch (e) {}
         }
         var elapsedTime2 = performance.now() - startTime;
        console.log("Execution time: "+ elapsedTime2 + " milliseconds");
        console.log("done");
     }-*/;

The above method called from builtInDS sample :

"" + obj;
Execution time: 0.5 milliseconds

obj.toString()
Execution time: 0.1 milliseconds

in my Applicatioin:

"" + obj;
Execution time: 3433.39 milliseconds

obj.toString()
Execution time: 2.40 milliseconds
Chrome 124, macOS 14.4

I just noticed that you already mentioned it in the comment within this code.

[Isomorphic]

Again, it seems like you must have some kind of browser extension or third-party library installed.

The normal output of

window + ""

.. is just "[object Window]" - that's it. It takes no measurable time and never crashes, and no matter how complex the DOM is, it just returns this static String.

So you have something extra installed, it seems - perhaps a third-party library that overrides window.toString() or Object.toString()? That would explain your problem.

Also, the performance of this code isn't relevant, since it's just part of diagnostic logging and never used in an inner loop. But even if it were relevant, your test isn't actually correct because you're not taking into account how JavaScript JIT-style optimization works as well as how GWT packages JSNI. Very long story there.

Then, finally, we do ""+obj on purpose, because over the years we have seen a number of cases where an explicit call to toString() blows up with a bogus exception (mostly to with cross-frame issues) whereas ""+obj is always safe. So, even if it weren't irrelevant (which it is), and even if the benchmark were correct (it's not), we still couldn't change this code, because it's a workaround for browser bugs.

Big picture, this is very much "off in the weeds", and your original report still claims a problem with DMI.call() during DataSource loading, but DMI.call() is not used during DataSource loading. So right now, your problem report doesn't make sense - we basically have no idea what problem you're reporting.

[Sanmargar]

Thank you for suggesting that it might be an issue with the installed browser plugin. That could have made sense. However, I've checked it on a clean environment, on various browsers both on Mac and Windows. The issue occurs in all environments.

I mentioned earlier about DMI.call, because when calling this method, I had exactly the same error. Indeed, both DataSource.load and DMI.call call sendRequest. When writing the first post, I didn't pay attention to it.
I think my imprecise description at the beginning is clear, and it's also known exactly where the issue is.

Now I think it's a problem with GWT, which manifests itself when performing this specific operation ""+window. Only when the PRETY compiler option is set together with -noincremental.

repro steps:

1. cd smartgwtpower-13.1d/samples/built-in-ds

2. edit war/BuiltInDS.html
remove line 38:

 <script src="builtinds/sc/DataSourceLoader?dataSource=supplyItem,animals,employees"></script>

3. edit src/com/smartgwt/sample/client/BuiltInDS.java

add:

import com.smartgwt.client.core.Function;

rename onModuleLoad() to init()

add method:

public void onModuleLoad() {
        String[] dss = {"supplyItem","animals","employees"};
        DataSource.load(dss, new Function() {
            @Override
            public void execute() {
                init();
            }
        }, true);
    }

4.
edit build.xml

add options PRETTY and noincremental to both gwtc and hosted targets:

 <arg line="-style PRETTY"/>
      <arg value="-noincremental" />

5.
export GWT_HOME=~/libs/gwt-2.10.0 ( also tested 2.8.2, 2.9, 2.11, same result)
ant build
ant hosted

6. go to any browser, launch devtools and check [pause on caught exception] and [pause on uncaught exception]
7. go to http://127.0.0.1:8888/BuiltInDS.html

Now I can see en exception occurring during the DataSource.load function call :

at eval (eval at checkCriticalNotNull (B51CC6C0AA96010A4115787F96E19B28.cache.js:53403:5), <anonymous>:1:8)
at Object.checkCriticalNotNull (InternalPreconditions.java:404:1)
at Object.checkNotNull_0 (InternalPreconditions.java:390:1)
at valueOf (Enum.java:53:1)
at _3.isc__debug_echoLeaf [as echoLeaf] (ISC_Core.js?isc_version=13.1d_2024-04-16.js:1391:28)
at Object.isc_echoLeaf [as echoLeaf] (ISC_Core.js?isc_version=13.1d_2024-04-16.js:91:723)
at _3.isc_c_ChromeStackTrace__resolveCallSiteFunctionArguments [as $1676] (ISC_Core.js?isc_version=13.1d_2024-04-16.js:1357:20)
at _3.isc_c_ChromeStackTrace__getLastErrorCallSitesParsedStack [as $122x] (ISC_Core.js?isc_version=13.1d_2024-04-16.js:1341:2526)
at _3.isc__debug_getStackTrace [as getStackTrace] (ISC_Core.js?isc_version=13.1d_2024-04-16.js:1372:56)
at _3.isc_c_RPCManager_sendRequest [as sendRequest] (ISC_DataBinding.js?isc_version=13.1d_2024-04-16.js:1481:390)
at _3.isc_c_RPCManager_send [as send] (ISC_DataBinding.js?isc_version=13.1d_2024-04-16.js:1477:3515)
at Object.isc_c_DataSource_load [as load] (ISC_DataBinding.js?isc_version=13.1d_2024-04-16.js:287:16)
at Object.load (DataSource.java:7394:1)
at BuiltInDS.onModuleLoad_3 [as onModuleLoad] (BuiltInDS.java:57:1)


You can add also this method to BuiltInDS.java

public static native void concatStringAndWindowIssue()/*-{
         var obj = window;
             try {
               var s = "" + obj;
               $wnd.isc.say('OK!');
             }
             catch (e) {
                $wnd.isc.say(' ["" + window] issue');
             }
     }-*/;

and call it at the beginning of the onModuleLoad() method, close devTools rebuild and refresh browser.

public void onModuleLoad() {
        concatStringAndWindowIssue();

[Isomorphic]

Hmm, OK, this is what seems to be going on:

1. you're doing something that goes through RPCManager.send(), the framework tries to get a stack trace, for logging/diagnostic purposes. No error has occurred at this point - we're getting the stack trace as part of diagnostics. The particular code involved is probably related to the Track RPCs feature from the Developer Console, where you can see the call stack that initiated any given RPCRequest.

2. As part of putting together the stack trace, the frameworks creates short textual summaries of everything in the call stack - all the arguments, etc

3. in "Pretty" mode, core GWT has installed some functions on various native objects - probably the native "window" - and these functions (from InternalPreconditions.java) are faulty and will crash if someone tries to concat the native "window" object with an empty string

So, then, questions on this:

1. is this your understanding as well?

2. you said you can reproduce in "any browser" but this seems like it has to be Chrome-specific, since that's the only browser in which we use the ChromeStackTrace framework class. In particular, we would either not expect an error in Firefox, or at least, the error would have to be different (you wouldn't see the ChromeStackTrace stuff). Can you confirm this is only in Chrome?

3. you also showed some JSNI that just tries "" + window - can you confirm that this code, on its own, is sufficient to cause a crash, even if there's no use of SmartGWT? If so, we have a usable and very clear bug report for the GWT team

4. this fault GWT code might be triggered by attempts to stringify other objects - have you noticed crashes with anything other than the "window" object?

[Sanmargar]

1. Agreed. The error occurs when setting two parameters together: -noincremental and -style PRETTY.

2.
Safari. The same echoLeaf method is being utilized, finally same exception
checkCriticalNotNull — InternalPreconditions.java:432
checkNotNull_0 — InternalPreconditions.java:418
valueOf — Enum.java:55
isc__debug_echoLeaf — ISC_Core.js:1391
isc__debug_getCallTrace — ISC_Core.js:1368
isc__debug__getStackTraceFromArgs — ISC_Core.js:1382:103
isc__debug_getStackTrace — ISC_Core.js:1374
isc_c_RPCManager_sendRequest — ISC_DataBinding.js:1481:404
isc_c_RPCManager_send — ISC_DataBinding.js:1477:3527
isc_c_DataSource_load — ISC_DataBinding.js:287
load — DataSource.java:7394
onModuleLoad_3 — BuiltInDS.java:57

Firefox: the same as in Safari.

Edge on Windows: the same as Chrome

3.
Yes it is.
I noted that I now think this is a GWT issue and probably the added SmartGWT modules don't matter. If it weren't for the fact that ""+window is used at least in one place, it probably wouldn't be related to SmartGWT at all.

This requires confirmation. At least write the code without isc.say().


4. No. I've noticed the issue only in the echoLeaf method, on the line with the code "" + window.