Closed gltarsa closed 7 years ago
Interesting I have not seen this so far so I wonder what makes your setup different from mine, as I have this quite often actually this way. normally the pry pager uses q
same for me
This is hitting us as well, but in the rails console using pry-rails
: no binding.pry required. Anything that triggers the pager causes it.
Process looks like this when it needs to be kill -9'd:
mp 43629 0.0 0.0 556624768 3996 s005 U+ 1:44pm 0:00.08 /Users/mp/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/zeus-0.15.13/build/zeus-darwin-amd64 c```
(note the very very high mem allocation)
There is a delay between the kill -9 and the process actually exiting.
This issue does not appear in the versions of zeus 0.15.4 to 0.15.12 - only in .13.
interesting... does that happen on a new rails app as well? wonder if any gem causes this, or any pry setting... would you be able to create a demo app for me to reproduce?
This is happening to me as well. Downgrading to 0.15.12 solved it.
rails (4.2.5.1) pry (0.10.4) pry-rails (0.3.6)
I can concur that the downgrade alleviates the immediate pain. Thanks, @maestromac!
rails (4.2.7.1) pry (0.10.4) pry-byebug (3.4.0)
OSX Sierra
Perfect thanks, lets see what is going on here 😢
so something in here broke it https://github.com/burke/zeus/compare/v0.15.12...v0.15.13
@Crunch09 as you wanted to take a look FYI, I assume it has something todo with how terminal is handled, or the input is directed ... The odd thing is it works in emacs using inf-ruby and inf-ruby-switch-from-compilation
I'm also experiencing this. Sometimes, I can ^C
out of the pager and drop back into pry. However, I then cannot quit the main process. I too have had quite a few ^Z
then kill %1
iterations in the last few weeks, though. This also usually corrupts the tty and I have to run stty sane
to get a functioning shell again.
Confirmed downgrading from 0.15.13
to 0.15.12
also resolved the issue for me.
With the help of git bisect
and manually testing the commit i could determine that the culprit is https://github.com/burke/zeus/commit/0916d0f4746995913a91c50979ab0bace8e8137f . cc: @sideshowcoder
Thanks @Crunch09
Ok so I got a little further with that the issue seems to be related to how the terminal state is restored, it is stored in a defer of a go func, where it should be restored at the end of the main func.
One way to work around this is to disable the pager in pry Pry.config.pager = false
this is obviously not ideal but at least means not needing to kill zeus everytime pry decides to page.
Hello,
I'm encountering that same pager bug in v0.15.14
Version 0.15.12 does not have that behavior indeed
Interesting, could you share something to reproduce? Could you try reinstalling zeus at the latest version. @benjamin-thomas
Sure, I'll see what I can do.
I'm developing in a (fairly complicated) docker environment so it should be reproducible.
Same problem with v0.15.15.pre
Do you have a docker environment setup ?
No actually I don't use docker but If you are able to provide a sample repro where the error occurs I can probably take a look @benjamin-thomas
Hello @sideshowcoder
Could you have a look at this repo? https://github.com/benjamin-thomas/zeus-pager-bug
I manage to isolate this bug pretty minimally I think.
Based on sqlite so should be pretty trivial to setup.
I've based it on rails 4 since there seems to be a library loading issue with rails 5, so would make it more difficult to revert zeus versions.
Let me know if you need anything else.
Zeus v0.15.13
Repeat by:
pry
orbyebug
binding.pry
orbyebug
into the codezeus rails s
User.all
or some other command that invokes the pagerAt the first pager prompt,
:
, nothing will advance to the next page,Ctrl-C
does not abort. I have to use^Z
to suspend the process, thenkill -9 %1
to REALLY kill the process.Here is
pstree
output, that shows the relationships at the time of the hang: