--memory gives me a ArgumentError: command is too long

[arthurnn]

running a : bundle exec rbtrace -p 41495 --memory

Output is:

*** attached to process 41495
*** detached from process 41495
bundler: failed to load command: rbtrace (/Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/bin/rbtrace)
ArgumentError: command is too long
  /Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/gems/rbtrace-0.4.11/lib/rbtrace/rbtracer.rb:324:in `send_cmd'
  /Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/gems/rbtrace-0.4.11/lib/rbtrace/rbtracer.rb:146:in `eval'
  /Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/gems/rbtrace-0.4.11/lib/rbtrace/cli.rb:467:in `run'
  /Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/gems/rbtrace-0.4.11/bin/rbtrace:5:in `<top (required)>'
  /Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/bin/rbtrace:23:in `load'
  /Users/arthurnn/src/dependency-graph-api/vendor/gems/ruby/2.4.0/bin/rbtrace:23:in `<top (required)>'

I am assuming the memory dump is too big or something, so it would break the msgpack buffer size?

is there a work around of some sort?

[SamSaffron]

Yeah there is a limit to the amount of data we can send via the signal, we need to establish an extra backchannel here. Surprised it is happening on --memory though but I guess that path is pretty deep there.

[themoah]

same here.
@arthurnn what ruby version are you running ? on what OS ?

[arthurnn]

Ruby 2.4.0 - OSX 10.13.4

[ankopainting]

same problem, ruby 2.5.3, macos 10.14

[vaidhyanathan-ananthakrishnan]

same problem in ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin17.0]

[Voxoff]

Same: ruby 2.5.3p105 (2018-10-18 revision 65156), macos, 10.14.1

[jatindhankhar]

Encountered the same error, with both heapdump and custom command -e flag.

Looks like it's mac specific.
Same command worked on linux machine

Ruby - 2.5.1
OSX - 10.14.6

bundle exec rbtrace -p 6563 --heapdump
*** attached to process 6563
*** detached from process 6563
Traceback (most recent call last):
        7: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/bin/ruby_executable_hooks:24:in `<main>'
        6: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/bin/ruby_executable_hooks:24:in `eval'
        5: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/bin/rbtrace:23:in `<main>'
        4: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/bin/rbtrace:23:in `load'
        3: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/gems/rbtrace-0.4.11/bin/rbtrace:5:in `<top (required)>'
        2: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/gems/rbtrace-0.4.11/lib/rbtrace/cli.rb:502:in `run'
        1: from /Users/jatindhankhar/.rvm/gems/ruby-2.5.1/gems/rbtrace-0.4.11/lib/rbtrace/rbtracer.rb:146:in `eval'
/Users/jatindhankhar/.rvm/gems/ruby-2.5.1/gems/rbtrace-0.4.11/lib/rbtrace/rbtracer.rb:324:in `send_cmd': command is too long (ArgumentError)

[jkburges]

For anyone else wondering about rbtrace architecture w.r.t. this issue, I found this blog quite useful: https://balazs.kutilovi.cz/posts/ruby-tracing-part-two-rbtrace/

[robreinhold]

Hey, I know why this is happening on Macs, and the fix is probably easy. I updated the raise arguments in rbtracer.rb, and got this:

Traceback (most recent call last):
        5: from /Users/robreinhold/.rbenv/versions/2.6.6/bin/rbtrace:23:in `<main>'
        4: from /Users/robreinhold/.rbenv/versions/2.6.6/bin/rbtrace:23:in `load'
        3: from /Users/robreinhold/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rbtrace-0.4.14/bin/rbtrace:5:in `<top (required)>'
        2: from /Users/robreinhold/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rbtrace-0.4.14/lib/rbtrace/cli.rb:467:in `run'
        1: from /Users/robreinhold/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rbtrace-0.4.14/lib/rbtrace/rbtracer.rb:146:in `eval'
/Users/robreinhold/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rbtrace-0.4.14/lib/rbtrace/rbtracer.rb:326:in `send_cmd': command is too long: [��eval��Thread.new do; begin; output = '/var/folders/0r/jv9m1ks54v1fbgy3nzz1ysp00000gn/T/output20200924-78777-1o2e8ga'; eval(File.read('/Users/robreinhold/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rbtrace-0.4.14/lib/rbtrace/memory_report.rb')); end; end] (ArgumentError)

The cmd here is 240ish characters, and is being checked against MsgQ::EventMsg::BUF_SIZE

This is defined as:

BUF_SIZE = RUBY_PLATFORM =~ /linux/ ? 256 : 120

The output parameter in the command is generated by Tempfile.new. I suspect that Mac started doing temp files differently or something, and the paths are now much longer than before.

Hard-coding BUF_SIZE to 256 got me a new error:

Error: argument --pid (process already being traced?)

[mcclymont]

Is the BUF_SIZE of 120 a hard limit on OSX?

[lvohra]

i followed a small trick here, i shorten the command by generating the dump in project custom dir with shorten filename(or even you can directly go to tmp dir.

from project root, run the below

bundle exec rbtrace -p 20740 -e 'Thread.new{GC.start;require "objspace";io=File.open("./r.json","w");ObjectSpace.dump_all(output:io);io.close}'

it sucks, if you want to add trace_object_allocations_start. however you can keep it in your app environment config. 👯 👯‍♂️