This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Any breakpoints set in a Ruby on Rails application will not result in a stop of the application. The breakpoint are not hit and do not turn green. The basic functionality of the rdebug-ide has been confirmed on this machine via Terminal. Debugging a basic "hello world" application does not show this behaviour. Here, everything works as normal. IDE log has been attached.
Created attachment 75533 [details] IDE log
Thanks for filling Ben. Some more question in reply to your email... Later will summarize it here.
So let's try to proceed somehow now when the blocking issue is fixed. Could you try the following, i.e. the main change is usage of different project, brand new, simple/empty one. I've tried: - download latest build [1] - have installed ruby-debug-ide 0.4.4 (and required ruby-debug-base-0.10.3) - start NetBeans - create new RoR project - choose MRI platform - Mongrel server - sqlite3 DB adapter (probably not important) - open boot.rb (in config directory) - put breakpoint on fourth line starting with: "RAILS_ROOT = "#{File..........." - right-click the editor -> Debug File -> QUESTION: does it stop on the breakpoint in the boot.rb? - finish the session (Shift-F5) - try to debug whole project (Menu -> Debug -> Debug Project) or Control-F5 -> QUESTION: does it stop on the breakpoint in the boot.rb? Does that scenario pass for you? [1] http://wiki.netbeans.org/RubyInstallation#section-RubyInstallation-HowDoIGetTheContinuousBuilds
BTW - I also have the same problem. IDE works on a normal project, but when I try to get a breakpoint hit when running an Rspec file (i.e. open rspec file and hitting TEST) it doesn't work. This did work in previous versions of Netbeans IDE for ruby.
callaga> and do you have a possibility to try it now with the IDE where it works. Or do you remember the configuration on which it works - NetBeans, Rails, Ruby, ruby-debug-ide, ruby-debug-base versions. The bug which Ben is encountering is in the backend, not in the NetBeans per se. We talk through emails and we think that bug starts to appear with some combination of Rails 2.2.2 + some version Ruby on Mac. Do you also use Mac? Which Ruby? Self-build or distributed with Mac? Could you attach detailed log as describe here: 6.5: http://wiki.netbeans.org/RubyDebugging#section-RubyDebugging-HowToFileABug 7.0: http://wiki.netbeans.org/RubyDebugging70#section-RubyDebugging70-HowToFileABug Might that your log will be different then Ben's and reveal something. Thanks.
see comments embedded: * do you have a possibility to try it now with the IDE where it works ==> It was pre-6.5 (well at least the up-to-date version of 6.5), so I don't have it now, OR it could have been before I upgraded from Rails 2.1.1 to 2.2.2 recently. I've also upgraded to the latest versions of the debug gems too around the same time. * Or do you remember the configuration on which it works - NetBeans, Rails, Ruby, ruby-debug-ide, ruby-debug-base versions. The bug which Ben is encountering is in the backend, not in the NetBeans per se. We talk through emails and we think that bug starts to appear with some combination of Rails 2.2.2 + some version Ruby on Mac. ==> Per above, unfortunatley I've upgraded a couple of things at the same time so can't be sure. * Do you also use Mac? Which Ruby? Self-build or distributed with Mac? Could you attach detailed log as describe here: ==> I'm on Mac. Some further details below. Also refer to my recent debug log update for Issue 156673. Macintosh-2:equity greg$ ruby -v ruby 1.8.6 (2007-09-23 patchlevel 110) [i686-darwin9.3.0] Macintosh-2:equity greg$ rails -v Rails 2.2.2 Macintosh-2:equity greg$ gem -v 1.3.1 Macintosh-2:equity greg$ sudo gem list Password: *** LOCAL GEMS *** actionmailer (2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.3.3) actionpack (2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.13.6, 1.13.3) actionwebservice (1.2.6, 1.2.3) activerecord (2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.15.6, 1.15.3) activeresource (2.2.2, 2.1.1, 2.1.0, 2.0.2) activesupport (2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.4.4, 1.4.2) calendar_date_select (1.13) capistrano (2.5.2, 2.4.2, 2.2.0, 2.0.0) cgi_multipart_eof_fix (2.5.0, 2.2) columnize (0.1) daemons (1.0.10, 1.0.7) facets (2.4.5) fastthread (1.0.1, 1.0) gem_plugin (0.2.3, 0.2.2) gruff (0.3.1) highline (1.4.0, 1.2.9) hobo (0.8.2) hobofields (0.8.2) hobosupport (0.8.2) hoe (1.7.0, 1.5.1) hpricot (0.6) linecache (0.42) mechanize (0.7.5) mislav-will_paginate (2.3.4) mocha (0.9.1) money (2.0.0) mongrel (1.1.4, 1.0.1) needle (1.3.0) net-scp (1.0.0) net-sftp (2.0.0, 1.1.1, 1.1.0) net-ssh (2.0.0, 1.1.2) net-ssh-gateway (1.0.0) ParseTree (1.7.1) ParseTreeReloaded (0.0.1) rails (2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.2.3) rake (0.8.3, 0.8.1, 0.7.3) rcov (0.8.1.2.0) redgreen (1.2.2) rmagick (1.15.7) rspactor (0.2.0) rspec (1.1.12, 1.1.11, 1.1.4) rspec-rails (1.1.12, 1.1.11) ruby-debug (0.10.3, 0.10.2) ruby-debug-base (0.10.3, 0.10.2, 0.10.0, 0.9.3) ruby-debug-ide (0.4.3, 0.3.1, 0.1.10, 0.1.8) ruby2ruby (1.1.6) rubyforge (1.0.0, 0.4.5) rubygems-update (1.3.1, 1.2.0, 1.1.1, 1.1.0) RubyInline (3.6.7) RubyInlineAcceleration (0.0.1) runt (0.6.0) ZenTest (3.11.0, 3.10.0) Hope this helps.
Martine (CCed), could you try to reproduce this on your Mac (do you have Mac, right?). Important part seems to have Rails 2.2.2. Does the debugging Rails work for you? Thanks.
callaga> thanks for details. It seems to be really Mac specific. If Martin can't help I'll try to find somebody with Mac in the office at Monday and try to reproduce there.
Can reproduce in ${Depot}/app/views/store/index.rhtml file on my: - Mac Os X 10.5.6 - Nb #200901160201 $ rails -v Rails 2.2.2 $ gem -v 1.3.1 $ ruby -v ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9.6.0] $ java -version java version "1.5.0_16" Nex I was trying a 'hello world' app and it at first stoped in a .erb file but after some some changes the bp refused to stop. .rb breakpoints in the same apps worked for me.
Thanks Martine. Little strange that you were able to stop once, seems that others cannot force the debugger to stop at all. Will be great if it the same issue. I will stop by on Monday.
So we have tried in the offices with two Macs with different configurations: - Ruby {1.8.6, 1.8.7} - NetBeans {6.5, 7.0} - ruby-debug-ide {0.3.4, 0.4.4} - on both Rails 2.2.2 with Mongrel 1.1.5 and we are still not able to reproduce - we can stop in the controllers. On one configuration we were not able to stop in .erb views, but that's other problem. So the only way seems to be to put more logging into backends to find the difference on your system(s), likely into ruby-debug-base C code itself, since tracing did not reveal anything on the first try.
anything else you want me to try - what's a good way for me to check it's not my environment I wonder?
Below is my reply to Ben. I'll take a look more deeply on the 80000+ lines tracing outputs Ben sent me. I think I'll try this round once-more and ask you both for detailed traced output. I'll put exact info here of what I exactly would need. Either tomorrow or next week as I said below. ==================================================== > When could you implement the logging for ruby-debug-ide? Hard to say. I'm leaving on Wednesday evening and will be available again on Monday morning next week. So either tomorrow or next week. > Another question - how exactly did you install Ruby and RubyGems on > this Mac? There are several options - using Apple's out-of-the-box > Ruby 1.8.6, or MacPorts Ruby 1.8.7, or self compiled Ruby? On one machine I've used out-of-the-box Ruby with NetBeans 6.5 with ruby-debug-ide 0.3.4. On colleague's machine he has self-compiled 1.8.7-p72. We have tried there with NetBeans 7.0 dev build, with ruby-debug-ide 0.4.4. Here we have some problem with .erb views. >> - Ruby {1.8.6, 1.8.7} >> - NetBeans {6.5, 7.0} >> - ruby-debug-ide {0.3.4, 0.4.4} >> - on both Rails 2.2.2 with Mongrel 1.1.5 >> and we are still not able to reproduce - we can stop in the >> controllers. On one configuration we were not able to stop in .erb >> views, but that's other problem. > > Which configuration worked best for you, i.e. it stopped at all > breakpoints incl. ERB breakpoints? 6.5 one above. >> So the only way seems to be to put more logging into backends to find >> the difference on your system(s), likely into ruby-debug-base C code >> itself, since tracing did not reveal anything on the first try. > > I would be happy to test it for you. On the other hand, I don't have a > spare machine for developing here. > > Please let me know how to proceed. Now it's really up-to-me or somebody who would look into the backends details. Might be I would ask you for one more telnet-sessions-round with tracing turned on - I'll possibly let you know if I need so. So might be tomorrow or next week, sorry. A bit overhauled these days. This is definitely high priority, but it's getting a bit harder, since nothing worked for us so far. Thanks for the help. Will let you know. ====================================================
So let's all start with the same initial scenario, with the same empty projects. Could you follow: In a terminal emit: $ rails -v # just a check Rails 2.2.2 $ ruby -v # just a check, likely OK if you have other Ruby version ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-linux] $ rails ~/tmp/usersapp $ cd ~/tmp/usersapp $ rdebug-ide _0.4.4_ -p 1234 -d -- script/server --port 300 Switch to (or run) second terminal and emit there (<Enter> means press Enter key): $ telnet localhost 1234 ... b app/controllers/application.rb:4<Enter> You should get something like: <breakpointAdded no="1" location="/home/you/tmp/usersapp/app/controllers/application.rb:4"/> Then type: start<Enter> after while you should get something like (IMPORTANT): <breakpoint file="/home/emdot/tmp/usersapp/app/controllers/application.rb" line="4" threadId="1"/> Then type: cont<Enter> You should see Mongrel started in the first terminal. Does you get to the 'IMPORTANT' point above, ideally both of you? Thanks.
PS: for you Ben, it is likely not going to work, since we've tried the same or very similar already. So it's ok to just write 'no' in your case ;) The next step will be to run with '-x' and sending me the outputs and I'll compare your ones with mine with the same scenario...... but let's wait for the results of my previous comments, might be callagga's result give us more clues.
try 1 (had a hiccup with version of rdebug-ide (see below), so I removed _0.4.4_. See below for result. After this I'll see if I can't drop down the version of rdebug-ide Macintosh-2:source greg$ rails -v Rails 2.2.2 Macintosh-2:source greg$ ruby -v ruby 1.8.6 (2007-09-23 patchlevel 110) [i686-darwin9.3.0] Macintosh-2:source greg$ rails test_for_netbeans_1 create create app/controllers create app/helpers create app/models create app/views/layouts create config/environments create config/initializers create config/locales create db create doc create lib create lib/tasks create log create public/images create public/javascripts create public/stylesheets create script/performance create script/process create test/fixtures create test/functional create test/integration create test/performance create test/unit create vendor create vendor/plugins create tmp/sessions create tmp/sockets create tmp/cache create tmp/pids create Rakefile create README create app/controllers/application.rb create app/helpers/application_helper.rb create test/test_helper.rb create test/performance/browsing_test.rb create config/database.yml create config/routes.rb create config/initializers/inflections.rb create config/initializers/mime_types.rb create config/initializers/new_rails_defaults.rb create config/locales/en.yml create config/boot.rb create config/environment.rb create config/environments/production.rb create config/environments/development.rb create config/environments/test.rb create script/about create script/console create script/dbconsole create script/destroy create script/generate create script/performance/benchmarker create script/performance/profiler create script/performance/request create script/process/reaper create script/process/spawner create script/process/inspector create script/runner create script/server create script/plugin create public/dispatch.rb create public/dispatch.cgi create public/dispatch.fcgi create public/404.html create public/422.html create public/500.html create public/index.html create public/favicon.ico create public/robots.txt create public/images/rails.png create public/javascripts/prototype.js create public/javascripts/effects.js create public/javascripts/dragdrop.js create public/javascripts/controls.js create public/javascripts/application.js create doc/README_FOR_APP create log/server.log create log/production.log create log/development.log create log/test.log Macintosh-2:source greg$ cd test test/ test1/ test3/ test4/ test_for_netbeans_1/ test_hackonly/ test_rails2/ test_rails2.zip test_rails2old/ testallocation/ testapp/ testapp2/ testapp3/ Macintosh-2:source greg$ cd test_for_netbeans_1/ Macintosh-2:test_for_netbeans_1 greg$ Macintosh-2:test_for_netbeans_1 greg$ rdebug-ide _0.4.4_ -p 1234 -d -- script/server --port 300 /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:636:in `report_activate_error': RubyGem version error: ruby-debug-ide(0.1.8 not = 0.4.4) (Gem::LoadError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:141:in `activate' from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:49:in `gem' from /opt/local/bin/rdebug-ide:18 Macintosh-2:test_for_netbeans_1 greg$ rdebug-ide -p 1234 -d -- script/server --port 300 Fast Debugger (ruby-debug-ide 0.4.3) listens on :1234 Starting command read loop Processing: b app/controllers/application.rb:4 <breakpointAdded no="1" location="/Users/greg/source/test_for_netbeans_1/app/controllers/application.rb:4"/> Processing: start Starting: running program script => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails 2.2.2 application starting on http://0.0.0.0:300 => Call with -d to detach => Ctrl-C to shutdown server ** Starting Mongrel listening at 0.0.0.0:300 Exiting Macintosh-2:test_for_netbeans_1 greg$ ------------ Macintosh-2:~ greg$ telnet localhost 1234 Trying ::1... Connected to localhost. Escape character is '^]'. b app/controllers/application.rb:4 <breakpointAdded no="1" location="/Users/greg/source/test_for_netbeans_1/app/controllers/application.rb:4"/>start Connection closed by foreign host. Macintosh-2:~ greg$
try 2 - actually I thought I'd try the same again (without the version number) but running as admin/root via using "sudo". By doing this I do get the IMPORTANT point it seems. See below. So is it a permission related issue? Macintosh-2:test_for_netbeans_1 greg$ sudo rdebug-ide -p 1234 -d -- script/server --port 300 Password: Fast Debugger (ruby-debug-ide 0.4.3) listens on :1234 Starting command read loop Processing: b app/controllers/application.rb:4 <breakpointAdded no="1" location="/Users/greg/source/test_for_netbeans_1/app/controllers/application.rb:4"/> Processing: start Starting: running program script => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails 2.2.2 application starting on http://0.0.0.0:300 => Call with -d to detach => Ctrl-C to shutdown server ** Starting Mongrel listening at 0.0.0.0:300 ** Starting Rails with development environment... <breakpoint file="/Users/greg/source/test_for_netbeans_1/app/controllers/application.rb" line="4" threadId="1"/> Stopping Thread #<Thread:0x346fc> Threads equal: true Processing: cont Processing context: cont Resumed Thread #<Thread:0x346fc> ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel 1.1.4 available at 0.0.0.0:300 ** Use CTRL-C to stop. ---------------- Macintosh-2:~ greg$ telnet localhost 1234 Trying ::1... Connected to localhost. Escape character is '^]'. b app/controllers/application.rb:4 <breakpointAdded no="1" location="/Users/greg/source/test_for_netbeans_1/app/controllers/application.rb:4"/>start <breakpoint file="/Users/greg/source/test_for_netbeans_1/app/controllers/application.rb" line="4" threadId="1"/>cont
try 2 (some additional info re my file permissions) Macintosh-2:test_for_netbeans_1 greg$ which rdebug-ide /opt/local/bin/rdebug-ide Macintosh-2:test_for_netbeans_1 greg$ Macintosh-2:test_for_netbeans_1 greg$ ls -l /opt/local/bin/rdebug-ide -rwxr-xr-x 1 root admin 365 12 Jan 21:44 /opt/local/bin/rdebug-ide Macintosh-2:test_for_netbeans_1 greg$ ls -l total 32 -rw-r--r-- 1 greg greg 10619 20 Jan 21:05 README -rw-r--r-- 1 greg greg 307 20 Jan 21:05 Rakefile drwxr-xr-x 6 greg greg 204 20 Jan 21:05 app drwxr-xr-x 9 greg greg 306 20 Jan 21:05 config drwxr-xr-x 2 greg greg 68 20 Jan 21:05 db drwxr-xr-x 3 greg greg 102 20 Jan 21:05 doc drwxr-xr-x 3 greg greg 102 20 Jan 21:05 lib drwxr-xr-x 6 greg greg 204 20 Jan 21:05 log drwxr-xr-x 14 greg greg 476 20 Jan 21:05 public drwxr-xr-x 12 greg greg 408 20 Jan 21:05 script drwxr-xr-x 8 greg greg 272 20 Jan 21:05 test drwxr-xr-x 6 greg greg 204 20 Jan 21:05 tmp drwxr-xr-x 3 greg greg 102 20 Jan 21:05 vendor Macintosh-2:test_for_netbeans_1 greg$ Macintosh-2:test_for_netbeans_1 greg$ which telnet /usr/bin/telnet Macintosh-2:test_for_netbeans_1 greg$ ls -l /usr/bin/telnet -r-xr-xr-x 1 root wheel 277952 9 Dec 13:09 /usr/bin/telnet Macintosh-2:test_for_netbeans_1 greg$
PS I did download a more recent version of Netbeans again a couple of days ago, however I assume this doesn't affect these tests I've run...
Thanks to both. Interesting. Ben also replied to me that he is able to debug only under 'sudo'. But I can't imagine why the debugger would want to write to some non-users areas. But anyway, could you try to run the whole NetBeans under 'sudo' and try whether the debugger in NetBeans works for you then? Callagga (Greg?) please also be sure to update to ruby-debug-ide 0.4.4.
I found the culprit for my setup. The @ sign next to the directory listing means that this directory has "extended attributes" in Mac OS X. In my case, in the Finder, I gave my "dev" directory a colorful yellow label ;-) This means that the dev directory got flagged with the "@" for it's proprietary Apple attribute (The yellow label). Once I removed the yellow label, the "@" sign disappeared from ls. And - all the RoR apps in this folder now are able to be debugged normally.
yes - running Netbeans under "sudo" allows me to hit the debug point in a spec file... Greg
Thanks Ben. Great it's resolved after 60+ exchanged email ;) Was really pretty hidden problem. I'm reopening at least as a task, since the debugger should report when such situation is encountered, since it very hard to find out from user's point of view. I'll try to simulate the same on the Mac in the office, but not soon, having other P1 tasks.... Greg> so at least workaround is there. Could you try to update to ruby-debug-ide 0.4.4. There was a bug fix wrt. to the backtrace during failure. Lower versions fail silently when some problem happens. Might be it will tell us more. At least we know it's a permission problem. Probably a bit different to Ben's one.
re "update to ruby-debug-ide 0.4.4" ==> sorry - that's what I was meaning to imply in my last post, that I'd done this update and still saw the same behaviour
I thought I would add my own experience to this. I have had this same issue with one of my projects, but I am using Ubuntu Intrepid, rdebug-base 0.10.4, rdebug-ide 0.4.4, NB 6.5. As part of my troubleshooting, several times I recreated the project from subversion. This never worked. The other oddity of my setup is that my laptop is a dual-boot, and I keep my dev projects on the XP partition. After reading the Mac solution here concerning extended attributes, I recreated the project from subversion again, but on the linux partition. Lo and behold, it works now. I can stop on breakpoints within the controllers. One other thing, before I fixed it, I could stop on breakpoints if I ran rdebug-ide manually, but not through Netbeans. Weird, glad its fixed. Thanks for the help.
I'm trying to get a picture what is the status of the issue. Is there anyone now who is still having this problem, or are all cases more or less solved now? The debugger backend would need to be enhanced to be able to better handle extended attributes (and win partitions etc), but I think P3 priority would be more appropriate for those.
this seems to be working for me now on NetBeans IDE 6.7 Beta (Build 200904242137) (that is the breakpoint in an Rspec test & debug the file & it stops at the breakpoint ok)
as per last comment, marking as fixed.
At some point Netbeans 7.0 beta stops catching breakpoints too This was happened before for unknown reasons and restored again I'm using Fast Debugger (ruby-debug-ide 0.4.15, ruby-debug-base 0.10.5.jb2) Product Version: NetBeans IDE 7.0 Beta (Build 201011152355) Java: 1.6.0_22; Java HotSpot(TM) 64-Bit Server VM 17.1-b03-307 System: Mac OS X version 10.6.6 running on x86_64; MacRoman; en_US (nb) I thought that it may be connected to migration to a new HDD and using encrypted sparsebundle Project recreation did not help After that, I've tried RubyMine IDE (commercial, not so bad at all) - this IDE uses Fast Debugger (ruby-debug-ide 0.4.15, ruby-debug-base 0.10.5.jb2) too but works in debug mode perfectly in the same folder (no permission changes, etc. - just open project in the same folder, place breakpoint, run debug and it stop! So, I believe that it is really Netbeans problem, not MacOS X related.. Please, investigate - I'll provide any info you need