| Title | MMQA test function/148.c failure |
| Status | closed |
| Priority | nice |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | $ qa run function/148.c % create arena: OK % register thread: OK % create format: OK % chain_create: OK % create ap(amc): OK % create SNC pool: OK % create ap: OK !com=61440 % push: OK % allocated id 16777216 at 0x10a009000. % allocated id 16777217 at 0x10a100000. % scan 16777216 at 0x10a009000. % fix 16777216[0] -> 16777217 % scan 16777217 at 0x10ac00000. % allocated id 16777218 at 0x10ab01000. !com=21405696 % collect... % scan 16777216 at 0x10a009000. % fix 16777216[0] -> 16777217 % scan 16777217 at 0x10c100000. !com=10878976 !inc1=1 % pop: OK % collect... % scan 16777216 at 0x10a009000. % fix 16777216[0] -> 16777217 % scan 16777217 at 0x10cc00000. !com=10878976 !inc2=1 % allocated id 16777219 at 0x10a009000. % allocated id 16777220 at 0x10a100000. % scan 16777219 at 0x10a009000. % fix 16777219[1] -> 16777220 % scan 16777220 at 0x10ac00000. % allocated id 16777221 at 0x10ab01000. % scan 16777219 at 0x10a009000. % fix 16777219[1] -> 16777220 % scan 16777220 at 0x10c100000. !inc3=0 % allocated id 16777222 at 0x10a100000. ... many allocations omitted ... % allocated id 16777722 at 0x10a100000. % scan 16777219 at 0x10a009000. % fix 16777219[1] -> 16777220 % scan 16777220 at 0x10cc00000. !inc4=0 % Destroyed arena. !completed=yes ----------------------------------------------------------------------------- FAILED TEST function/148.c ***** harness = 2.1 id = $Id: //info.ravenbrook.com/project/mps/master/test/function/148.c#5 $language = c link = testlib.o rankfmt.o summary = SNC scanning test SPECIFIED RESULTS inc1 = 1 inc2 = 0 inc3 = 1 inc4 = 1 MMQA OPTIONS MPS_INCLUDE_DIR = ../code MPS_LINK_OBJ = ../code/xci6ll/cool/mps.o MPS_PRODUCT = mps PLATFORM = Darwin_13.4.0_i386__unix RESULTS com = 10878976 completed = yes inc1 = 1 inc2 = 1 inc3 = 0 inc4 = 0 seconds = 5 CONCLUSION FAIL failed on inc4: wanted = 1, was 0 |
| Analysis | Note that the CONCLUSION is misleading because the failure on inc4 is reported but the *first* failure (the one we're really interested in) is the failure on inc2. Between "!inc1" and "!inc2", the allocation frame was popped but the object is still being scanned. Stepping through in the debugger shows that the pop is recorded as pending in the AP, but the pool is not notified until after the collection. See job003883 for detailed analysis of the cause. |
| How found | automated_test |
| Evidence | [1] https://info.ravenbrook.com/project/mps/master/test/function/148.c |
| Test procedure | function/148.c |
| Created by | Gareth Rees |
| Created on | 2014-10-11 01:23:41 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-10-20 17:17:03 |
| History | 2014-10-11 GDR Created. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 187224 | closed | 2014-10-12 15:20:57 | Gareth Rees | Fix scanning/walking for SNC: Record which segments are free and don't walk them (objects in these segments are dead). If a buffered segment has a pending pop, don't scan or walk objects beyond the address that's going to be popped to (these objects are also dead). Don't try to do a lightweight pop to an address that's not in the segment attached to the buffer -- the segment being popped to (and any other segments on the stack in between) are now dead, and the only way to mark them as being dead is to do a heavyweight pop. |