[#103680] [Ruby master Bug#17843] Ruby on Rails error[BUG] Segmentation fault at 0x0000000000000110 ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin15] (#42110) — nayaronfire@...

Issue #17843 has been reported by nayaronfire (kk nayar).

7 messages 2021/05/01

[#103686] [Ruby master Misc#17845] Windows Ruby - ucrt build? — Greg.mpls@...

Issue #17845 has been reported by MSP-Greg (Greg L).

22 messages 2021/05/01

[#103690] [Ruby master Bug#17846] Percent mode changes the output from ERB beyond what is documented — wolf@...

Issue #17846 has been reported by graywolf (Gray Wolf).

8 messages 2021/05/02

[#103724] [Ruby master Feature#17849] Fix Timeout.timeout so that it can be used in threaded Web servers — duerst@...

Issue #17849 has been reported by duerst (Martin Dst).

22 messages 2021/05/05

[#103756] [Ruby master Feature#17853] Add Thread#thread_id — komamitsu@...

Issue #17853 has been reported by komamitsu (Mitsunori Komatsu).

11 messages 2021/05/06

[#103801] [Ruby master Feature#17859] Start IRB when running just `ruby` — deivid.rodriguez@...

Issue #17859 has been reported by deivid (David Rodr刕uez).

18 messages 2021/05/12

[#103866] [Ruby master Bug#17866] Incompatible changes with Psych 4.0.0 — hsbt@...

Issue #17866 has been reported by hsbt (Hiroshi SHIBATA).

13 messages 2021/05/17

[#103892] [Ruby master Bug#17871] TestGCCompact#test_ast_compacts test failing again — jaruga@...

Issue #17871 has been reported by jaruga (Jun Aruga).

11 messages 2021/05/19

[#103912] [Ruby master Bug#17873] Update of default gems in Ruby 3.1 — hsbt@...

Issue #17873 has been reported by hsbt (Hiroshi SHIBATA).

38 messages 2021/05/20

[#103971] [Ruby master Bug#17880] [BUG] We are killing the stack canary set by `opt_setinlinecache` — jean.boussier@...

Issue #17880 has been reported by byroot (Jean Boussier).

8 messages 2021/05/22

[#103974] [Ruby master Feature#17881] Add a Module#const_added callback — jean.boussier@...

Issue #17881 has been reported by byroot (Jean Boussier).

29 messages 2021/05/22

[#104004] [Ruby master Feature#17883] Load bundler/setup earlier to make `bundle exec ruby -r` respect Gemfile — mame@...

Issue #17883 has been reported by mame (Yusuke Endoh).

21 messages 2021/05/24

[#104109] [Ruby master Feature#17930] Add column information into error backtrace — mame@...

Issue #17930 has been reported by mame (Yusuke Endoh).

34 messages 2021/05/31

[ruby-core:103840] [Ruby master Feature#17762] A simple way to trace object allocation

From: mame@...
Date: 2021-05-14 05:03:08 UTC
List: ruby-core #103840
Issue #17762 has been updated by mame (Yusuke Endoh).

Assignee set to mame (Yusuke Endoh)
Status changed from Closed to Assigned

I realized that the compatibility of this library is not important at all, because this is a tool for human's debugging. Any codebase must not use it. This means that we can change the file name and APIs anytime if needed, even after it is release.

So, tentatively, I've committed my proposal as `require "objspace/trace"`. I've heard @ko1 plans to create `lib/debug/run.rb` to enable a new debugger feature that he is now developing. `require "debug/run"` sounds simple and great to me, so I think `require "objspace/trace"` is also good enough. However, I'm okay to change if many people prefer `require "objspace/start_tracing"`.

I admit redefining `Kernel#p` may be radical. But I want to see if it brings any actual issue. I'm not against adding `allocation_location` or something. If anyone wants it too, a pull request is welcome.

Just an idea: it might be good to create a rubocop rule to prevent `require "objspace/trace"` from being committed accidentally.

----------------------------------------
Feature #17762: A simple way to trace object allocation
https://bugs.ruby-lang.org/issues/17762#change-91960

* Author: mame (Yusuke Endoh)
* Status: Assigned
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
----------------------------------------
How about having a short hand to `ObjectSpace.trace_object_allocations_start`, `ObjectSpace.allocation_sourcefile` and `ObjectSpace.allocation_sourceline`?

They are a very powerful tool for debugging and code-reading which allows us to identify an allocation site of an object.
Though they are never lightweight, they are the last resort when you try debugging code written by someone else.

However, the names are too long for me to remember and to type. Whenever I want to use them, I have to google, copy and paste the names.

## Proposal

To enable trace allocations:

```
require "objspace/trace" #=> objspace/trace is enabled
```

To show the allocation site of an object:

```
p obj #=> #<Object:0x...> @ (file.rb):(lineno)
```

## Example

```
require "objspace/trace"
require "active_support/all"

p ActiveSupport::VERSION::STRING
  #=> "6.1.3.1" @ /home/mame/work/ruby/local/lib/ruby/gems/3.1.0/gems/activesupport-6.1.3.1/lib/active_support/gem_version.rb:15
```

## Discussion

I've attached a simple patch that is originally authored by @ko1 .

* Is the message `objspace/trace is enabled` needed or not?
* To stop the trace, you need to use `ObjectSpace.trace_object_allocations_stop`. But, I guess that it is rare that we need to stop it during debugging.
* Is it too radical to redefine `Kernel#p`? I think that it is good enough for many cases. When it matters, the original APIs (`ObjectSpace.trace_object_allocations_start`, ...) can be used.

---Files--------------------------------
objspace-trace.patch (631 Bytes)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next