0x2c7/ruby_jard

[BUG] breaks with foreman and rails

jtmkrueger opened this issue · 4 comments

jtmkrueger commented

Describe the bug
When I try to run with foreman, it errors out

To Reproduce
Steps to reproduce the behavior:

  1. put a jard breakpoint in a rails application
  2. start foreman
  3. see error

Expected behavior
The jard window to pop up somwhere

here's the stack trace in a gist

Environment (please complete the following information):

  • OS: MacOS
  • Terminal Emulator Terminal.app
  • Output when you run tput colors in your terminal
  • Output when you run echo $TERM in your terminal
  • Output when you run stty
  • tux
calebmeyer commented

Can confirm. I'm also using rails (5.2.4.4) and foreman.

  • OS: MacOS
  • Terminal Emulator: iTerm2
  • Output when you run tput colors in your terminal
  • Output when you run echo $TERM in your terminal
  • Output when you run stty
    image
  • tmux: no
0x2c7 commented

Hi guys, thanks for reporting this issue.

The root cause of this isuse is that foreman redirects the STDOUT of the rails server (or any proc program) into a pipe (found at https://github.com/ddollar/foreman/blob/5b815c5d8077511664a712aca90b070229ca6413/lib/foreman/engine.rb#L367). Ruby Jard depends heavily on the STDOUT of the program to create rich user interfaces inside terminal, and the STDOUT is a TTY is important. So, any redirection prevents Jard from doing its job. Similar situations happen with other TUI apps like vim, or htop, or bat, etc. In addition, foreman makes things more complicated by spawning the procs as sub-processes, and the main foreman process controls those ones. When you Jard stops at a line, it actually stops insdie a sub-process. Solving all those issues are not trivial since there are bunches of edge cases, or nested piping.

The most completed way to overcome this is remote debugging. Unfortunately, it's not available now. It's definitely in my roadmap at https://rubyjard.org/docs/roadmap/. I'll make it higher priority since I see some ues cases for it recently. In the mean time, you could run the process you want to debug outsie of foreman.

Besides, jard should return a more meaningful message (Jard could not work with redirected STDIN/STDOUT for example), instead of throwing a confusing backtrace like above.

Btw, there was a related conflict between byebug and foreman: ddollar/foreman#58

  • 👍1
0x2c7 commented

Hi @jtmkrueger, @calebmeyer. Please ignore my above post. During the night, I finally found a way to make Jard works with standard stream redirection, which is trying to find the real user tty from /dev/tty. This solution is described in #51. I recorded a video to prove it works at

asciicast

I'll do some manual tests, and wait for other bug fixes before I can release a new version. In the meantime, you guys can test it out by pointing to the master branch:

gem 'ruby_jard', group: :development, git: 'https://github.com/nguyenquangminh0711/ruby_jard'
kbrock commented

Whoa, I was not expecting this to work.

I thought requiring a user to run as foreman run web was a viable solution.
thanks for all your hard work