axelson

axelson

Scenic Core Team

ElixirConf US 2018 – You Can Never Debug the Code You Run, But You Can View the Code the Debugger is Running – Luke Imhoff (@KronicDeth)

Elixir supports various ways to debug code: printing with IO.inspect, prying with IEx.pry, or using more advanced OTP tools like :debugger and :int. Choosing when to use these different tools can be confusing, and understanding how they work can prove downright intimidating.

Throughout this talk we’ll peel back the covers on the more advanced debugging techniques and dissect exactly how each debugging tool can be used to examine our compiled code. None of debugging techniques leave your code the same as how it was running in production. Adding IO and IEx.pry calls obviously changes the code as you edit the source, but using the OTP debugger, either with :debugger, IntelliJ Elixir, or Elixir Language Server, or by adding new break points from the IEx.pry shell changes the module code being run.

Luke Imhoff will show how each type of debugging changes the code by revealing how IEx.pry and :debugger are implemented. You’ll see why sometimes the debuggers can’t reproduce bugs because the modifications to make the code debuggable also subtly changes the execution of the code by looking at changes to the bytecode and AST. Although the modified code never exists as source, we can recover the Abstract Syntax Tree (AST) of either the Elixir quoted form or the Erlang Abstract Code from the Dbgi chunk, but the Dbgi chunk ASTs aren’t terribly easy to read, so we can use tools to decompile the code and translate it to Elixir or Erlang modules.

When looking at Dgbi code isn’t enough, we can drop down to the Code chunk and look at the bytecode. The bytecode is a unique binary format, so once again we reach for for tools to render it, so instead of having to read machine code, we can read assembly. Looking at this bytecode also allows us to check if our high-level optimizations, such as module attribute reuse, compute variables once, and the order of pattern matching, have an impact on the code run by the VM, as unlike Dbgi, the Code chunk is actually loaded by the VM when running code without debugging.

Audience: Intermediate, Advanced
Topics: elixir, debugging

All talks are available in the ElixirConf US 2018 Talks List or via the elixirconf2018 tag

Showing Posts 1 to 2

blatyo

blatyo

Conduit Core Team

I’m always impressed with the things he’s able to do in IntelliJ. I really enjoyed the deep dive on how the debuggers work and the BEAM bytecode.

axelson

axelson OP

Scenic Core Team

I really enjoyed this video. It was great to learn more about BEAM internals. I think I need to re-watch the video after reading the BEAM book or the BEAM wisdoms site: http://beam-wisdoms.clau.se/en/latest/

— All posts loaded —

Where Next? Top

Trending in Talks Top

Other Trending Topics Top

dominicletz
Hey there, I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first. ...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews