735121 - Need self tests of GCLargeAlloc::FindBeginning at "interesting" boundary cases

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Felix S. Klock II [:pnkfelix, :fklock]]

Inspired by Bug 733807, comment 8 and Bug 733807, comment 12, namely:

"""
  #6  0x000022a7 in avmplus::_AvmAssertMsg (condition=0, message=0x22d6c8
      "Can't call FindBeginning on something pointing to GC header")
      at AvmAssert.h:72
  #7  0x00062a16 in MMgc::GCLargeAlloc::FindBeginning (item=0x10e9000)
      at GCLargeAlloc-inlines.h:97
  #8  0x00062408 in MMgc::GC::FindBeginningFast (this=0x1005018,
      gcItem=0x10e4000)
      at GC-inlines.h:533
"""

(where, when tracing through the code, GC::FindBeginningFast is stepping backwards from an address looking for the start of the object, and I strongly suspect we are hitting a corner case here where we step too far.)

and

"""
  So: Bug 525875 does not itself explain this particular bug.
  But like [Bug 733807], it is a case where we show weakness in
  testing behavior at large offsets (or at least "interesting"
  large offsets like multiples of the block size, which seems
  to be our problem here).
"""

Comment 1

[Felix S. Klock II [:pnkfelix, :fklock]]

Note also that the issue from Bug 733807 seems likely to be isolated GC::FindBeginningFast, and should not come up in GC::FindBeginningGuarded, because the latter deliberately avoids calling GCLargeAlloc::FindBeginning due to this very assertion, as discovered and documented in Bug 596927, comment 11.

(Also another scary possibility that I have not properly addressed here is that the root cause of the FindBeginning failure in Bug 733807 is not these loops but instead the PageMap.  This would explain why I have so far had much difficulty recreated the scenario in a selftest.  Will investigate tomorrow; going to bed.)

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.