Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Debugging chapter #69

Open
happi opened this issue Apr 17, 2017 · 2 comments
Open

The Debugging chapter #69

happi opened this issue Apr 17, 2017 · 2 comments
Assignees
Labels

Comments

@happi
Copy link
Owner

happi commented Apr 17, 2017

I was thinking of making turning the chapter on the debugger into a broader chapter on "Finding and Fixing Bugs"

The top level idea is:

  • Finding and Fixing Bugs
    ** In a long running 24/7 system there will always be bugs,
    or at east unwanted features. In this chapter we will look
    at different ways to find and fix bugs, without disrupting
    the running service.
    ** You want to read this chapter to learn about different ways to test code and
    about the tools and frameworks that are available for testing.
    This chapter will also cover some common sources of bugs and problems
    in the system, such as deadlocks, message overflow, and memory
    problems, and how to identify and fix them.
    ** You will learn about the "let it crash" principle and how to
    best use it in your system. You will also learn how exceptions
    works and how to design your system with supervisor trees.
    You will learn how to use the debugger to debug your program
    and how to use GDB to debug the runtime system.
    You will learn how to read crash dumps, you will learn
    why you often don't get crash dumps and what to do about it.
    You will learn how the Erlang debugger works.
    You will learn how redbug can make debugging easier and
    somewhat safer to run on a live system.
    You will learn a little bit about how to use gdb
    to debug on the ERTS level.
    You will also learn a little about dtrace and systemtap.
    And maybe, perhaps, you will pick up some debugging philosophy.
    ** You will be able to test your system in a systematic way,
    and you will be able to test individual components of your system.
    You will be able to identify some common mistakes and problems.
    You will be able to use the debugger.

Suggested outline:

Testing

Eunit

Common Test

Mocking

The Usual Suspects

Deadlocks

Mailboxes

Binaries

Let it Crash

Exceptions

Supervisors

The Debugger

The Erlang debugger dbg

redbug

starting, stopping

choosing what to debug

setting limits.

Crash Dumps

Debugging the Runtime

gdb

gdb macros

systemtap and dtrace

@KronicDeth
Copy link
Contributor

@happi would you be OK with me adding how to use IntelliJ Elixir for debugging since I create IntelliJ Elixir and it has a graphical debugger?

@happi
Copy link
Owner Author

happi commented Aug 12, 2018

That would be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants