Movatterモバイル変換


[0]ホーム

URL:


Skip to main content
More atrubyonrails.org:

Debugging Rails Applications

This guide introduces techniques for debugging Ruby on Rails applications.

After reading this guide, you will know:

  • The purpose of debugging.
  • How to track down problems and issues in your application that your tests aren't identifying.
  • The different ways of debugging.
  • How to analyze the stack trace.

1. View Helpers for Debugging

One common task is to inspect the contents of a variable. Rails provides three different ways to do this:

  • debug
  • to_yaml
  • inspect

1.1.debug

Thedebug helper will return a <pre> tag that renders the object using the YAML format. This will generate human-readable data from any object. For example, if you have this code in a view:

<%=debug@article%><p><b>Title:</b><%=@article.title%></p>

You'll see something like this:

---!ruby/objectArticleattributes:updated_at:2008-09-05 22:55:47body:It's a very helpful guide for debugging your Rails app.title:Rails debugging guidepublished:tid:"1"created_at:2008-09-05 22:55:47attributes_cache:{}Title:Rails debugging guide

1.2.to_yaml

Alternatively, callingto_yaml on any object converts it to YAML. You can pass this converted object into thesimple_format helper method to format the output. This is howdebug does its magic.

<%=simple_format@article.to_yaml%><p><b>Title:</b><%=@article.title%></p>

The above code will render something like this:

---!ruby/objectArticleattributes:updated_at:2008-09-05 22:55:47body:It's a very helpful guide for debugging your Rails app.title:Rails debugging guidepublished:tid:"1"created_at:2008-09-05 22:55:47attributes_cache:{}Title:Rails debugging guide

1.3.inspect

Another useful method for displaying object values isinspect, especially when working with arrays or hashes. This will print the object value as a string. For example:

<%=[1,2,3,4,5].inspect%><p><b>Title:</b><%=@article.title%></p>

Will render:

[1, 2, 3, 4, 5]Title: Rails debugging guide

2. The Logger

It can also be useful to save information to log files at runtime. Rails maintains a separate log file for each runtime environment.

2.1. What is the Logger?

Rails makes use of theActiveSupport::Logger class to write log information. Other loggers, such asLog4r, may be substituted:

# config/environments/production.rbconfig.logger=Logger.new(STDOUT)config.logger=Log4r::Logger.new("Application Log")

By default, each log is created underRails.root/log/ and the log file is named after the environment in which the application is running.

2.2. Log Levels

When something is logged, it's printed into the corresponding log if the loglevel of the message is equal to or higher than the configured log level. If youwant to know the current log level, you can call theRails.logger.levelmethod.

The available log levels are::debug,:info,:warn,:error,:fatal,and:unknown, corresponding to the log level numbers from 0 up to 5,respectively. To change the default log level:

# config/environments/production.rbconfig.log_level=:warn

This is useful when you want to log under development or staging without flooding your production log with unnecessary information.

The default Rails log level is:debug. However, it is set to:info for theproduction environment in the default generatedconfig/environments/production.rb.

2.3. Sending Messages

To write in the current log use thelogger.(debug|info|warn|error|fatal|unknown) method from within a controller, model, or mailer:

logger.debug"Person attributes hash:#{@person.attributes.inspect}"logger.info"Processing the request..."logger.fatal"Terminating application, raised unrecoverable error!!!"

Here's an example of a method instrumented with extra logging:

classArticlesController<ApplicationController# ...defcreate@article=Article.new(article_params)logger.debug"New article:#{@article.attributes.inspect}"logger.debug"Article should be valid:#{@article.valid?}"if@article.savelogger.debug"The article was saved and now the user is going to be redirected..."redirect_to@article,notice:'Article was successfully created.'elserender:new,status: :unprocessable_entityendend# ...privatedefarticle_paramsparams.expect(article:[:title,:body,:published])endend

Here's an example of the log generated when this controller action is executed:

