debugger hangs at eval statement #194
Comments
|
@DaveBone I have trouble understanding this issue. So the problem is that tracing stops at same point. Is it possible that it stops because the interpreter is not running any more Ruby code? More importantly, can you provide me with a way to observe the bug myself? |
|
David,
I've used both Byebug within Ruby code and Firefoxe's debugger within the browser. ==> Byebug stops when the Ruby code does an eval expression when tracing from config/application.rb : where the eval statement just sits and waits. At that point I had to abort the program at startup using Cntl C My questions so far are:
Any pointers to documents/websites/forums where these questions allow me to continue my investigations is appreciated I thank you in advance for your ``eyes and ears'' evaluating my request The above code and areas should provide you with a starting point for your debugging. Good luck with it.
|
|
@DaveBone Thank you. This looks very similar to your initial message... which doesn't really answer my question. In any case, a support group seems definitely a better place for this kind of questions. I'll close this for now. If you have a set of commands I can run to see the bug you are seeing, please share them and reopen the issue. |
|
Hi David,
I do not mind helping out. If b) then lets consider the issue closed ;{ if a) is adequate for your investigation :}
If same result happens (Byebug stops outputting source code line traces), I will reopen the issue with the following instructions: D
|
|
David, The support group was very responsive but not appropriate for this type of problem and suggested getting help from Byebug.
|
|
@DaveBone Create a simple dummy application and give me a set of steps I can run in my machine to see this unresponsiveness. Can you do that? |
|
Yep.
|
|
Hi David,
4) bundle install=================Tests showing various issues=========== now run rails s ========test 2: see that byebug stops due to `no file or directory' error throw though the previous test shows that the code is okay [1, 10] in /Users/bone_david/blog/config/application.rb ~/blog: ===========test 3: Tracing: just loops and never continues on to where the server outputs following messages Comment out require / set linetrace commands in config/application.rb ~/blog: rails s [1, 10] in /Users/bone_david/blog/config/environments/development.rb ..... until loop Tracing: /usr/local/rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/webrick/server.rb:170 if svrs = IO.select(@listeners, nil, nil, 2.0)The above are the same issues as i remembered going thru back 6 months. Hope this helps
|
|
Hi Dave! I was now able to reproduce the issue of |
deivid-rodriguez
changed the title
set linetrace + cont combo does not work
|
great. Sent from my iPad
|
test 1 is reproductive with only byebug 7.0+ and I think that's my mistake. I fixed it in #264.
test 2 and 3 seem the same issue and not related to test 1 and #160 since it's also reproductive on byebug 6.0. I fixed it in #263. |
|
Hi Deivid, I now have byebug 9.0.1 installed.
|
|
@DaveBone Well, my real name is David, so you're fine using it! :) You normally would drop |
|
Hi David, here is the terminal output: ~/blog: bundle install Use
|
|
@DaveBone You're using |
|
Hi David, here is the result: ~/blog: rails s ~/blog: d
|
|
Try running rails through |
|
Why bundle install does not work: Gem::FilePermissionError: You don't have write permissions for the /usr/local/rvm/gems/ruby-2.1.1/bin directory. With sudo: ========================same result=================== ~/blog: d
|
|
Mmmm this looks like a problem with your environment or a bug in bundler or something. Somehow the C extension does not seem to be compiled when installing via sudo. Let me release 9.0.2 so you can try this more easily. |
|
ok It could be the xcode environment installed: I've had problems developing with xcode and had to reinstall a previous version that worked! Do u want me to re-install a previous xcode that u are using?
|
|
@DaveBone Please try 9.0.2 |
|
Same issue as shown below. What xcode version are u using? ~/blog: bundle install Gem::FilePermissionError: You don't have write permissions for the /usr/local/rvm/gems/ruby-2.1.1/bin directory. ~/blog: sudo bundle install ~/blog: byebug -v from /usr/local/rvm/gems/ruby-2.1.1@global/bin/ruby_executable_hooks:15:in eval' from /usr/local/rvm/gems/ruby-2.1.1@global/bin/ruby_executable_hooks:15:in'~/blog:
|
|
Now you need to remove the line I don't use MacOSX nor rvm, so our setups are very different, by the way. |
|
Bundle picks up old byebug with gemfile gem 'byebug' Running byebug 9.0.1
|
|
Run |
|
Still had to use sudo to install byebug Running byebug 9.0.2 The set linetrace/cont combo starts logging! YES :} But stops logging in the eval statement as show below ~/blog: rails s [1, 10] in /Users/bone_david/blog/config/application.rb ...... ~/blog:=============test 2 config/development.rb==== Same waiting on loop. stopped after 1 minute of looping [1, 10] in /Users/bone_david/blog/config/environments/development.rb ~/blog:d
|
deivid-rodriguez
changed the title
set linetrace + cont combo does not work
|
Noted. Sorry for bothering you again @k0kubun , do you know what might be going on here? |
|
I overlooked one issue in #194 (comment). The problem in test2 and test3 aren't the same. Then #194 (comment) contains only test3's issue.
I couldn't understand what's wrong in test3 and no issue found in #194 (comment) for me. Just rails server looped being traced and you stopped it with SIGINT. I guess it's not a bug and the way to use byebug is wrong. But I don't know how linetrace works in multi-threaded environment like WEBrick. Only one thing I can say is that if you're not debugging Rails or WEBrick, it may be bad idea to start tracing from such a line. |
|
I do not understand. This is not happening.
For example u can do this type of "execution line code" tracing in other languages using dtrace and c++ This is not a criticism but observations on how to improve the product.
My view is to learn by "execution code path sequences" what is happening. My 2 cents. I do appreciate the efforts expressed so far.
|
So your usecase may be that you want to do something like rbtrace with byebug. Since
You mean byebug should trace until program reaches "[2016-05-15 20:46:50] INFO WEBrick 1.3.1" and nothing should be put after "[2016-05-15 20:46:50] INFO WEBrick::HTTPServer#start: pid=1236 port=3000"? |
|
Let me summarize my findings from this note:
Seeing this looping output allows me then to control c the execution.
The manifestations to investigate:
What i hope to establish are the conditions manifesting these issues and possibly to come up with suggested work arounds or work-in-process warnings. |
|
I admit that some issue may exist in the combination of rack, webrick, rails and byebug. But the scope is too large and personally I have no time to do such hard investigation. Could you investigate it further by yourself and provide minimal code to reproduce the two issues? I mean, ideally the issue report to byebug should not include WEBrick, Rack and config/* of Rails. |
|
Yes i will play with the program and byebug debugging. The 2 issues being investigated by me are as reported:
d
|
|
Hi Guys,
I am exploring dtrace to determine a reduced context as per Kakashi Kokubun's request. Apple's detour: El Capitan's SID I am currently looking at a work around to see where dtrace exploration takes me.
|
|
Hi David + Takashi,
Sorry that it took so long looking at the problem re 2 years.
My journey:
1) Created a Freebsd bootable disk for my mac: by creating on a memory stick a bootable Freebsd distribution. Freebsd used cuz of dtrace
2) Use dtrace to watch rails server execute with byebug's traceline statement turned on. This produces a recursive loop waiting on stdout to output its source lines
This guard also prevented dtrace output pipe lining with tee utility. When stopping the rail server, dtrace then flushed out its output.
3) I did other interspersed activities as i am retired
4) Sometimes the journey is at the tip of one's nose and not around the back of one's head to the other side: laughing at myself :}
The good news is Byebug funcitons properly!
The issue is in builder.rb"s statement using TOPLEVEL_BINDING context
def self.new_from_string(builder_script, file="(rackup)")
eval "Rack::Builder.new {\n" + builder_script + "\n}.to_app", TOPLEVEL_BINDING, file, 0
end
On my mac os:
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.5/lib/rack/builder.rb
In Freebsd
~/blog/.rvm/ of ruby version/src
The TOPLEVEL_BINDING context takes over stdout and guards against its use. Probably builder.rb software developer's decision to not allow the tracing of this eval statement.
By commenting out in builder.rb
eval str#, TOPLEVEL_BINDING, file, 0
^
!
----- U can observe the Byebug traced lines of the eval statement
So if anyone like me wants to trace the server to post evaluate a la grep, gawk etc the source code modules called, maybe astatement in Byebug's documentation will add this finding.
I did not post this to the forum as to possible developer's reason to disallow the tracing to public eyes?
Hope this helps, and thanks to your past responses
Dave
… On Jun 2, 2016, at 12:51 PM, david bone ***@***.***> wrote:
Hi Guys,
I have not abandoned my commitment.
So far i have isolated the 2 problems but within the blog/rails context:
1) linetrace on stops at eval statement --- looks like output device capacity or context capacity blocking the linetrace's outputing source lines and continuing blog's execution.
By placing linetrace off before the eval statement, program behaves well and continues to its browser wait loop
2) linetrace outputs blocks the blog's stderr device logging its own messages. When linetrace turned off between 2 of blog's messages, it re-establishes blog's stderr device to output its messages
I am exploring dtrace to determine a reduced context as per Kakashi Kokubun's request.
Apple's detour: El Capitan's SID
I develop on a Mac and have its latest OS running.
El Captitan now uses digital signatures and blocks certain directories/programs like dtrace to run against /usr/local ... programs etc.
I am currently looking at a work around to see where dtrace exploration takes me.
Will keep u posted.
Dave
> On May 16, 2016, at 6:53 PM, Takashi Kokubun ***@***.***> wrote:
>
> I admit that some issue may exist in the combination of rack, webrick, rails and byebug. But the scope is too large and personally I have no time to do such hard investigation. Could you investigate it further and provide minimal code to reproduce the two issues? I mean, ideally the issue report to byebug should not include WEBrick, Rack and config/* of Rails.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub
>
|
and others
I'm trying to see how Rails at ``startup time'' creates Javascripts within
the Clientside of the browser.
rails s #starting my program
I've used both Byebug within Ruby code and Firefoxe's debugger within the
browser.
==> Firefox's debug shows me the generated scripts like jquery etc but this
is after the fact: the code producing the scripts has already executed.
I want to observe how/when it generates the script and how various
callbacks are registered particularly in jquery. Eg plot function using
flot.
==> Byebug stops when the Ruby code does an eval expression when tracing from config/application.rb:
I used byebug's set linetrace to observe the following:
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:33
options = {}
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:34 if
config =~ /.ru$/
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:35
cfgfile = ::File.read(config)
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:36 if
cfgfile[/^#(.)/] && opts
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:39
cfgfile.sub!(/^END\n.\Z/m, '')
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:40 app
= new_from_string cfgfile, config
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:49 eval
"Rack::Builder.new {\n" + builder_script + "\n}.to_app",
Tracing:
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:49 eval
"Rack::Builder.new {\n" + builder_script + "\n}.to_app",
where the eval statement just sits and waits. At that point I had to abort
the program at startup using Cntl C
Other Eval statements like the above has the same behavior.
Is there a work around? so that I can continue viewing the source code's execution paths?
Or is it more of a hit-miss with avoidance attempts to Eval statements to continue debugging?
Thank you for considering this.
Dave
The text was updated successfully, but these errors were encountered: