Forum: Ruby-core [ruby-trunk - Bug #9150][Open] Segfault in case statement execution, possibly related to refinements

Db127d836e3d2a743f0558c0e32bc435?d=identicon&s=25 bradleybuda (Bradley Buda) (Guest)
on 2013-11-25 06:59
(Received via mailing list)
Issue #9150 has been reported by bradleybuda (Bradley Buda).

----------------------------------------
Bug #9150: Segfault in case statement execution, possibly related to
refinements
https://bugs.ruby-lang.org/issues/9150

Author: bradleybuda (Bradley Buda)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43783)
[x86_64-darwin13.0.0]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


This code consistently segfaults in 2.0.0p353:

require 'active_support/all'

case 3600
when 1.week then true
end

This is after `gem install activesupport --version=3.2.13`. The code
works fine in 2.0.0p247.

I ran a git bisect between the two patches and I've narrowed it down to
this change:
https://bugs.ruby-lang.org/projects/ruby-trunk/rep...
. I don't know enough about ruby's internals to debug this any further,
but according to LLDB the problem is a null pointer dereference in
vm_eval.c:

 141  {
 142      VALUE ret;
 143
 144      if (!ci->me->def) return Qnil;
 145
 146      if (th->passed_block) {
 147          ci->blockptr = (rb_block_t *)th->passed_block;

ci->me is null on line 144.

I can reproduce this error on both OSX and Linux. Let me know if I can
provide any more info to help debug this.
054b5f6b8afdd5f6190bad08e46cd782?d=identicon&s=25 zzak (Zachary Scott) (Guest)
on 2013-11-27 09:22
(Received via mailing list)
Issue #9150 has been updated by zzak (Zachary Scott).

Status changed from Open to Assigned
Assignee set to nagachika (Tomoyuki Chikanaga)

@nagachika What do you think?
----------------------------------------
Bug #9150: Segfault in case statement execution, possibly related to
refinements
https://bugs.ruby-lang.org/issues/9150#change-43202

Author: bradleybuda (Bradley Buda)
Status: Assigned
Priority: Normal
Assignee: nagachika (Tomoyuki Chikanaga)
Category:
Target version:
ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43783)
[x86_64-darwin13.0.0]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


This code consistently segfaults in 2.0.0p353:

require 'active_support/all'

case 3600
when 1.week then true
end

This is after `gem install activesupport --version=3.2.13`. The code
works fine in 2.0.0p247.

I ran a git bisect between the two patches and I've narrowed it down to
this change:
https://bugs.ruby-lang.org/projects/ruby-trunk/rep...
. I don't know enough about ruby's internals to debug this any further,
but according to LLDB the problem is a null pointer dereference in
vm_eval.c:

 141  {
 142      VALUE ret;
 143
 144      if (!ci->me->def) return Qnil;
 145
 146      if (th->passed_block) {
 147          ci->blockptr = (rb_block_t *)th->passed_block;

ci->me is null on line 144.

I can reproduce this error on both OSX and Linux. Let me know if I can
provide any more info to help debug this.
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 shugo (Shugo Maeda) (Guest)
on 2013-11-27 10:30
(Received via mailing list)
Issue #9150 has been updated by shugo (Shugo Maeda).


I've not investigated this problem yet, but Matz said implicit method
calls should not honor refinements, so r42869 might be an undesirable
change.
----------------------------------------
Bug #9150: Segfault in case statement execution, possibly related to
refinements
https://bugs.ruby-lang.org/issues/9150#change-43205

Author: bradleybuda (Bradley Buda)
Status: Assigned
Priority: Normal
Assignee: nagachika (Tomoyuki Chikanaga)
Category:
Target version:
ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43783)
[x86_64-darwin13.0.0]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


This code consistently segfaults in 2.0.0p353:

require 'active_support/all'

case 3600
when 1.week then true
end

This is after `gem install activesupport --version=3.2.13`. The code
works fine in 2.0.0p247.

I ran a git bisect between the two patches and I've narrowed it down to
this change:
https://bugs.ruby-lang.org/projects/ruby-trunk/rep...
. I don't know enough about ruby's internals to debug this any further,
but according to LLDB the problem is a null pointer dereference in
vm_eval.c:

 141  {
 142      VALUE ret;
 143
 144      if (!ci->me->def) return Qnil;
 145
 146      if (th->passed_block) {
 147          ci->blockptr = (rb_block_t *)th->passed_block;

ci->me is null on line 144.

I can reproduce this error on both OSX and Linux. Let me know if I can
provide any more info to help debug this.
5cf8f058a4c094bb708174fb43e7a387?d=identicon&s=25 nagachika (Tomoyuki Chikanaga) (Guest)
on 2013-12-02 04:45
(Received via mailing list)
Issue #9150 has been updated by nagachika (Tomoyuki Chikanaga).

Status changed from Assigned to Closed

duplicated. please move to #8872
----------------------------------------
Bug #9150: Segfault in case statement execution, possibly related to
refinements
https://bugs.ruby-lang.org/issues/9150#change-43339

Author: bradleybuda (Bradley Buda)
Status: Closed
Priority: Normal
Assignee: nagachika (Tomoyuki Chikanaga)
Category:
Target version:
ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43783)
[x86_64-darwin13.0.0]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


This code consistently segfaults in 2.0.0p353:

require 'active_support/all'

case 3600
when 1.week then true
end

This is after `gem install activesupport --version=3.2.13`. The code
works fine in 2.0.0p247.

I ran a git bisect between the two patches and I've narrowed it down to
this change:
https://bugs.ruby-lang.org/projects/ruby-trunk/rep...
. I don't know enough about ruby's internals to debug this any further,
but according to LLDB the problem is a null pointer dereference in
vm_eval.c:

 141  {
 142      VALUE ret;
 143
 144      if (!ci->me->def) return Qnil;
 145
 146      if (th->passed_block) {
 147          ci->blockptr = (rb_block_t *)th->passed_block;

ci->me is null on line 144.

I can reproduce this error on both OSX and Linux. Let me know if I can
provide any more info to help debug this.
This topic is locked and can not be replied to.