Started POST "/articles" for 127.0.0.1 at 2018-10-18 20:09:23 -0400Processing by ArticlesController#create as HTML  Parameters: {"utf8"=>"✓", "authenticity_token"=>"XLveDrKzF1SwaiNRPTaMtkrsTzedtebPPkmxEFIU0ordLjICSnXsSNfrdMa4ccyBjuGwnnEiQhEoMN6H1Gtz3A==", "article"=>{"title"=>"Debugging Rails", "body"=>"I'm learning how to print in logs.", "published"=>"0"}, "commit"=>"Create Article"}New article: {"id"=>nil, "title"=>"Debugging Rails", "body"=>"I'm learning how to print in logs.", "published"=>false, "created_at"=>nil, "updated_at"=>nil}Article should be valid: true   (0.0ms)  begin transaction  ↳ app/controllers/articles_controller.rb:31  Article Create (0.5ms)  INSERT INTO "articles" ("title", "body", "published", "created_at", "updated_at") VALUES (?, ?, ?, ?, ?)  [["title", "Debugging Rails"], ["body", "I'm learning how to print in logs."], ["published", 0], ["created_at", "2018-10-19 00:09:23.216549"], ["updated_at", "2018-10-19 00:09:23.216549"]]  ↳ app/controllers/articles_controller.rb:31   (2.3ms)  commit transaction  ↳ app/controllers/articles_controller.rb:31The article was saved and now the user is going to be redirected...Redirected to http://localhost:3000/articles/1Completed 302 Found in 4ms (ActiveRecord: 0.8ms)

Adding extra logging like this makes it easy to search for unexpected or unusual behavior in your logs. If you add extra logging, be sure to make sensible use of log levels to avoid filling your production logs with useless trivia.

2.4. Verbose Query Logs

When looking at database query output in logs, it may not be immediately clear why multiple database queries are triggered when a single method is called:

irb(main):001:0>Article.pamplemousse  Article Load (0.4ms)  SELECT "articles".* FROM "articles"  Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 1]]  Comment Load (0.1ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 2]]  Comment Load (0.1ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 3]]=> #<Comment id: 2, author: "1", body: "Well, actually...", article_id: 1, created_at: "2018-10-19 00:56:10", updated_at: "2018-10-19 00:56:10">

After enablingverbose_query_logs we can see additional information for each query:

irb(main):003:0>Article.pamplemousse  Article Load (0.2ms)  SELECT "articles".* FROM "articles"  ↳ app/models/article.rb:5  Comment Load (0.1ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 1]]  ↳ app/models/article.rb:6  Comment Load (0.1ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 2]]  ↳ app/models/article.rb:6  Comment Load (0.1ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 3]]  ↳ app/models/article.rb:6=> #<Comment id: 2, author: "1", body: "Well, actually...", article_id: 1, created_at: "2018-10-19 00:56:10", updated_at: "2018-10-19 00:56:10">

Below each database statement you can see arrows pointing to the specific source filename (and line number) of the method that resulted in a database call e.g.↳ app/models/article.rb:5.

This can help you identify and address performance problems caused by N+1 queries: i.e. single database queries that generate multiple additional queries.

Verbose query logs areenabled by default in the development environment logs.

We recommend against using this setting in production environments. It relies on Ruby'sKernel#caller method which tends to allocate a lot of memory in order to generate stacktraces of method calls. Use query log tags (see below) instead.

2.5. Verbose Enqueue Logs

Similar to the "Verbose Query Logs" above, allows to print source locations of methods that enqueue background jobs.

Verbose enqueue logs areenabled by default in the development environment logs.

# config/environments/development.rbconfig.active_job.verbose_enqueue_logs=true
# bin/rails consoleActiveJob.verbose_enqueue_logs = true

We recommend against using this setting in production environments.

2.6. Verbose redirect logs

Similar to other verbose log settings above, this logs the source location of a redirect.

Redirected to http://localhost:3000/posts/1↳ app/controllers/posts_controller.rb:32:in `block (2 levels) in create'

