MPS issue job004041

TitleAssertion failure in fotest on ananll
Assigned userGareth Rees
DescriptionJenkins build #1580.1 on lii6ll [1] failed in ananll/cool/fotest:

ananll/cool/fotest: randomize(): choosing initial state (v3): 1347764879.
arena.c:1059: MPS ASSERTION FAILED: res == ResOK
AnalysisSome notes on the envelope of the problem:

1. Can't reproduce on xci6ll.
2. Can reproduce on lii6ll.
3. Not reproducible with the given seed.
4. With no seed, happens maybe one time in ten.
5. Not reproducible under GDB.
6. Not reproducible with ASLR turned off.

I was able to get a core dump, which shows that the error was ResRESOURCE and the backtrace looks like this:

#0 0x00007fa44a5290d5 in raise () from /lib/x86_64-linux-gnu/
#1 0x00007fa44a52c83b in abort () from /lib/x86_64-linux-gnu/
#2 0x00000000004028ff in verror (
    format=0x4d6272 "%s:%u: MPS ASSERTION FAILED: %s\n", args=0x7fff0895f180)
    at testlib.c:377
#3 0x0000000000402a52 in error (
    format=0x4d6272 "%s:%u: MPS ASSERTION FAILED: %s\n") at testlib.c:390
#4 0x0000000000402b60 in assert_die (file=0x4e38a8 "arena.c", line=1059,
    condition=0x4e28a5 "res == ResOK") at testlib.c:430
#5 0x0000000000495f43 in mps_lib_assert_fail (file=0x4e38a8 "arena.c",
    line=1059, condition=0x4e28a5 "res == ResOK") at mpsliban.c:87
#6 0x000000000049d8c3 in ArenaFreeLandAlloc (tractReturn=0x7fff0895f460,
    arena=0x1060000, zones=18446744069414584320, high=0, size=4096,
    pool=0x7fa4475551b0) at arena.c:1059
#7 0x000000000043df4e in PolicyAlloc (tractReturn=0x7fff0895f4d8,
    arena=0x1060000, pref=0x6f5160, size=4096, pool=0x7fa4475551b0)
    at policy.c:60
#8 0x000000000049e2fc in ArenaAlloc (baseReturn=0x7fff0895f558,
    pref=0x6f5160, size=4096, pool=0x7fa4475551b0) at arena.c:1114
#9 0x000000000046263d in SegAlloc (segReturn=0x7fff0895f620, klass=0x6fd558,
    pref=0x6f5160, size=4096, pool=0x7fa4475551b0, args=0x6f5120) at seg.c:65
#10 0x000000000049067a in MVTSegAlloc (segReturn=0x7fff0895f620,
    mvt=0x7fa4475551b0, size=4096) at poolmv2.c:1140
#11 0x00000000004905b0 in MVTSegFill (baseReturn=0x7fff0895f748,
    limitReturn=0x7fff0895f740, mvt=0x7fa4475551b0, fillSize=4096,
    minSize=2496) at poolmv2.c:675
#12 0x000000000048d1b8 in MVTBufferFill (baseReturn=0x7fff0895f748,
    limitReturn=0x7fff0895f740, pool=0x7fa4475551b0, buffer=0x7fa447555b88,
    minSize=2496) at poolmv2.c:737
#13 0x00000000004a6c95 in BufferFill (pReturn=0x7fff0895f798,
    buffer=0x7fa447555b88, size=2496) at buffer.c:605
#14 0x000000000043995b in mps_ap_fill (p_o=0x7fff0895f858,
    mps_ap=0x7fa447555be8, size=2496) at mpsi.c:1065
#15 0x0000000000401a38 in make (p=0x7fff0895f858, ap=0x7fa447555be8,
    size=2496) at fotest.c:45
#16 0x0000000000401812 in stress (size=0x4018d0 <randomSizeAligned>,
    alignment=16, pool=0x7fa4475551b0) at fotest.c:124
#17 0x000000000040150c in main (argc=1, argv=0x7fff08960ab8) at fotest.c:187

The problem is that fotest injects allocation errors by patching the MFS class's "alloc" function (so that the CBS fails, provoking the failover feature). But this affects all MFS allocations, including the ones used by the arena's free land's CBS. So this causes the failed call to LandFindInZones in ArenaFreeLandAlloc.

Is the AVER in ArenaFreeLandAlloc really right? The call to LandFindInZones calls through cbsFindInZones, cbsDelete, cbsBlockAlloc, PoolAlloc. How do we know this doesn't fail? In arena.c it's because we just successfully called arenaExtendCBSBlockPool, so we know there is at least a page of memory in the CBS's block pool, which must be enough to allocate one block. So the AVER is fine.
How foundautomated_test
Created byGareth Rees
Created on2016-09-05 10:33:34
Last modified byGareth Rees
Last modified on2016-09-05 13:17:59
History2016-09-05 GDR Created.


Change Effect Date User Description
192164 closed 2016-09-05 13:17:59 Gareth Rees When injecting allocation failures to test the fail-over land, don't also inject failures into the arena's free land's block pool.