Closed brodock closed 4 years ago
Thank you for your report.
that failed in a hamlit parsed file. It seems to point to https://github.com/k0kubun/hamlit/blob/master/ext/hamlit/hamlit.c#L158
Right.
the relevant bits:
While it's indeed failed when calling hamlit's C extension, I believe this is not caused by the C extension but RubyVM itself in this particular output.
The most important part in Ruby's SEGV output for me is "C level backtrace information", which includes:
-- C level backtrace information -------------------------------------------
/usr/local/lib/libruby.so.2.6(rb_vm_bugreport+0x4f1) [0x7f779df18dd1] vm_dump.c:715
/usr/local/lib/libruby.so.2.6(rb_bug_context+0xe7) [0x7f779dd699a7] error.c:609
/usr/local/lib/libruby.so.2.6(sigsegv+0x42) [0x7f779de82252] signal.c:998
/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f779d8890e0]
/usr/local/lib/libruby.so.2.6(method_entry_get+0x144) [0x7f779def5834] vm_method.c:813
/usr/local/lib/libruby.so.2.6(vm_respond_to+0x3f) [0x7f779df01dcf] vm_method.c:1990
/usr/local/lib/libruby.so.2.6(rb_check_funcall_default+0x49) [0x7f779df02019] vm_eval.c:358
/usr/local/lib/libruby.so.2.6(rb_check_convert_type_with_id+0x4f) [0x7f779ddfe24f] object.c:2943
/usr/local/lib/libruby.so.2.6(rb_ary_join+0xef) [0x7f779dcf129f] array.c:2315
/builds/gitlab-org/gitlab/vendor/ruby/2.6.0/gems/hamlit-2.11.0/lib/hamlit/hamlit.so(hamlit_build_class+0xd9) [0x7f77901d6349] hamlit.c:158
/usr/local/lib/libruby.so.2.6(vm_call_cfunc+0x10f) [0x7f779def8bff] vm_insnhelper.c:1908
When rb_ary_join was
called, Ruby seems to have failed in method_entry_get
, which is not in hamlic.c, and I believe hamlit.c does nothing special that could indirectly break that part.
Please report this to https://bugs.ruby-lang.org instead. Thanks.
To fix it in either MRI or Hamlit, it'd be nice if we can reproduce it with a small script. Is the /builds/gitlab-org/gitlab/app/views/projects/new.html.haml:53
same as current https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/app/views/projects/new.html.haml#L53?
#create-from-template-pane.tab-pane.js-toggle-container.px-0.pb-0{ class: active_when(active_tab == 'template'), role: 'tabpanel' }
# frozen_string_literal: true
require 'hamlit'
puts "#{RUBY_DESCRIPTION}, hamlit #{Hamlit::VERSION}"
def active_when(condition)
'active' if condition
end
GC.stress = true
total = 1000
total.times do |i|
print "#{i}/#{total}\r"
::Hamlit::AttributeBuilder.build_class(true, "tab-pane js-toggle-container px-0 pb-0".freeze, active_when(true))
::Hamlit::AttributeBuilder.build_class(true, "tab-pane js-toggle-container px-0 pb-0".freeze, active_when(false))
end
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux], hamlit 2.11.0
1000/1000
Hmm...
Is the /builds/gitlab-org/gitlab/app/views/projects/new.html.haml:53 same as current https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/app/views/projects/new.html.haml#L53?
It is...
I don't think this is easily reproducible, as an example, this happened in this spec run: https://gitlab.com/gitlab-org/gitlab/-/jobs/498446202, but after a retry : https://gitlab.com/gitlab-org/gitlab/-/jobs/499303434 it worked. So maybe this depends on other environmental conditions or some fluke on the vm running the tests itself.
I got a stacktrace from our CI today, that failed in a hamlit parsed file. It seems to point to https://github.com/k0kubun/hamlit/blob/master/ext/hamlit/hamlit.c#L158
the relevant bits:
You can check the full stacktrace in https://gist.github.com/brodock/22dbc591639fe94930d2a661f6d46345