It is enabled by default in development. To enable in other environments, use this configuration:

config.action_dispatch.verbose_redirect_logs=true

As with other verbose loggers, it is not recommended to be used in production environments.

3. SQL Query Comments

SQL statements can be commented with tags containing runtime information, such as the name of the controller or job, totrace troublesome queries back to the area of the application that generated these statements. This is useful when you arelogging slow queries (e.g.MySQL,PostgreSQL),viewing currently running queries, or for end-to-end tracing tools.

config.active_record.query_log_tags_enabled=true

Enabling Query tags automatically disables prepared statements, because it makes most queries unique.

By default the name of the application, the name and action of the controller, or the name of the job are logged. Thedefault format isSQLCommenter. For example:

Article Load (0.2ms)  SELECT "articles".* FROM "articles" /*application='Blog',controller='articles',action='index'*/Article Update (0.3ms)  UPDATE "articles" SET "title" = ?, "updated_at" = ? WHERE "posts"."id" = ? /*application='Blog',job='ImproveTitleJob'*/  [["title", "Improved Rails debugging guide"], ["updated_at", "2022-10-16 20:25:40.091371"], ["id", 1]]

The behavior ofActiveRecord::QueryLogs can bemodified to include anything that helps connect the dots from the SQL query, such as request and job ids forapplication logs, account and tenant identifiers, etc.

3.1. Tagged Logging

When running multi-user, multi-account applications, it's often usefulto be able to filter the logs using some custom rules.TaggedLoggingin Active Support helps you do exactly that by stamping log lines with subdomains, request ids, and anything else to aid debugging such applications.

logger=ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))logger.tagged("BCX"){logger.info"Stuff"}# Logs "[BCX] Stuff"logger.tagged("BCX","Jason"){logger.info"Stuff"}# Logs "[BCX] [Jason] Stuff"logger.tagged("BCX"){logger.tagged("Jason"){logger.info"Stuff"}}# Logs "[BCX] [Jason] Stuff"

3.2. Impact of Logs on Performance

Logging will always have a small impact on the performance of your Rails app,particularly when logging to disk. Additionally, there are a few subtleties:

Using the:debug level will have a greater performance penalty than:fatal,as a far greater number of strings are being evaluated and written to thelog output (e.g. disk).

Another potential pitfall is too many calls toLogger in your code:

logger.debug"Person attributes hash:#{@person.attributes.inspect}"

In the above example, there will be a performance impact even if the allowedoutput level doesn't include debug. The reason is that Ruby has to evaluatethese strings, which includes instantiating the somewhat heavyString objectand interpolating the variables.

Therefore, it's recommended to pass blocks to the logger methods, as these areonly evaluated if the output level is the same as — or included in — the allowed level(i.e. lazy loading). The same code rewritten would be:

logger.debug{"Person attributes hash:#{@person.attributes.inspect}"}

The contents of the block, and therefore the string interpolation, are onlyevaluated if debug is enabled. This performance savings are only reallynoticeable with large amounts of logging, but it's a good practice to employ.

This section was written byJon Cairns at a Stack Overflow answerand it is licensed undercc by-sa 4.0.

4. Debugging with thedebug Gem

When your code is behaving in unexpected ways, you can try printing to logs orthe console to diagnose the problem. Unfortunately, there are times when thissort of error tracking is not effective in finding the root cause of a problem.When you actually need to journey into your running source code, the debuggeris your best companion.

The debugger can also help you if you want to learn about the Rails source codebut don't know where to start. Just debug any request to your application anduse this guide to learn how to move from the code you have written into theunderlying Rails code.

Rails 7 includes thedebug gem in theGemfile of new applications generatedby CRuby. By default, it is ready in thedevelopment andtest environments.Please check itsdocumentation for usage.

4.1. Entering a Debugging Session

By default, a debugging session will start after thedebug library is required, which happens when your app boots. But don't worry, the session won't interfere with your application.

To enter the debugging session, you can usebinding.break and its aliases:binding.b anddebugger. The following examples will usedebugger:

