|Title||Asssertion "ring->next != NULL" in ztfm test|
|Assigned user||Gareth Rees|
|Description||The ztfm test case fails on OS X in the COOL (Debug) variety with the following output:|
/Users/gdr/info.ravenbrook.com/project/mps/branch/2013-10-21/cet-addr-to-obj/code/xc/Debug/ztfm: randomize(): choosing initial state (v3): 2113482590.
Create arena, size = 500000000.
INT_DYI(1): 5; DYI_INT(5): 1
Will make and transform sets of old nodes into new nodes. Set sizes: 1000, 10, 1, 1000, 10, 1, total: 4044.
perset: 1000, first: 0
Transform [260..574) to [1260..1574).
/Users/gdr/info.ravenbrook.com/project/mps/branch/2013-10-21/cet-addr-to-obj/code/ring.c:32: MPS ASSERTION FAILED: ring->next != NULL
GDR 2014-01-10: It also fails on w3i6mv with seed 10479569.
|Analysis||Running the failing test case under lldb shows that the assertion goes off in TransformCreate(). Here's the relevant part of the backtrace:|
frame #7: 0x000000010004e767 ztfm`RingCheck(ring=0x000000010fffdb50) + 487 at ring.c:32
frame #8: 0x000000010012bc5f ztfm`TransformCheck(transform=0x000000010fffdb40) + 1455 at trans.c:58
frame #9: 0x000000010012c144 ztfm`TransformCreate(transformReturn=0x00007fff5fbff2e0, arena=0x0000000100b91000) + 708 at trans.c:110
Reading the code shows that the RingCheck() fails because arenaRing is never initialized! In fact, this ring not used at all in trans.c , so it seems simpler to remove it rather than initialize it pointlessly. (Note also that if a Ring had a signature this mistake could not have happened.)
|Created by||Gareth Rees|
|Created on||2014-01-09 14:53:18|
|Last modified by||Gareth Rees|
|Last modified on||2014-01-11 22:06:09|
|History||2014-01-09 GDR Created.|
2014-01-10 GDR Add assertion failure on w3i6mv.
|183944||closed||2014-01-11 22:06:09||Gareth Rees||Remove arenaRing from struct mps_transform_s: it was not used.|