[Bug 1843804] Re: DEP8 segfault on arm64

[Lucas Kanashiro]

Agreed, I had the same problem. This DEP-8 test doesn't fail in arm64
every time, on average it fails 2 out of 5 sequential executions for me.
It should happen because in some executions we are lucky and the memory
access is aligned. Applying the proposed patch I've not faced any
failure after more than 5 sequential executions.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1843804

Title:
  DEP8 segfault on arm64

Status in glibc package in Ubuntu:
  Invalid
Status in ruby-ferret package in Ubuntu:
  Triaged
Status in ruby2.5 package in Ubuntu:
  Triaged

Bug description:
  DEP8 tests are segfaulting on arm64:
  ...Stack trace:
  Not available
  E
  ===============================================================================
  Error: test_key_used_for_id_field(IndexTest):
    StandardError: Signal occurred at <global.c>:422 in sighandler_crash
    Exiting on signal SIGSEGV (11)
  /tmp/autopkgtest.emjxzb/build.gxX/src/test/unit/index/tc_index.rb:202:in `new'
  /tmp/autopkgtest.emjxzb/build.gxX/src/test/unit/index/tc_index.rb:202:in `test_key_used_for_id_field'
       199:   def test_key_used_for_id_field
       200:     fs_path = File.expand_path(File.join(File.dirname(__FILE__), '../../temp/fsdir'))
       201: 
    => 202:     index = Index.new(:path => fs_path, :key => :my_id, :create => true)
       203:     [
       204:       {:my_id => "three", :id => "me"},
       205:       {:my_id => "one", :field2 => "three"},
  ===============================================================================

  Closest I got to debugging this is:
  #0  0x0000ffffbf5a0744 in generic_ivar_get (undef=52, id=85987, obj=<optimized out>) at variable.c:990
          iv_index_tbl = <error reading variable iv_index_tbl (Cannot access memory at address 0x0)>
          index = 187649990798752
          ivtbl = 0xaaaaab0b2da0
          ivtbl = <optimized out>
          iv_index_tbl = <optimized out>
          index = <optimized out>
          ret = <optimized out>
  #1  rb_ivar_lookup (obj=<optimized out>, id=id at entry=85987, undef=undef at entry=52) at variable.c:1205
          val = <optimized out>
          ptr = <optimized out>
          iv_index_tbl = <optimized out>
          len = <optimized out>
          index = 187649990798752
  #2  0x0000ffffbf5a15e0 in rb_ivar_lookup (undef=52, id=85987, obj=<optimized out>) at variable.c:1184
          val = <optimized out>
          len = <optimized out>
          ptr = <optimized out>
          iv_index_tbl = <optimized out>
          index = <optimized out>
          val = <optimized out>
          ptr = <optimized out>
          iv_index_tbl = <optimized out>
          len = <optimized out>
          index = <optimized out>
  #3  rb_ivar_get (obj=<optimized out>, id=85987) at variable.c:1214
          iv = <optimized out>
  #4  0x0000ffffbeb1c12c in frb_fsdir_new (argc=<optimized out>, argv=<optimized out>, klass=<optimized out>) at r_store.c:375
          ref_cnt = <optimized out>
          self = 187649991624280
          rpath = 187649996041240
          rcreate = <optimized out>
          store = 0xaaaaab391410
          create = <optimized out>
          verify = <optimized out>

  The full stack trace has 85 frames.

  The NULL iv_index_tbl comes from;
          st_table *iv_index_tbl = RCLASS_IV_INDEX_TBL(rb_obj_class(obj));

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1843804/+subscriptions