classPostsController<ApplicationControllerbefore_action:set_post,only:%i[ show edit update destroy ]# GET /posts or /posts.jsondefindex@posts=Post.alldebuggerend# ...end

Once your app evaluates the debugging statement, it'll enter the debugging session:

ProcessingbyPostsController#index as HTML[2,11]in~/projects/rails-guide-example/app/controllers/posts_controller.rb2|before_action:set_post,only:%i[ show edit update destroy ]3|4|# GET /posts or /posts.json5|defindex6|@posts=Post.all=>7|debugger8|end9|10|# GET /posts/1 or /posts/1.json11|defshow=>#0    PostsController#index at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:7#1    ActionController::BasicImplicitRender#send_action(method="index", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-8.1.0.alpha/lib/action_controller/metal/basic_implicit_render.rb:6# and 72 frames (use `bt' command for all frames)(rdbg)

You can exit the debugging session at any time and continue your application execution with thecontinue (orc) command. Or, to exit both the debugging session and your application, use thequit (orq) command.

4.2. The Context

After entering the debugging session, you can type in Ruby code as if you are in a Rails console or IRB.

(rdbg)@posts# ruby[](rdbg)self#<PostsController:0x0000000000aeb0>(rdbg)

You can also use thep orpp command to evaluate Ruby expressions, which is useful when a variable name conflicts with a debugger command.

(rdbg)pheaders# command=>{"X-Frame-Options"=>"SAMEORIGIN","X-XSS-Protection"=>"1; mode=block","X-Content-Type-Options"=>"nosniff","X-Download-Options"=>"noopen","X-Permitted-Cross-Domain-Policies"=>"none","Referrer-Policy"=>"strict-origin-when-cross-origin"}(rdbg)ppheaders# command{"X-Frame-Options"=>"SAMEORIGIN","X-XSS-Protection"=>"1; mode=block","X-Content-Type-Options"=>"nosniff","X-Download-Options"=>"noopen","X-Permitted-Cross-Domain-Policies"=>"none","Referrer-Policy"=>"strict-origin-when-cross-origin"}(rdbg)

Besides direct evaluation, the debugger also helps you collect a rich amount of information through different commands, such as:

  • info (ori) - Information about current frame.
  • backtrace (orbt) - Backtrace (with additional information).
  • outline (oro,ls) - Available methods, constants, local variables, and instance variables in the current scope.

4.2.1. Theinfo Command

info provides an overview of the values of local and instance variables that are visible from the current frame.

(rdbg)info# command%self=#<PostsController:0x0000000000af78>@_action_has_layout=true@_action_name="index"@_config={}@_lookup_context=#<ActionView::LookupContext:0x00007fd91a037e38 @details_key=nil, @digest_cache=...@_request=#<ActionDispatch::Request GET "http://localhost:3000/posts" for 127.0.0.1>@_response=#<ActionDispatch::Response:0x00007fd91a03ea08 @mon_data=#<Monitor:0x00007fd91a03e8c8>...@_response_body=nil@_routes=nil@marked_for_same_origin_verification=true@posts=[]@rendered_format=nil

4.2.2. Thebacktrace Command

When used without any options,backtrace lists all the frames on the stack:

=>#0    PostsController#index at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:7#1    ActionController::BasicImplicitRender#send_action(method="index", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-2.0.alpha/lib/action_controller/metal/basic_implicit_render.rb:6#2    AbstractController::Base#process_action(method_name="index", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-8.1.0.alpha/lib/abstract_controller/base.rb:214#3    ActionController::Rendering#process_action(#arg_rest=nil) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-8.1.0.alpha/lib/action_controller/metal/rendering.rb:53#4    block in process_action at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-8.1.0.alpha/lib/abstract_controller/callbacks.rb:221#5    block in run_callbacks at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activesupport-8.1.0.alpha/lib/active_support/callbacks.rb:118#6    ActionText::Rendering::ClassMethods#with_renderer(renderer=#<PostsController:0x0000000000af78>) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actiontext-8.1.0.alpha/lib/action_text/rendering.rb:20#7    block {|controller=#<PostsController:0x0000000000af78>, action=#<Proc:0x00007fd91985f1c0 /Users/st0012/...|} in <class:Engine> (4 levels) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actiontext-8.1.0.alpha/lib/action_text/engine.rb:69#8    [C] BasicObject#instance_exec at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activesupport-8.1.0.alpha/lib/active_support/callbacks.rb:127.....andmore

