Project

General

Profile

Actions

Feature #7436

open

Allow for a "granularity" flag for backtrace_locations

Added by sam.saffron (Sam Saffron) over 11 years ago. Updated about 6 years ago.

Status:
Assigned
Target version:
-
[ruby-core:50094]

Description

related to http://bugs.ruby-lang.org/issues/7051

Sometimes one need less information (or more information) associated with backtraces.

It would be nice if one could send in a separate flag informing the VM about the granularity of information required, eg:

caller_locations(0,-current_depth, BacktraceInfo::Label & BacktraceInfo::Lineno)

This allows for one to take quicker backtraces if they need less information, additionally BacktraceInfo::Bindings and BacktraceInfo::Klass could be added which allow you to gather more information for heavy profiling / diagnostics.

Updated by sam.saffron (Sam Saffron) over 11 years ago

ouch, this was meant to be a feature req not a bug ... cant figure out how to change

Updated by zzak (zzak _) over 11 years ago

  • Category set to core
  • Status changed from Open to Assigned
  • Assignee set to ko1 (Koichi Sasada)
  • Target version set to 2.0.0

Updated by zzak (zzak _) over 11 years ago

  • Tracker changed from Bug to Feature

Updated by zzak (zzak _) over 11 years ago

  • Target version changed from 2.0.0 to 2.6

Updated by ko1 (Koichi Sasada) over 11 years ago

  • Assignee changed from ko1 (Koichi Sasada) to matz (Yukihiro Matsumoto)

Updated by ko1 (Koichi Sasada) over 11 years ago

(2012/11/26 7:06), sam.saffron (Sam Saffron) wrote:

This allows for one to take quicker backtraces if they need less information, additionally BacktraceInfo::Bindings and BacktraceInfo::Klass could be added which allow you to gather more information for heavy profiling / diagnostics.

I want to reject to get bindings and klasses with this API.

Please ask matz.

--
// SASADA Koichi at atdot dot net

Updated by headius (Charles Nutter) over 11 years ago

As a debugging feature I can support access to arbitrary bindings. As a general, runtime, hot-path feature, there's numerous reasons why it's a terrible idea:

  • It exposes all method-local state to everyone. Any library anywhere can not only access your local variables but modify them too. A potentially massive security hole.
  • It requires that all method bodies everywhere in the system maintain all frame/scope state regardless of whether it's used or not, since "Binding.of_caller" style features could access it at any time.
  • It drastically limits optimization potential for Ruby. On a good day, JRuby can be 10x or more faster than MRI largely because we've been able to eliminate framing/scoping overhead. A Binding.of_caller feature would severely damage our performance and very likely limit forever general Ruby performance.

Updated by Anonymous over 11 years ago

=begin
Why not introduce a (({$DEBUG})) variable that tells the runtime to enable introspective features like this at the cost of performance? I would love for better_errors to run on JRuby, but at the moment it can't since JRuby leans too far towards the performance side of the argument and there's no way to tell it to disregard performance in favour of debuggability.

=end

Updated by headius (Charles Nutter) over 11 years ago

A flag that's enabled at runtime would not really work, since optimizations might already have happened. There needs to be a way to specify that optimizations should be off. In JRuby, the simplest way to do that is to turn off the compiler by passing -X-C to JRuby. In that case, all code will remain interpreted with full bindings available at every ruby level of the stack (we do not provide bindings for native methods). Implementing Binding.of_caller in that scenario would be pretty simple.

JRuby currently has a --debug flag that turns on things like trace functions. It might be reasonable for it to turn on full bindings as well, though it would definitely have a major perf impact.

Actions #11

Updated by naruse (Yui NARUSE) about 6 years ago

  • Target version deleted (2.6)
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0