[Solved: QScriptEngine::popContext() doesn't match with pushContext()] Error when loading assets

frits.vancampen

Daz Studio crashes when I try to load certain assets, such as a hair color (but it also readily crashes on other types of assets). For example hair colors of "OOT MEGA Updo 2 Hair".

I've tried `App.getAssetIOMgr().doLoad(..filepath)` and `App.getContentMgr().openFile(..filepath)` with similar results.

Is this the proper way of load this type of asset, or is there another way?

I've submitted a bug report for this issue.

frits.vancampen

I found the problem. It doesn't have to do with asset loading.

The error I got was 

QScriptEngine::popContext() doesn't match with pushContext()

In my case this was caused by calling a function wrong.

I called `Scene.findNodeByLabel()` with `undefined` instead of a string. This doesn't immediately cause a problem. But then somewhere down the road you get this QScriptEnginge error.

I can easily remidy this class of errors by setting my typechecking to be more strict. So the 'fix' is simple but it did cost me a lot of time to get to this point.

I do think it would be prudent for this bug to be fixed in Daz Studio as well. I don't know if there is any kind of argument checking happening but that would be a really good idea. A small mistake on my end shouldn't crash the application with a cryptic error message.

I hope that at the very least this post will help other people who run into this error. There might be other causes of this error but this is a good place to start.

 

PS

I also tried emptying out my asset library, even going so far as to reinstall Daz Studio (losing all my plugins :( ) but that didn't solve anyhting.

 

Richard Haseltine

Dos the applciation crash or does the script error out - it's not clear from your post. Generally if a function is called with the wrong type of parameters it will cause an error, but it is certainly important for authors to make sure their scripts do error-checking on the returns of prvious calls - if nothing else it makes trouble-shooting easier.

frits.vancampen

Hi Richard,

Thanks for taking the time to look at this.

Dos the applciation crash or does the script error out

I can't reproduce the crash anymore. I have since rebooted and reinstalled Daz Studio so perhaps that resolved that issue somehow. Daz Studio is very .. capricious.

It does log the error to the log file, but because of another bug it doesn't always 'flush' all the lines to the log file so you might not see it.

Here is a reproduction script, that will trigger the error:

 

var empty;Scene.findNodeByLabel(empty);

 

Because of the log-flushing bug you might have to run it twice to see the error.

So for me Daz Studio would either crash or become unresponsive, but that doesn't happen anymore. Now the script just 'silently' fails; there is no 'An unexpected error occured .." message.

Generally if a function is called with the wrong type of parameters it will cause an error

That was a dangerous assumption to make. It's such an ingrained assumption for me that it took me 2 days to find that this was the problem. 

but it is certainly important for authors to make sure their scripts do error-checking on the returns of prvious calls

Agreed, are there any plans from the Daz Studio team to assist in this? For instance publishing the API as a Typescript definition. A Typescript to QtScript transpiler. Integration with NPM. Good CLI/headless/unattended support. These are things that are high on my list of quality-of-life improvements, so we can leverage the full power of the modern ECMAScript ecosystem.

Richard Haseltine

Well, you are passing it the correct data (since the script is not strongly typed) -  the fact that it is null/invalid is not something that the script engine can really be expected to handle. This is why the samples generally have a lot of if ( ! check data type/validity) { return; } blocks.

As for the log, it can be flushed manually DzApp::flushLogBuffer() - http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/object_index/app_dz

frits.vancampen

Well, you are passing it the correct data (since the script is not strongly typed) -  the fact that it is null/invalid is not something that the script engine can really be expected to handle

I don't expect it to be able to handle `undefined` or `null`, but I do expect it to not crash/exit. I think throwing an invalid-argument exception is a good response. Returning `null` could also be a reasonable response. What do you think is a good response?

This is why the samples generally have a lot of if ( ! check data type/validity) { return; } blocks.

This is why I'm an advocate for using Typescript. It adds types to ECMAScript, removing the need to do runtime type-checking.

There is a small caveat here though: this works best if your interfaces are built in a type-safe way. The Daz Script API relies somewhat on polymorphism, which is a questionable choice. It necessitates `instance-of`/`classname` guards, which, in my opinion, are an anti-pattern. Another issue is that the documentation is inaccurate in it's typing. For example the documentation says that `Scene.findNodeByLabel()` returns a DzNode, but that's inaccurate, it returns `DzNode | null`. And there are many more examples like this. A first-party type definition could go a long way here.

As for the log, it can be flushed manually DzApp::flushLogBuffer()

I see. I don't like that that's necessary. I don't even think that's workable. If I throw an error my script will exit. Then I can't flush anymore, but I need to flush to see the error?

In this particular case, since the script exists abnormally, there is no hope of calling flush.

 

Are you the right person to talk to about effecting change in the Daz Studio code base, or is there someone else I should be talking to?

Richard Haseltine

I am not a developer, you should open a Technical Support ticket to make a formal feature request - though I suspect that the potential knock-ons from this one mean it is unlikely to be adopted.