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.
[ BUILD # : 200905281401 ] [ JDK VERSION : 1.6.* ] When I'm debugging my rails application, if I am stopped at a breakpoint, and hold my mouse over a variable or other part of code which will attempt to show the object value, the debugger crashes. This appears to be consistent for every rails project I am currently working on under Linux.
Created attachment 82957 [details] Log file with extra ruby debugging enabled.
What does it mean "debugger crashes"? Please evaluate in ruby...
I'll have a look. Seems to work for me though (I'm also on Linux). Can you reproduce this from scratch with a plain Ruby app, or with a newly created Rails app? Are you able to recall when you run into this for the first time? Also, I noticed you're using rdebug 0.4.6, could you try with 0.4.5 (i.e. the version bundled with the IDE) instead? Although I doubt that it would help, but worth trying I guess.
I need to run this app under MRI and not JRuby due to some gem issues with native code so I can't run directly with the built-in 1.2.0 JRuby. It appears to work using the older version of ruby-debug-ide. Reducing priority because a workaround exists, but I'm setting it at P2 because the workaround may not be usable by some developers (eg.: My work box's gems are strictly controlled and 0.4.6 is the corporate standard and locked down by the sysadmins so it cannot be backed out).
It appears to be a bit trickier than I thought. Under 0.4.5 I did a mouse over and it generated a set of 4 deadlock messages: deadlock 0xb7c7a1ac: sleep:- (main) - /usr/lib/ruby/1.8/webrick/server.rb:91 deadlock 0bx5b90920: sleep:- - /var/lib/gems/ruby-debug-ide-0.4.5/lib/ruby-debug/event_processsor.rb:58 deadlock 0xb5ba82e4: sleep:- - /usr/lib/ruby/1.8/webrick/httpserver.rb:53 deadlock 0xb5f522a0: sleep:- - /usr/lib/ruby/1.8/webrick/httpserver.rb:51
Is there any difference if you run under Mongrel instead of Webrick?
I just switched to mongrel 1.1.5 from webrick and it appears to work with 0.4.5 under mongrel. It may be a combination of webrick and gems that is causing it.
While Mongrel allows the system to view the single variable in the pop-up hint, attempting to load the Variables pane caused the debugger process to terminate. From what I can see in the log, it has to deal with the END_DOCUMENT event from the debugcommons.Util. Once the END_DOCUMENT is received, the debugger terminates.
I see, this one might prove to be difficult to track down. Are you familiar with debugging from the command line? That way we could first make sure it is not a bug in ruby-debug-base or in MRI itself. See e.g. http://www.datanoise.com/ articles/2006/7/12/tutorial-on-ruby-debug for a tutorial - any chance you could try that with your app? When you hit a breakpoint, try inspecting the problematic variable, and listing all global and local variables using the ruby-debug commands listed in the tutorial (you can also see the commands from the IDE log file). I know this is quite a lot to ask, but as I can't reproduce this I think it would be the fastest way to make progress on this.
Some observations from the looking at the log: The "v inspect reservations" command, which the IDE sends to the backend when evaluating an expression (e.g. when hovering the mouse over a variable) seems to cause the problem; it doesn't throw any exceptions, but the response is just: <variables></variables> followed by END_DOCUMENT This leads me to think the problem is either in ruby-debug-ide or ruby-debug-base. Unfortunately I haven't yet found a place where I could add logging to help track this down, I'll continue investigating.
It occurred to me that this might be related to issue 164366, could you please try whether this is still reproducible in RC2 or in the latest daily? Thanks.
The issue seems fixed as per our email discussion with the reporter, indicating that the root cause was the same as in issue 164366. I'm therefore closing this as fixed in 6.7 - Eric, please reopen if you run into this again. Thanks.