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

arthurnn commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

arthurnn commented 6 years ago

Ruby 2.4.0 - OSX 10.13.4

ankopainting commented 6 years ago

same problem, ruby 2.5.3, macos 10.14

vaidhyanathan-ananthakrishnan commented 5 years ago

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

Voxoff commented 5 years ago

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

jatindhankhar commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

Is the BUF_SIZE of 120 a hard limit on OSX?

lvohra commented 2 years ago

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. 👯 👯‍♂️

tmm1 / rbtrace

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