Every frame comes with:

  • Frame identifier
  • Call location
  • Additional information (e.g. block or method arguments)

This will give you a great sense about what is happening in your app. However, you probably will notice that:

  • There are too many frames (usually 50+ in a Rails app).
  • Most of the frames are from Rails or other libraries you use.

Thebacktrace command provides 2 options to help you filter frames:

  • backtrace [num] - only shownum numbers of frames, e.g.backtrace 10 .
  • backtrace /pattern/ - only show frames with identifier or location that matches the pattern, e.g.backtrace /MyModel/.

It is also possible to use these options together:backtrace [num] /pattern/.

4.2.3. Theoutline Command

outline is similar topry andirb'sls command. It will show you what is accessible from the current scope, including:

  • Local variables
  • Instance variables
  • Class variables
  • Methods & their sources
ActiveSupport::Configurable#methods: configAbstractController::Base#methods:action_methodsaction_nameaction_name=available_action?controller_pathinspectresponse_bodyActionController::Metal#methods:content_typecontent_type=controller_namedispatchheaderslocationlocation=media_typemiddleware_stackmiddleware_stack=middleware_stack?performed?requestrequest=reset_sessionresponseresponse=response_body=response_codesessionset_request!set_response!statusstatus=to_aActionView::ViewPaths#methods:_prefixesany_templates?append_view_pathdetails_for_lookupformatsformats=localelocale=lookup_contextprepend_view_pathtemplate_exists?view_pathsAbstractController::Rendering#methods: view_assigns# .....PostsController#methods: create  destroy  edit  index  new  show  updateinstancevariables:@_action_has_layout@_action_name@_config@_lookup_context@_request@_response@_response_body@_routes@marked_for_same_origin_verification@posts@rendered_formatclassvariables:@@raise_on_open_redirects

4.3. Breakpoints

There are many ways to insert and trigger a breakpoint in the debugger. In addition to adding debugging statements (e.g.debugger) directly in your code, you can also insert breakpoints with commands:

  • break (orb)
    • break - list all breakpoints
    • break <num> - set a breakpoint on thenum line of the current file
    • break <file:num> - set a breakpoint on thenum line offile
    • break <Class#method> orbreak <Class.method> - set a breakpoint onClass#method orClass.method
    • break <expr>.<method> - sets a breakpoint on<expr> result's<method> method.
  • catch <Exception> - set a breakpoint that'll stop whenException is raised
  • watch <@ivar> - set a breakpoint that'll stop when the result of current object's@ivar is changed (this is slow)

And to remove them, you can use:

  • delete (ordel)
    • delete - delete all breakpoints
    • delete <num> - delete the breakpoint with idnum

4.3.1. Thebreak Command

Set a breakpoint on a specified line number - e.g.b 28

