Project

General

Profile

Bug #11657

Abort Trap 6 when running a test suite

Added by adh1003 (Andrew Hodgkinson) over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin15] *OR* ruby 2.3.0dev (2015-11-01 trunk 52421) [x86_64-darwin15]
[ruby-core:71344]

Description

An internal Ruby gem I develop for my company has a test suite that works fine on Ruby 2.1.x but crashes on 2.2.3 and 2.3.0-dev with:

[BUG] Stack consistency error (sp: 273, bp: 271)

I've tried this on both OS X (10.11.1) and a Debian build in a Virtualbox VM to try and eliminate OS X as the problem, with the same results (as in, an abort and a 'stack consistency error' in the logs). I have attached the backtrace log data from both the OS X and Debian builds, from Ruby 2.2.3p173 (though as I say, I did try 2.3.0-dev too and the same stack error arose).

At present, the component in question is closed source. We are actually planning to open source it, but it'll be a while. I'm unable to replicate this as some isolated test case at present I'm afraid - it seems quite a lot of "stuff" needs to happen before it dies.


Files

ruby_crash_osx.log (141 KB) ruby_crash_osx.log adh1003 (Andrew Hodgkinson), 11/05/2015 03:00 AM
ruby_crash_debian.log (160 KB) ruby_crash_debian.log adh1003 (Andrew Hodgkinson), 11/05/2015 03:00 AM

Updated by adh1003 (Andrew Hodgkinson) over 4 years ago

  • Assignee changed from ruby-core to ko1 (Koichi Sasada)

Changing assignee after 7 days with no response, because I notice from other issues in the list that "ruby-core" never seems to be used.

Updated by adh1003 (Andrew Hodgkinson) over 4 years ago

Andrew Hodgkinson wrote:

Added by Andrew Hodgkinson 11 days ago.

This - https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReport - says:

If the ticket doesn't have any replies after 10 days, you can send a reminder.

It doesn't say how to send a reminder, but hopefully just commenting on the bug suffices.

Updated by adh1003 (Andrew Hodgkinson) over 4 years ago

Andrew Hodgkinson wrote:

I've tried this on both OS X (10.11.1) and a Debian build in a Virtualbox VM [...]

The test suite also crashes under Travis if an attempt is made to use Ruby 2.2.3.

Updated by nobu (Nobuyoshi Nakada) over 4 years ago

Sorry for delay.

We love to see your "isolated test case".
Thank you.

Updated by adh1003 (Andrew Hodgkinson) over 4 years ago

Nobuyoshi Nakada wrote:

We love to see your "isolated test case". Thank you.

OK, unsure if I will be able to replicate it isolated since it seems to need the entire currently-closed-source component to be present. I'll work on it.

Updated by adh1003 (Andrew Hodgkinson) over 4 years ago

Nobuyoshi Nakada wrote:

We love to see your "isolated test case".

My company has now open sourced the gem in question. The best I've been able to is create a branch with a replicable test case that has as many dependencies cut out as I can get away with, using a random seed that causes the error to happen very early in test execution to try and aid fault analysis.

git clone -b demonstration/ruby_223_abort_trap_6 https://git@github.com/LoyaltyNZ/hoodoo.git
cd hoodoo
bundle install
bundle exec rspec -f d spec/services/middleware/middleware_multi_local_spec.rb:677 -f d --seed 30498

This should abort. See "log/test.log" for the stack info.

The full test suite won't run at all because I've stripped out so many things, but that particular section of it, with that particular random seed, prompts the abort quickly. If you ask it to run the whole file:

be rspec -f d spec/services/middleware/middleware_multi_local_spec.rb

...then - ignoring any test failures caused by the stripped-out stuff - you'll notice it gets a variable length through before aborting, apparently with no pattern; but no matter how many or few tests seem to run first, the specific line complaining about the fault prior to the crash is always the same:

/.../hoodoo/spec/services/middleware/middleware_multi_local_spec.rb:227: [BUG] Stack consistency error (sp: 224, bp: 222)

Is there anything else you need to help look into this crash?

Updated by ko1 (Koichi Sasada) over 4 years ago

Thank you.

minimal reproducible script is here:

class C
  attr_accessor :foo
  alias set_foo :foo=
end

c = C.new

2.times{
  c.set_foo foo: 1, bar: 2
}

This is because a bug of method cache.
I'll commit fix.

Your provided code is so much helpful. Thank you!

#8

Updated by ko1 (Koichi Sasada) over 4 years ago

  • Status changed from Open to Closed

Applied in changeset r53164.


  • vm_insnhelper.c (vm_call_method_each_type): should not set fastpath with keyword arguments for VM_METHOD_TYPE_ATTRSET type methods.

Normally, we can not use keyword arguments for this kind of methods,
(obj.foo = 1), but we can set alias names for them.
[Bug #11657]

  • test/ruby/test_keyword.rb: add a test for this fix.

Updated by ko1 (Koichi Sasada) over 4 years ago

nagachika-san:

Ruby 2.2 has same problem. Here is a patch for ruby 2.2.
Ruby 2.1 and before don't have.

Index: vm_insnhelper.c
===================================================================
--- vm_insnhelper.c (revision 53165)
+++ vm_insnhelper.c (working copy)
@@ -1691,7 +1691,7 @@ vm_call_method(rb_thread_t *th, rb_contr
        CALLER_SETUP_ARG(cfp, ci);
        rb_check_arity(ci->argc, 1, 1);
        ci->aux.index = 0;
-       CI_SET_FASTPATH(ci, vm_call_attrset, enable_fastpath && !(ci->flag & VM_CALL_ARGS_SPLAT));
+       CI_SET_FASTPATH(ci, vm_call_attrset, enable_fastpath && !(ci->flag & VM_CALL_ARGS_SPLAT) && ci->kw_arg == NULL);
        return vm_call_attrset(th, cfp, ci);
          }
          case VM_METHOD_TYPE_IVAR:{

Updated by usa (Usaku NAKAMURA) over 4 years ago

  • Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN to 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: REQUIRED

Updated by adh1003 (Andrew Hodgkinson) about 4 years ago

Excellent, many thanks for the patches :-)

Updated by adh1003 (Andrew Hodgkinson) about 4 years ago

2.3.0 works, but 2.2.4 currently doesn't include the fix. I note a tag saying 2.2 is required; I guess it'll end up in 2.2.5 at some point? Thought I'd double-check given that this issue is now marked as Closed but 2.2.4 still crashes. Thanks.

Updated by nagachika (Tomoyuki Chikanaga) about 4 years ago

  • Backport changed from 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: REQUIRED to 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: DONE

Backported at r53567.
ko1 san thank you for providing a patch.

Hello, Andrew.
Sorry for my late reaction. The next patchlevel release 2.2.5 contains the fix for this issue.
Thank you for reporting this.

Updated by adh1003 (Andrew Hodgkinson) about 4 years ago

Tomoyuki Chikanaga wrote:

The next patchlevel release 2.2.5 contains the fix for this issue.

That is excellent :-) many thanks.

Also available in: Atom PDF