.. _devdocs-gdb: ****************** gdb debugging tips ****************** Displaying Julia variables -------------------------- Within ``gdb``, any ``jl_value_t*`` object ``obj`` can be displayed using :: (gdb) call jl_(obj) The object will be displayed in the ``julia`` session, not in the gdb session. This is a useful way to discover the types and values of objects being manipulated by Julia's C code. Similarly, if you're debugging some of Julia's internals (e.g., ``inference.jl``), you can print ``obj`` using :: ccall(:jl_, Void, (Any,), obj) This is a good way to circumvent problems that arise from the order in which julia's output streams are initialized. Julia's flisp interpreter uses ``value_t*`` objects; these can be displayed with ``call fl_print(ios_stdout, obj)``. Useful Julia variables for Inspecting ------------------------------------- While the addresses of many variables, like singletons, can be be useful to print for many failures, there are a number of additional variables (see julia.h for a complete list) that are even more useful. - (when in ``jl_apply_generic``) ``f->linfo`` and ``jl_uncompress_ast(f->linfo, f->linfo->ast)`` :: for figuring out a bit about the call-stack - ``jl_lineno`` and ``jl_filename`` :: for figuring out what line in a test to go start debugging from (or figure out how far into a file has been parsed) - ``$1`` :: not really a variable, but still a useful shorthand for referring to the result of the last gdb command (such as ``print``) - ``jl_options`` :: sometimes useful, since it lists all of the command line options that were successfully parsed - ``jl_uv_stderr`` :: because who doesn't like to be able to interact with stdio Useful Julia functions for Inspecting those variables ----------------------------------------------------- - ``gdblookup($rip)`` :: For looking up the current function and line. (use ``$eip`` on i686 platforms) - ``jlbacktrace()`` :: For dumping the current Julia backtrace stack to stderr. Only usable after ``record_backtrace()`` has been called. - ``jl_dump_llvm_value(Value*)`` :: For invoking ``Value->dump()`` in gdb, where it doesn't work natively. For example, ``f->linfo->functionObject``, ``f->linfo->specFunctionObject``, and ``to_function(f->linfo)``. - ``Type->dump()`` :: only works in lldb. Note: add something like ``;1`` to prevent lldb from printing its prompt over the output - ``jl_eval_string("expr")`` :: for invoking side-effects to modify the current state or to lookup symbols - ``jl_typeof(jl_value_t*)`` :: for extracting the type tag of a Julia value (in gdb, call ``macro define jl_typeof jl_typeof`` first, or pick something short like ``ty`` for the first arg to define a shorthand) Inserting breakpoints for inspection from gdb --------------------------------------------- In your ``gdb`` session, set a breakpoint in ``jl_breakpoint`` like so:: (gdb) break jl_breakpoint Then within your Julia code, insert a call to ``jl_breakpoint`` by adding :: ccall(:jl_breakpoint, Void, (Any,), obj) where ``obj`` can be any variable or tuple you want to be accessible in the breakpoint. It's particularly helpful to back up to the ``jl_apply`` frame, from which you can display the arguments to a function using, e.g., :: (gdb) call jl_(args[0]) Another useful frame is ``to_function(jl_lambda_info_t *li, bool cstyle)``. The ``jl_lambda_info_t*`` argument is a struct with a reference to the final AST sent into the compiler. However, the AST at this point will usually be compressed; to view the AST, call ``jl_uncompress_ast`` and then pass the result to ``jl_``:: #2 0x00007ffff7928bf7 in to_function (li=0x2812060, cstyle=false) at codegen.cpp:584 584 abort(); (gdb) p jl_(jl_uncompress_ast(li, li.ast)) Inserting breakpoints upon certain conditions --------------------------------------------- Loading a particular file ~~~~~~~~~~~~~~~~~~~~~~~~~ Let's say the file is ``sysimg.jl``:: (gdb) break jl_load if strcmp(fname, "sysimg.jl")==0 Calling a particular method ~~~~~~~~~~~~~~~~~~~~~~~~~~~ :: (gdb) break jl_apply_generic if strcmp(F->name->name, "method_to_break")==0 Since this function is used for every call, you will make everything 1000x slower if you do this. Debugging during Julia's build process (bootstrap) -------------------------------------------------- Errors that occur during ``make`` need special handling. Julia is built in two stages, constructing ``sys0`` and ``sys.ji``. To see what commands are running at the time of failure, use ``make VERBOSE=1``. At the time of this writing, you can debug build errors during the ``sys0`` phase from the ``base`` directory using:: julia/base$ gdb --args ../usr/bin/julia-debug -C native --build ../usr/lib/julia/sys0 sysimg.jl You might need to delete all the files in ``usr/lib/julia/`` to get this to work. You can debug the ``sys.ji`` phase using:: julia/base$ gdb --args ../usr/bin/julia-debug -C native --build ../usr/lib/julia/sys -J ../usr/lib/julia/sys0.ji sysimg.jl By default, any errors will cause Julia to exit, even under gdb. To catch an error "in the act", set a breakpoint in ``jl_error`` (there are several other useful spots, for specific kinds of failures, including: ``jl_too_few_args``, ``jl_too_many_args``, and ``jl_throw``). Once an error is caught, a useful technique is to walk up the stack and examine the function by inspecting the related call to ``jl_apply``. To take a real-world example:: Breakpoint 1, jl_throw (e=0x7ffdf42de400) at task.c:802 802 { (gdb) p jl_(e) ErrorException("auto_unbox: unable to determine argument type") $2 = void (gdb) bt 10 #0 jl_throw (e=0x7ffdf42de400) at task.c:802 #1 0x00007ffff65412fe in jl_error (str=0x7ffde56be000 <_j_str267> "auto_unbox: unable to determine argument type") at builtins.c:39 #2 0x00007ffde56bd01a in julia_convert_16886 () #3 0x00007ffff6541154 in jl_apply (f=0x7ffdf367f630, args=0x7fffffffc2b0, nargs=2) at julia.h:1281 ... The most recent ``jl_apply`` is at frame #3, so we can go back there and look at the AST for the function ``julia_convert_16886``. This is the uniqued name for some method of ``convert``. ``f`` in this frame is a ``jl_function_t*``, so we can look at the type signature, if any, from the ``specTypes`` field:: (gdb) f 3 #3 0x00007ffff6541154 in jl_apply (f=0x7ffdf367f630, args=0x7fffffffc2b0, nargs=2) at julia.h:1281 1281 return f->fptr((jl_value_t*)f, args, nargs); (gdb) p f->linfo->specTypes $4 = (jl_tupletype_t *) 0x7ffdf39b1030 (gdb) p jl_( f->linfo->specTypes ) Tuple{Type{Float32}, Float64} # <-- type signature for julia_convert_16886 Then, we can look at the AST for this function:: (gdb) p jl_( jl_uncompress_ast(f->linfo, f->linfo->ast) ) Expr(:lambda, Array{Any, 1}[:#s29, :x], Array{Any, 1}[Array{Any, 1}[], Array{Any, 1}[Array{Any, 1}[:#s29, :Any, 0], Array{Any, 1}[:x, :Any, 0]], Array{Any, 1}[], 0], Expr(:body, Expr(:line, 90, :float.jl)::Any, Expr(:return, Expr(:call, :box, :Float32, Expr(:call, :fptrunc, :Float32, :x)::Any)::Any)::Any)::Any)::Any Finally, and perhaps most usefully, we can force the function to be recompiled in order to step through the codegen process. To do this, clear the cached ``functionObject`` from the ``jl_lamdbda_info_t*``:: (gdb) p f->linfo->functionObject $8 = (void *) 0x1289d070 (gdb) set f->linfo->functionObject = NULL Then, set a breakpoint somewhere useful (e.g. ``emit_function``, ``emit_expr``, ``emit_call``, etc.), and run codegen:: (gdb) p jl_compile(f) ... # your breakpoint here Mozilla's Record and Replay Framework (rr) --------------------------------------------- Julia now works out of the box with `rr, `_ the lightweight recording and deterministic debugging framework from Mozilla. This allows you to replay the trace of an execution deterministically. The replayed execution's address spaces, register contents, syscall data etc are exactly the same in every run. A recent version of ``rr`` (3.1.0 or higher) is required.