[20,29]in~/projects/rails-guide-example/app/controllers/posts_controller.rb20|end21|22|# POST /posts or /posts.json23|defcreate24|@post=Post.new(post_params)=>25|debugger26|27|respond_todo|format|28|if@post.save29|format.html{redirect_to@post,notice:"Post was successfully created."}=>#0    PostsController#create at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:25#1    ActionController::BasicImplicitRender#send_action(method="create", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/basic_implicit_render.rb:6# and 72 frames (use `bt' command for all frames)(rdbg)b28# break command#0  BP - Line  /Users/st0012/projects/rails-guide-example/app/controllers/posts_controller.rb:28 (line)
(rdbg)c# continue command[23,32]in~/projects/rails-guide-example/app/controllers/posts_controller.rb23|defcreate24|@post=Post.new(post_params)25|debugger26|27|respond_todo|format|=>28|if@post.save29|format.html{redirect_to@post,notice:"Post was successfully created."}30|format.json{render:show,status: :created,location:@post}31|else32|format.html{render:new,status: :unprocessable_entity}=>#0    block {|format=#<ActionController::MimeResponds::Collec...|} in create at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:28#1    ActionController::MimeResponds#respond_to(mimes=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/mime_responds.rb:205# and 74 frames (use `bt' command for all frames)Stopby#0  BP - Line  /Users/st0012/projects/rails-guide-example/app/controllers/posts_controller.rb:28 (line)

Set a breakpoint on a given method call - e.g.b @post.save.

[20,29]in~/projects/rails-guide-example/app/controllers/posts_controller.rb20|end21|22|# POST /posts or /posts.json23|defcreate24|@post=Post.new(post_params)=>25|debugger26|27|respond_todo|format|28|if@post.save29|format.html{redirect_to@post,notice:"Post was successfully created."}=>#0    PostsController#create at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:25#1    ActionController::BasicImplicitRender#send_action(method="create", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/basic_implicit_render.rb:6# and 72 frames (use `bt' command for all frames)(rdbg)b@post.save# break command#0  BP - Method  @post.save at /Users/st0012/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/suppressor.rb:43
(rdbg)c# continue command[39,48]in~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/suppressor.rb39|SuppressorRegistry.suppressed[name]=previous_state40|end41|end42|43|defsave(**)# :nodoc:=>44|SuppressorRegistry.suppressed[self.class.name]?true:super45|end46|47|defsave!(**)# :nodoc:48|SuppressorRegistry.suppressed[self.class.name]?true:super=>#0    ActiveRecord::Suppressor#save(#arg_rest=nil) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/suppressor.rb:44#1    block {|format=#<ActionController::MimeResponds::Collec...|} in create at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:28# and 75 frames (use `bt' command for all frames)Stopby#0  BP - Method  @post.save at /Users/st0012/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/suppressor.rb:43

4.3.2. Thecatch Command

Stop when an exception is raised - e.g.catch ActiveRecord::RecordInvalid.

[20,29]in~/projects/rails-guide-example/app/controllers/posts_controller.rb20|end21|22|# POST /posts or /posts.json23|defcreate24|@post=Post.new(post_params)=>25|debugger26|27|respond_todo|format|28|if@post.save!29|format.html{redirect_to@post,notice:"Post was successfully created."}=>#0    PostsController#create at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:25#1    ActionController::BasicImplicitRender#send_action(method="create", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/basic_implicit_render.rb:6# and 72 frames (use `bt' command for all frames)(rdbg)catchActiveRecord::RecordInvalid# command#1  BP - Catch  "ActiveRecord::RecordInvalid"
(rdbg)c# continue command[75,84]in~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb75|defdefault_validation_context76|new_record??:create::update77|end78|79|defraise_validation_error=>80|raise(RecordInvalid.new(self))81|end82|83|defperform_validations(options={})84|options[:validate]==false||valid?(options[:context])=>#0    ActiveRecord::Validations#raise_validation_error at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb:80#1    ActiveRecord::Validations#save!(options={}) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb:53# and 88 frames (use `bt' command for all frames)Stopby#1  BP - Catch  "ActiveRecord::RecordInvalid"

4.3.3. Thewatch Command

Stop when the instance variable is changed - e.g.watch @_response_body.

