About debugging applications

　Debugging is the work of identifying and fixing bugs (causes of malfunction or unexpected behavior) in an application.
　Kirikiri has several debugging support functions, and I will debug applications using those functions. Here's how.

Debug message output

Kirikiri provides several windows to help with debugging. See the description of each link for details.
console
You can display various debugging messages output by the Kirikiri system and user scripts.

　Especially on the console, Debug.message displays the message output by the user program in the program. You can call methods anywhere in the program, display the contents of variables on the console, and see the contents of running variables.
　For details on how to display messages on the console and how to write logs to a file, see "Debug-related Options" in Command line options and Debug class.

Debug mode

　If you specify '-debug' with Command line options ("Enable" the "debug mode"), you can run Kirikiri in debug mode.
　In debug mode, TJS2 runs slowly, but some features useful for debugging are enabled.

Type information tracking function
　Information about TJS2 objects is enhanced.
　If you are not in debug mode, try to get information on kag.saveSystemVariables with KAG, for example.
Console: kag.saveSystemVariables = (object)(object 0x0279E130:0x01EB0BD4)
　But only if debug mode is enabled
Console: kag.saveSystemVariables = (object)(object 0x0279E130[(function) KAGWindow.saveSystemVariables]:0x01EB0BD4[instance of class KAGWindow])
　You can get the type information as follows. (Of the two parts separated by ':', the first part is the type of the object, and the last part is the context in which the object operates).
　This is almost a required option when using a debugger.
　This feature is enabled everywhere (in the current version) an object is converted to a string.
Object leak detection function
　Enables a function to warn on termination of objects that have not been deleted (not released).
　Originally, created objects are automatically deleted by the garbage collection function in TJS2, and there is no need to explicitly specify the deletion. However, due to bugs in plugins, the Kirikiri core, and circular references, objects may be left undeleted (leaked).
　In debug mode, objects that have not yet been freed at the end are written to the console log file.
　Note that even if only one object is not released, the log file can be huge because all objects related to that object are detected.

　Note that the System.exit method terminates the application in a manner similar to a forced termination. Terminating the application with this method will result in many objects leaking and a large amount of logging.

Note
A circular reference is a situation where A refers to B, and B refers to A.
For example, the following script generates a circular reference.
var a = %[], b = %[];
a.b = b; b.a = a;
In such a situation, object a needs b and object b needs a. TJS2 does not detect such situations because the garbage collection method (reference counter) employed by TJS2 is difficult to detect and release objects. Therefore, these objects will not be deleted indefinitely (you can break circular references by explicitly invalidating either object with the invalidate operator).

Plug-ins can leak objects if mishandled reference counters. When creating a plug-in and handling TJS2 objects in it, be very careful with reference counters.

Script execution warning on object being deleted
　When an object is deleted or invalidated, its finalize method is called.
　In TJS2, the timing of deleting an object is "I don't know when", so the finalize method is called at an odd timing and may exhibit unexpected behavior. In debug mode, these "unstable timings", i.e. objects that have not been invalidated, are removed by garbage collection and a warning is displayed on the console when the finalize method is called.
　The warning is as follows:

Warning: Function anonymous@0x016DFA7C(9)[(function) finalize] running on object 0x0167DD44[instance of class A] being deleted. The call stack when creating this object is as follows:
                     anonymous@0x016DFA7C(13)[(top level script) global]
　To avoid this situation, it is recommended that objects created with new be explicitly invalidated with the invalidate operator after use.
　However, it may not be necessary to explicitly invalidate objects of classes that do not have a finalize method, such as Array, Dictionary, and Date, or that do not behave in the finalize method.
　The above warning appears when an object is being deleted without explicit invalidation and a TJS2 script is being executed in that context.
Call history acquisition function
　Function / method call history of TJS2 can be obtained from script.
　This is done using the Scripts.getTraceString method.
　If you have a problem in the middle of a program and you don't know where the method was called from, you can use this method to print the call stack to the console.