Bug #11657: Abort Trap 6 when running a test suite

• Status: Closed
• Assignee: ko1 (Koichi Sasada)
• 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]
• Backport: 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: DONE

[adh1003 (Andrew Hodgkinson)]

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.

[adh1003 (Andrew Hodgkinson)]

• Assignee changed from 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.

[adh1003 (Andrew Hodgkinson)]

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.

[adh1003 (Andrew Hodgkinson)]

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.

[nobu (Nobuyoshi Nakada)]

Sorry for delay.

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

[adh1003 (Andrew Hodgkinson)]

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.

[adh1003 (Andrew Hodgkinson)]

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://[e-mail]/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?

[ko1 (Koichi Sasada)]

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!

[ko1 (Koichi Sasada)]

• 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.

[ko1 (Koichi Sasada)]

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:{

[usa (Usaku NAKAMURA)]

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

[adh1003 (Andrew Hodgkinson)]

Excellent, many thanks for the patches :-)

[adh1003 (Andrew Hodgkinson)]

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.

[nagachika (Tomoyuki Chikanaga)]

• 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.

[adh1003 (Andrew Hodgkinson)]

Tomoyuki Chikanaga wrote:

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

That is excellent :-) many thanks.