MPS issue job003873

TitleMMQA test function/136.c failure
Statusclosed
Prioritynice
Assigned userGareth Rees
OrganizationRavenbrook
Descriptionmaster$ qa run test/function/136.c
% create arena: OK
% register thread: OK
!limit=80000
% Allocated 92 objects of size 4096
% Allocated 512 objects of size 8
% ASSERTION FAILED
!assert=true
!asserttext=Couldn't allocate one object of size 4096 in second pool
-----------------------------------------------------------------------------
FAILED TEST test/function/136.c

  harness = 1.0
  id =
    $Id: //info.ravenbrook.com/project/mps/master/test/function/136.c#3 $
  language = c
  link = testlib.o
  summary = MVFF low-memory test
SPECIFIED RESULTS
  completed = yes
MMQA OPTIONS
  MPS_INCLUDE_DIR = code
  MPS_LINK_OBJ = code/xc/mps.build/Debug/mps.build/Objects-normal/
                        x86_64/mps.o
  MPS_PRODUCT = mps
  PLATFORM = Darwin_13.4.0_i386__unix
RESULTS
  assert = true
  asserttext =
    Couldn't allocate one object of size 4096 in second pool
  limit = 80000
  seconds = 0
CONCLUSION
  FAIL failed on completed: wanted = yes, was absent
AnalysisThis is failing for the same reason as function/167.c (see job003872), namely that the test case is attempting to test that if you free an object in one MVFF pool then you can immediately allocate an object of the same size in another pool without hitting the commit limit. But as of change 184498 [1] an MVFF pool now keeps a fund of spare memory by default. It's necessary to turn this off for the test case to work.

Fixing that problem reveals a couple of bugs in the test case:

1. The test case frees a block of size 4096 in an MVFF pool and then tries to see if it can allocate a block of this size in an MV pool. But if that block is the *first* block in the MV pool then the MV pool will need to provide some memory for the span and block pools too, requiring 3 grains of memory from the arena to do so.

2. If the test case managed to only allocate one large block in the MVFF pool, it frees that block to provide space for the many small blocks, but then it has nothing left to free to provide memory for the MV pool.

To fix (1) we need to allocate something in the MV pool initially, so that the span and block pools have some capacity. To fix (2) we need to make sure we're allocating at least 2 big blocks.

Presumably these bugs weren't being encountered in the 32-bit MPS because memory never got so tight that there was just one or two big blocks being allocated in the MVFF pool. But in 64-bit everything is twice as big.
How foundautomated_test
Evidence[1] https:/​​/​​info.ravenbrook.com/​​info...cgi/​​perfbrowse.cgi?%40describe+184498
Test procedurefunction/136.c
Created byGareth Rees
Created on2014-10-10 14:02:19
Last modified byGareth Rees
Last modified on2014-10-20 17:18:40
History2014-10-10 GDR Created.

Fixes

Change Effect Date User Description
187182 closed 2014-10-10 14:04:41 Gareth Rees Fix MMQA test function/136.c:
* Turn off the spare memory on the MVFF pool so that it returns freed memory to the arena immediately.
* Allocate something in the MV pool initially so that the span and block pools have some capacity.
* Stop the test if there isn't room in the MVFF to allocate 2 big blocks.
* Change the test success criterion so that it passes on 64-bit.