How do I get ruby to print a full backtrace instead of a truncated one?

前端 未结 10 1585
-上瘾入骨i
-上瘾入骨i 2020-12-12 12:00

When I get exceptions, it is often from deep within the call stack. When this happens, more often than not, the actual offending line of code is hidden from me:



        
10条回答
  •  时光取名叫无心
    2020-12-12 13:04

    [examine all threads backtraces to find the culprit]
    Even fully expanded call stack can still hide the actual offending line of code from you when you use more than one thread!

    Example: One thread is iterating ruby Hash, other thread is trying to modify it. BOOM! Exception! And the problem with the stack trace you get while trying to modify 'busy' hash is that it shows you chain of functions down to the place where you're trying to modify hash, but it does NOT show who's currently iterating it in parallel (who owns it)! Here's the way to figure that out by printing stack trace for ALL currently running threads. Here's how you do this:

    # This solution was found in comment by @thedarkone on https://github.com/rails/rails/issues/24627
    rescue Object => boom
    
        thread_count = 0
        Thread.list.each do |t|
          thread_count += 1
          err_msg += "--- thread #{thread_count} of total #{Thread.list.size} #{t.object_id} backtrace begin \n"
          # Lets see if we are able to pin down the culprit
          # by collecting backtrace for all existing threads:
          err_msg += t.backtrace.join("\n")
          err_msg += "\n---thread #{thread_count} of total #{Thread.list.size} #{t.object_id} backtrace end \n"
        end
    
        # and just print it somewhere you like:
        $stderr.puts(err_msg)
    
        raise # always reraise
    end
    

    The above code snippet is useful even just for educational purposes as it can show you (like x-ray) how many threads you actually have (versus how many you thought you have - quite often those two are different numbers ;)

提交回复
热议问题