ScriptEase ISDK Newsletter

In This Issue

Dr. Scripter describes debugging tool to analyze internal state of the SE:ISDK/C engine.

Errata for 4.30d release.

Other Newsletters

DevSpace Developer Support

For more information and resources, visit ScriptEase: ISDK DevSpace online.

Download Center

For latest updates and extensions, visit the ISDK Download Center.


	Help from JSE_COLLECT_AND_ANALYZE An in-depth debugging tool for tracking locked memory and objects

		In this month's Dr. Scripter, we discuss a tool for analyzing the internal state of the ScriptEase engine, its use of memory, and the hierarchy of locks on all objects and variables. This is an extremely useful tool when an application is not freeing variables as expected, or is growing in its use of memory. Calling JSE_COLLECT_AND_ANALYZE When compiling without NDEBUG defined an additional option is available to the jseGarbageCollect call, which can be called like this: jseGarbageCollect(jsecontext,JSE_COLLECT_AND_ANALYZE) When this jseGarbageCollect() is called, the ScriptEase engine will first run a garbage collection, and then step through all objects and variables again, in the same way the garbage collector would, while printing lots of data to your debug log file (e.g. c:\jsedebug.log on WIN32; see srcmisc/dbgprntf.c for the location of the debug log file on other systems). This debug log can can now be examined to learn nearly everything about the state of the ScriptEase engine, and your script, at that moment. Sections of the jse debug log file memory use: This section provides a quick summary of memory used by variables before and after garbage collection. From this section you can get a quick overview of how much memory is used overall. String Table: This section shows all of the strings that are used as variable names and properties. If a name is still in this section, and you don't think that your script should still be using that name, then some variable is still locked on to that string. OBJECT TREE: The section between "BEGIN OBJECT TREE" and "END OBJECT TREE" is the bulk of the debug log file. Indented beneath each object that the garbage collector would visit are all of the properties of that object, and indicators of whether that object can be found via another path. Help from JSE_COLLECT_AND_ANALYZE output I have found that JSE_COLLECT_AND_ANALYZE output is most useful when an implementation an script is using more memory than you expect, or is not releasing some resource when you expect it to (e.g., you expect the delete method of an object to be called but it is not). By looking through the OBJECT TREE you can look for objects that you don't expect to still be there, see were in the path of garbage collection that object is still locked, and from there get clues for implementation errors. The most common place for objects to be locked in, when you expect them to be garbage collected, is when API vars have not been destroyed. So look for the "API VARS" section to find listing of such variables. Another common way that variables are locked is when globals are switched and the old global is still around. How can we improve JSE_COLLECT_AND_ANALYZE? We know how valuable your time is when debugging your application. And with a language that can be as rich and complex as ECMAScript, combined with your own applications and object models, that debugging can become a nightmare. This is why we created the JSE_COLLECT_AND_ANALYZE tool, and we hope you find it useful. This is just the second pass at this internal analysis tool. What additional information should appear in this output file? What other tools should we add to your development arsenal? We appreciate any suggestion you can give for making this and other tools more valuable. Have a question about how to use ScriptEase:ISDK? Let Dr. Scripter know at nombas.

4.30d and earlier versions Error with continue in do/while loop: "continue" statement, when used in a do/while loop, is skipping the while statement and always going to the top of the loop. This bug and a fix are described at continue_do_while_bug on the errata web site. locale not supported by Date object: The Date treats toLocale function the same as the standard string functions (e.g., toLocaleString==toString). If you need special handling of the toLocale function on the date object read the Date toLocale description and fix on the errata web site. Memory not free when string.replace fails: When the string.replace encounters an invalid regular expression and (correctly) reports an error, there is a jseVariable that remains unfreed. This bug and a fix are described at string.replace unfreed variable on the errata web site. Date object TimeZone calculations incorrect and inefficient: The time-zone calculations are inefficient, and on at least one Solaris system have been incorrect. This problem and a fix are described at Date object TimeZone on the errata web site. Further support for browser-style HTML comments: HTML browsers support more comment styles than standard ECMAScript. With JSE_HTML_COMMENT_STYLE defined the SE:ISDK engine has long recognized the "<!--" style comment. With the changes described on the JSE_HTML_COMMENT_STYLE too strict link on the errata page, the compiler will now recognizes "-->" as an end-comment. string.lastIndexOf incorrect for offset < 0: If the second parameter (offset) to string.lastIndexOf is negative the interpreter should default to zero, but is instead defaulting to -1. This bug and a fix are described at string.lastIndexOf invalid negative link on the errata web site. string.replace always converting to regular expression: String.prototype.replace() is always converting the first argument to a regular expression. This is not correct. It should convert to a string on any parameter that is not already a regular expression object. This bug and a fix are described at string.replace always RegExp link on the errata web site.