[20,29]in~/projects/rails-guide-example/app/controllers/posts_controller.rb20|end21|22|# POST /posts or /posts.json23|defcreate24|@post=Post.new(post_params)=>25|debugger26|27|respond_todo|format|28|if@post.save!29|format.html{redirect_to@post,notice:"Post was successfully created."}=>#0    PostsController#create at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:25#1    ActionController::BasicImplicitRender#send_action(method="create", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/basic_implicit_render.rb:6# and 72 frames (use `bt' command for all frames)(rdbg)watch@_response_body# command#0  BP - Watch  #<PostsController:0x00007fce69ca5320> @_response_body =
(rdbg)c# continue command[173,182]in~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal.rb173|body=[body]unlessbody.nil?||body.respond_to?(:each)174|response.reset_body!175|returnunlessbody176|response.body=body177|super=>178|end179|180|# Tests if render or redirect has already happened.181|defperformed?182|response_body||response.committed?=>#0    ActionController::Metal#response_body=(body=["<html><body>You are being <a href=\"ht...) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal.rb:178 #=> ["<html><body>You are being <a href=\"ht...#1    ActionController::Redirecting#redirect_to(options=#<Post id: 13, title: "qweqwe", content:..., response_options={:allow_other_host=>false}) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/redirecting.rb:74# and 82 frames (use `bt' command for all frames)Stopby#0  BP - Watch  #<PostsController:0x00007fce69ca5320> @_response_body =  -> ["<html><body>You are being <a href=\"http://localhost:3000/posts/13\">redirected</a>.</body></html>"](rdbg)

4.3.4. Breakpoint Options

In addition to different types of breakpoints, you can also specify options to achieve more advanced debugging workflows. Currently, the debugger supports 4 options:

  • do: <cmd or expr> - when the breakpoint is triggered, execute the given command/expression and continue the program:
    • break Foo#bar do: bt - whenFoo#bar is called, print the stack frames.
  • pre: <cmd or expr> - when the breakpoint is triggered, execute the given command/expression before stopping:
    • break Foo#bar pre: info - whenFoo#bar is called, print its surrounding variables before stopping.
  • if: <expr> - the breakpoint only stops if the result of<expr> is true:
    • break Post#save if: params[:debug] - stops atPost#save ifparams[:debug] is also true.
  • path: <path_regexp> - the breakpoint only stops if the event that triggers it (e.g. a method call) happens from the given path:
    • break Post#save path: app/services/a_service - stops atPost#save if the method call happens at a path that includesapp/services/a_service.

Please also note that the first 3 options:do:,pre: andif: are also available for the debug statements we mentioned earlier. For example:

[2,11]in~/projects/rails-guide-example/app/controllers/posts_controller.rb2|before_action:set_post,only:%i[ show edit update destroy ]3|4|# GET /posts or /posts.json5|defindex6|@posts=Post.all=>7|debugger(do:"info")8|end9|10|# GET /posts/1 or /posts/1.json11|defshow=>#0    PostsController#index at ~/projects/rails-guide-example/app/controllers/posts_controller.rb:7#1    ActionController::BasicImplicitRender#send_action(method="index", args=[]) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/actionpack-7.0.0.alpha2/lib/action_controller/metal/basic_implicit_render.rb:6# and 72 frames (use `bt' command for all frames)(rdbg:binding.break)info%self=#<PostsController:0x00000000017480>@_action_has_layout=true@_action_name="index"@_config={}@_lookup_context=#<ActionView::LookupContext:0x00007fce3ad336b8 @details_key=nil, @digest_cache=...@_request=#<ActionDispatch::Request GET "http://localhost:3000/posts" for 127.0.0.1>@_response=#<ActionDispatch::Response:0x00007fce3ad397e8 @mon_data=#<Monitor:0x00007fce3ad396a8>...@_response_body=nil@_routes=nil@marked_for_same_origin_verification=true@posts=#<ActiveRecord::Relation [#<Post id: 2, title: "qweqwe", content: "qweqwe", created_at: "...@rendered_format=nil

4.3.5. Program Your Debugging Workflow

With those options, you can script your debugging workflow in one line like:

defcreatedebugger(do:"catch ActiveRecord::RecordInvalid do: bt 10")# ...end

And then the debugger will run the scripted command and insert the catch breakpoint

