GDB Debugging Tips

In 'gdb`, any object (obj) jl_value_t* can be displayed as follows.

The object will be displayed in the julia session, not in the gdb session. This is a good way to determine the types and values of objects that are manipulated by Julia’s C code.

In addition, if you are debugging some internal Julia components (for example, compiler.jl), you can output an object (obj) using the function

This is the best option to work around problems that arise due to the initialization order of julia output streams.

The flisp interpreter in Julia uses value_t objects. They can be displayed using `call fl_print(fl_ctx, ios_stdout, obj)'.

Although outputting the addresses of many variables, such as single instances, can be useful for many failures, there are a number of additional variables (for a full list, see the description of julia.h) that are even more relevant.

In the gdb session, set the breakpoint in the jl_breakpoint function as follows.

Then, in Julia’s code, insert a call to the jl_breakpoint function by adding:

obj can be any variable or tuple that should be available at the breakpoint.

It is especially useful to return to the jl_apply frame, from which you can display arguments for a function, for example as follows.

Another useful frame is to_function(jl_method_instance_t li, bool cstyle)'. The `jl_method_instance_t argument is a structure with a reference to the final AST tree sent to the compiler. However, the AST is usually compressed at this stage. To view the AST, call jl_uncompress_ast' and then pass the result to `jl_.

Several signals are required for Julia to function correctly. The profiler uses SIGUSR2 for sampling, and the garbage collector uses SIGSEGV for thread synchronization. If you are debugging code that is used by a profiler or several threads, you can allow the debugger to ignore these signals, since they can be activated very often during normal operation. To do this, GDB uses the following command (replace SIGSEGV with SIGUSR2 or other signals that need to be ignored).

The corresponding LLDB command (executed after the process is started) is the following.

If you are debugging an emergency with streaming code, you can set a breakpoint in jl_critical_error (sigdie_handler should also work on Linux and BSD) to intercept only the actual emergency, and not the synchronization points of the garbage collector.

Errors that occur during the build (make) require special handling. Julia is built in two stages with the construction of sys0 and `sys.ji'. To see which commands were running at the time of the crash, use `make VERBOSE=1'.

At the time of writing this document, you can debug build errors at the sys0 stage from the base directory as follows.

You may need to delete all the files in usr/lib/julia/ to make this work.

You can debug 'sys.ji` as follows.

By default, any errors cause Julia to shut down, even in gdb. To catch an error in the process, set a breakpoint to jl_error (there are several more useful breakpoints for specific types of failures, including jl_too_few_args, jl_too_many_args and `jl_throw').

After catching the error, it is recommended to go up the stack and examine the function by checking the associated function call jl_apply. Let’s give a real example.

The last function jl_apply' is in frame 3, so we can go back there and look at the AST for the function `julia_convert_16886'. This is the unique name of some conversion method (`convert'). The `f in this frame is a function of jl_function_t*, so you can view the type signature, if any, from the `specTypes' field.

Then we can look at the AST for this function.

Finally, you can perform a forced recompilation of the function to go through the code generation process. To do this, clear the cached object functionObject from jl_lamdbda_info_t*.

Then set the breakpoint in the right place (for example, emit_function, emit_expr, emit_call, etc.) and start code generation.

Precompiling a module generates a separate Julia process for precompiling each module. To set a breakpoint or track failures in the pre-compilation work role, you need to connect a debugger. The simplest approach is to set up a debugger to monitor the launch of new processes matching a given name. For example:

or:

Then run the script or command to run the pre-compilation. As described earlier, use conditional breakpoints in the parent process to intercept certain file upload events and narrow the debugging window. (Some operating systems may require alternative approaches, such as following each branch (fork) from the parent process.)

Julia is currently working directly with https://rr-project.org /[rr], Mozilla’s simplified recording and deterministic debugging platform. This allows you to deterministically reproduce the execution trace. The address spaces, register contents, system call data, etc. of the reproduced execution are exactly the same in each run.

The latest version of rr is required (3.1.0 or higher).