| Title | MMQA test function/136.c failure |
| Status | closed |
| Priority | nice |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | master$ 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 |
| Analysis | This 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 found | automated_test |
| Evidence | [1] https://info.ravenbrook.com/info...cgi/perfbrowse.cgi?%40describe+184498 |
| Test procedure | function/136.c |
| Created by | Gareth Rees |
| Created on | 2014-10-10 14:02:19 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-10-20 17:18:40 |
| History | 2014-10-10 GDR Created. |
| 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. |