About Application Debugging

Debugging is the process of identifying and fixing bugs (causes of malfunctions or unintended behavior) within an application.
Kirikiri provides several debugging support features. Use these features to debug your application. This section explains how to use them.

Debug Message Output

Kirikiri provides several windows to support debugging. Please refer to the descriptions in each link for details.
Console
Displays various debug messages output by the Kirikiri system or user scripts.

Specifically, the console displays messages output by user programs using Debug.message. You can call this method anywhere in your program to display variable contents in the console and inspect them during execution.
For information on how to display messages in the console or write logs to a file, refer to "Debug-related options" in Command Line Options or the Debug class.

Debug Mode

By specifying '-debug' in the Command Line Options (enabling "Debug Mode"), you can run Kirikiri in debug mode.
In debug mode, TJS2 performance decreases, but several features useful for debugging are enabled.

Type Information Tracking
Information regarding TJS2 objects is enhanced.
When not in debug mode, for example, if you try to get information about kag.saveSystemVariables in KAG:
Console : kag.saveSystemVariables = (object)(object 0x0279E130:0x01EB0BD4)
is all you get, but when debug mode is enabled:
Console : kag.saveSystemVariables = (object)(object 0x0279E130[(function) KAGWindow.saveSystemVariables]:0x01EB0BD4[instance of class KAGWindow])
type information is obtained like this. (Of the two parts separated by ':', the first part is the object type, and the second part is the context in which the object operates).
This is an almost essential option when tracking with a debugger.
This feature (in the current version) is enabled throughout the process of converting objects to strings.
Object Leak Detection
Enables a feature that warns about objects that have not been deleted (released) upon exit.
TJS2 normally deletes created objects automatically via garbage collection, so explicit deletion instructions are not required. However, objects may remain undeleted (leak) due to bugs in plugins or Kirikiri itself, or due to circular references.
In debug mode, objects that have not been released by the time the application exits are written to the console log file.
Note that even if only a single object is not released, all objects related to it will be detected, which may result in a huge log file.

The System.exit method terminates the application in a manner close to a forced termination. Note that terminating the application with this method will cause many objects to leak and a large amount of logs to be recorded.

Note
A circular reference is a situation where A refers to B, and B refers to A.
For example, the following script creates a circular reference.
var a = %[], b = %[];
a.b = b; b.a = a;
In this situation, object a requires b, and object b requires a. Since the garbage collection method used by TJS2 (reference counting) has difficulty detecting such situations to release objects, TJS2 does not detect them. Therefore, these objects will never be deleted (you can break the circular reference by explicitly invalidating either object with the invalidate operator).

In plugins, objects may leak if reference counting is handled incorrectly. When creating a plugin and handling TJS2 objects within it, pay close attention to reference counting.

Warning for Script Execution on Objects Being Deleted
The finalize method is called when an object is deleted or invalidated.
Since the timing of object deletion in TJS2 is "unpredictable", the finalize method may be called at an odd time, leading to unexpected behavior. In debug mode, a warning is displayed in the console when the finalize method is called at such an "unstable timing"—specifically, when an object that was not invalidated is deleted by garbage collection and the finalize method is called.
The warning looks like this:

Warning: anonymous@0x016DFA7C(9)[(function) finalize]: Code is being executed on object 0x0167DD44[instance of class A] which is being deleted. The call stack at the time of this object's creation is as follows:
                     anonymous@0x016DFA7C(13)[(top level script) global]
To prevent such situations, it is recommended to explicitly invalidate objects created with new using the invalidate operator once you are finished with them.
However, for objects of classes like Array, Dictionary, or Date that do not have a finalize method, or whose finalize method does not perform actions that cause problems, explicit invalidation may not be necessary.
The above warning is displayed when an object is about to be deleted without explicit invalidation, and a TJS2 script attempts to execute within that context.
Call Stack Retrieval Feature
Allows the TJS2 function/method call stack to be retrieved from a script.
This is done using the Scripts.getTraceString method.
If there is a problem in the middle of a program and you don't know where a method was called from, you can use this method to output the call stack to the console.