| Message |
 |
Date: 2010-12-14 13:12
Sender: Rocky Bernstein
Reread http://bashdb.sourceforge.net/ruby-debug.html |
Date: 2010-12-13 16:28
Sender: Dennis Ushakov
It seems that adding Debugger.keep_frame_bindings=true before
Debugger.start fixes binding.rb test. Moreover, setting this
option seems to fix segfault as well. Any ideas why this is turned
off by default? |
Date: 2010-12-13 15:20
Sender: Dennis Ushakov
I've submitted patch with teardown here:
http://rubyforge.org/tracker/index.php?func=detail&aid=28779&
amp;group_id=1900&atid=7438
Also, I've created test configuration at public JetBrains TeamCity
server: http://teamcity.jetbrains.com/project.html?projectId=project51
with debugger tests.
I'm continuing work on fixin binding_n and adding new test |
Date: 2010-12-13 11:39
Sender: Rocky Bernstein
About binding_n. It's useful in its own right; it is not going
to disappear.
I have heard indirectly that a member of the ruby core team has
found it useful. |
Date: 2010-12-13 11:29
Sender: Rocky Bernstein
Yes, please provide a patch that makes all of the tests succeed.
In general, when you provide patches also make sure the tests
continue to work. If the tests need changing, then include that
in the patch.
Yes, we want ruby-debug to be thread safe. Now that you understand
more precisely what the problem is, come up with a standalone
test case that doesn't involve ruby-debug-ide and that tests
the problem is fixed with your patch. That way we can make sure
that your patch fixes this; it will ensure we don't have the
problem again once the problem is fixed.
Thanks |
Date: 2010-12-13 10:57
Sender: Dennis Ushakov
I've checked failing tests and it seems that only binding test
fails, and forgets to stop the debugger so other tests fail because
of this. I think that should be useful to add teardown method
to all base tests that stops the debugger if it's still running.
I can provide this as a separate patch if you need it.
I've a question about binding_n method. I checked whole project
and see no usages of it. Is there some reason for keeping it
at all?
Also, it seems that I've found the problem with local variables
and it happens because ruby-debug-ide tries to evaluate their
values from the different thread. You may think that it's the
problem in the ruby-debug-ide, but for me it seems like problem
with threading in ruby-debug-base. If ruby-debug-base is considered
thread safe it should not provide values that cannot be used
on the other thread. |
Date: 2010-12-08 04:20
Sender: Rocky Bernstein
I've spent more time investigating the behavior and right now,
it is not clear to me that this is a bug in ruby-debug-base.
It is possible this is some sort of improper use via ruby-debug-ide
possibly with the assistance of ruby-debug-base. If someone can
cause a failure without using ruby-debug-ide, that would make
a very very strong case for there being a bug in ruby-debug-base.
The fact that one can change the semantics of ruby-debug-base
(which includes Kernel#binding_n in particular) so that ruby-debug-ide
doesn't SEGV doesn't mean that there is a bug in ruby-debug-base.
Some details surrounding what I see.
First, I note that the traceback for the SEGV raised either in
my tests or the redmine URL given is not in ruby-debug-base code
but in Ruby itself. It is possible this is because ruby-debug-base
passes back a local variable in a way that is out of scope at
the time of use by ruby-debug-ide.
Note that if one changes the data slightly and instead of issuing
"frame 5; var local" you issue that as two commands,
on occasion you get this message from ruby_debug_ide:
Exception in DebugThread loop: method `==' called on terminated
object (0xbfff99f0)
And that also suggests perhaps what the problem may be inside
ruby_debug_ide (with ruby-debug-base assisting). Using gdb, it
looks like this is coming from xml_printer.rb. And the line that
looks like it could match this exception may be line 73:
print_variable(v, yield(v), kind) unless v == 'self'
|
Date: 2010-12-07 02:46
Sender: Rocky Bernstein
I've now been able to reproduce this problem. However with the
changes from the github account, the existing basic tests now
fail. |
Date: 2010-11-13 08:22
Sender: Dennis Ushakov
denofevil@Dennis-Ushakovs-Mac-Pro ~/Code/debug-segfault $ ruby
-v
ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-darwin10.4.0]
denofevil@Dennis-Ushakovs-Mac-Pro ~/Code/debug-segfault $ gem
list
*** LOCAL GEMS ***
bundler (1.0.3, 1.0.0)
columnize (0.3.2)
linecache (0.43)
rake (0.8.7)
rspec (1.3.1)
ruby-debug (0.10.4)
ruby-debug-base (0.10.4)
ruby-debug-ide (0.4.11)
I was able to reproduce it only with ruby-debug-ide, but I don't
see any big difference in code:
First terminal:
ruby /Users/denofevil/.gem/ruby/1.8/bin/rdebug-ide _0.4.11_ --port
50289 -- /usr/bin/spec /Users/denofevil/Code/debug-segfault/my_sp
ec_test.rb
Fast Debugger (ruby-debug-ide 0.4.10) listens on :50289
/Users/denofevil/.rvm/gems/ruby-1.8.7-p302/gems/ruby-debug-ide-0.
4.11/lib/ruby-debug/xml_printer.rb:103: [BUG] Segmentation fault
ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-darwin10.4.0]
Abort trap
Second terminal:
denofevil@Dennis-Ushakovs-Mac-Pro ~ $ telnet localhost 50289
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying fe80::1...
telnet: connect to address fe80::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
b /Users/denofevil/Code/debug-segfault/my_spec_test.rb:17
<breakpointAdded no="1"
location="/Users/denofevil/Code/debug-segfault/my_spec_test.
rb:17"/>start
<breakpoint file="/Users/denofevil/Code/debug-segfault/my
_spec_test.rb" line="17" threadId="1"/>f
5; v l
<variables><variable name="self"
kind="local" value="Spec::Example::ExampleGroup::S
ubclass_1" type="Class" hasChildren="true"
objectId="+0x80e8b554"/>Connection closed by foreign
host.
You can find backtrace here:
http://redmine.ruby-lang.org/attachments/download/1286 |
Date: 2010-11-12 13:04
Sender: Rocky Bernstein
Right now I'm not able to reproduce this problem.
Could you please:
1. run "gem list" and attach that output
2. Inside rdebug run:
save /tmp/settings.txt
and attach that file
3. Give a complete rdebug session, For example
rdebug /tmp/segv.rb
continue 17
4. attach a complete gdb traceback.
Thanks.
|
Date: 2010-11-10 16:43
Sender: Dennis Ushakov
Actually, the simpliest scenario that I've found looks like
this:
require 'rubygems'
require "spec"
class FSO
attr_reader :name
def initialize(name)
@name = name
end
end
describe "fso" do
FILE_NAME = 'snow.jpg'
it "should allow creation from local info" do
fso = FSO.new(FILE_NAME)
fso.name.should == FILE_NAME
end
end
Just place a breakpoint on the FSO.new line and it causes the
seg fault.
(from http://youtrack.jetbrains.net/issue/RUBY-5912#comment=27-16
2941)
BTW, could you please contact me at dennis.ushakov@jetbrains.com
for another question regarding breakpoints skipping? |
Date: 2010-11-10 16:37
Sender: Rocky Bernstein
Since ruby-debug-base is causing a serious problem with JetBrains,
sure, we can put out another release of ruby-debug.
However looking at the patch I don't really understand what's
wrong. Yes, I see that you making a call to eval_expression()
to pick up a value (as you write for "lazy" evaluation)
instead of using scope->local_vars[i]. But under what conditions
is this needed?
Best would be to add a test case to ruby-debug. But if you can't
do just giving the shortest test case that produces the problem
would be helpful.
The sooner you can give a test case or reproducable example,
the sooner we can get this released. Thanks.
|
Date: 2010-11-10 08:24
Sender: Dennis Ushakov
Actually that fix is not quite correct, for fixed version see
https://github.com/denofevil/ruby-debug/commit/07494e43b7b00cf4b4
16bcf1d08309974d8aaf2d |
Date: 2010-11-05 22:42
Sender: Dennis Ushakov
Seems this problem is caused by some lazy initialization of local
variables. Here's the diff of the fix:
Index: ext/ruby_debug.c
=================================================================
==
--- ext/ruby_debug.c (revision 961)
+++ ext/ruby_debug.c (working copy)
@@ -1806,7 +1806,8 @@
for (i=2; i<n; i++)
{ /* skip first 2 ($_ and $~) */
if (!rb_is_local_id(tbl[i])) continue; /* skip flip
states */
- rb_hash_aset(hash, rb_str_new2(rb_id2name(tbl[i])),
scope->local_vars[i]);
+ VALUE val = (id2ref(tbl[i]) == Qnil) ? Qnil
: scope->local_vars[i];
+ rb_hash_aset(hash, rb_str_new2(rb_id2name(tbl[i])),
val);
}
}
Anyone willing to apply and release? =) |
Date: 2009-10-26 18:25
Sender: John Firebaugh
Is anyone looking at this? It makes debugging essentially impossible
for me, and seems to be a problem for many other people as well.
http://rubyforge.org/tracker/index.php?func=detail&aid=27114&
amp;group_id=3085&atid=11903
http://support.aptana.com/asap/browse/ROR-279
http://forums.netbeans.org/topic5276.html
http://www.jetbrains.net/devnet/thread/281342
http://www.jetbrains.net/devnet/thread/280357
http://www.jetbrains.net/devnet/thread/280366
It's been filed as ruby-core bug, but they seem to think it's
a ruby-debug bug:
http://redmine.ruby-lang.org/issues/show/728
Version on old ruby-core tracker:
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2
1185&group_id=426 |
Date: 2009-03-17 14:33
Sender: Dominic Clifton
and with:
ruby-debug (0.10.3)
ruby-debug-base (0.10.3)
ruby-debug-ide (0.4.5)
but with 0.4.5 i can step though some code but then when it hits
the next breakpoint it dies.
|
Date: 2009-03-17 14:30
Sender: Dominic Clifton
happens for me too with:
ruby-debug (0.10.2)
ruby-debug-base (0.10.2)
ruby-debug-ide (0.4.0)
and
ruby-debug (0.10.3)
ruby-debug-base (0.10.3)
ruby-debug-ide (0.4.4)
|
Date: 2009-03-09 12:43
Sender: Oleg Shpynov
Seems to be linked with:
http://rubyforge.org/tracker/?
func=detail&atid=1698&aid=21185&group_id=426
|