(rdbg:binding.break)catchActiveRecord::RecordInvaliddo:bt10#0  BP - Catch  "ActiveRecord::RecordInvalid"[75,84]in~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb75|defdefault_validation_context76|new_record??:create::update77|end78|79|defraise_validation_error=>80|raise(RecordInvalid.new(self))81|end82|83|defperform_validations(options={})84|options[:validate]==false||valid?(options[:context])=>#0    ActiveRecord::Validations#raise_validation_error at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb:80#1    ActiveRecord::Validations#save!(options={}) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb:53# and 88 frames (use `bt' command for all frames)

Once the catch breakpoint is triggered, it'll print the stack frames

Stopby#0  BP - Catch  "ActiveRecord::RecordInvalid"(rdbg:catch)bt10=>#0    ActiveRecord::Validations#raise_validation_error at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb:80#1    ActiveRecord::Validations#save!(options={}) at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/validations.rb:53#2    block in save! at ~/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/activerecord-7.0.0.alpha2/lib/active_record/transactions.rb:302

This technique can save you from repeated manual input and make the debugging experience smoother.

You can find more commands and configuration options from itsdocumentation.

5. Debugging with theweb-console Gem

Web Console is a bit likedebug, but it runs in the browser. You can request a console in the context of a view or a controller on any page. The console would be rendered next to your HTML content.

5.1. Console

Inside any controller action or view, you can invoke the console bycalling theconsole method.

For example, in a controller:

classPostsController<ApplicationControllerdefnewconsole@post=Post.newendend

Or in a view:

<%console%><h2>New Post</h2>

This will render a console inside your view. You don't need to care about thelocation of theconsole call; it won't be rendered on the spot of itsinvocation but next to your HTML content.

The console executes pure Ruby code: You can define and instantiatecustom classes, create new models, and inspect variables.

Only one console can be rendered per request. Otherwiseweb-consolewill raise an error on the secondconsole invocation.

5.2. Inspecting Variables

You can invokeinstance_variables to list all the instance variablesavailable in your context. If you want to list all the local variables, you cando that withlocal_variables.

5.3. Settings

  • config.web_console.allowed_ips: Authorized list of IPv4 or IPv6addresses and networks (defaults:127.0.0.1/8, ::1).
  • config.web_console.whiny_requests: Log a message when a console renderingis prevented (defaults:true).

Sinceweb-console evaluates plain Ruby code remotely on the server, don't tryto use it in production.

6. Debugging Memory Leaks

A Ruby application (on Rails or not), can leak memory — either in the Ruby codeor at the C code level.

In this section, you will learn how to find and fix such leaks by using toolssuch as Valgrind.

6.1. Valgrind

Valgrind is an application for detecting C-based memoryleaks and race conditions.

There are Valgrind tools that can automatically detect many memory managementand threading bugs, and profile your programs in detail. For example, if a Cextension in the interpreter callsmalloc() but doesn't properly callfree(), this memory won't be available until the app terminates.

For further information on how to install Valgrind and use with Ruby, refer toValgrind and Rubyby Evan Weaver.

6.2. Find a Memory Leak

There is an excellent article about detecting and fixing memory leaks at Derailed,which you can read here.

7. Plugins for Debugging

There are some Rails plugins to help you to find errors and debug yourapplication. Here is a list of useful plugins for debugging:

  • Query Trace Adds queryorigin tracing to your logs.
  • Exception NotifierProvides a mailer object and a default set of templates for sending emailnotifications when errors occur in a Rails application.
  • Better Errors Replaces thestandard Rails error page with a new one containing more contextual information,like source code and variable inspection.
  • RailsPanel Chrome extension for Railsdevelopment that will end your tailing of development.log. Have all informationabout your Rails app requests in the browser — in the Developer Tools panel.Provides insight to db/rendering/total times, parameter list, rendered views andmore.
  • Pry An IRB alternative and runtime developer console.

8. References



Back to top
[8]ページ先頭

©2009-2025 Movatter.jp