ppack is empty after pwin_step in MODIFY mode about cpic

[rodarima]

This comes from the new periodic_boundary function which uses only OPEN_MODIFY mode. The window is pointing to a ppack outside the block:

(gdb) f 4
#4  0x000055555556885a in pwin_step_modify (w=0x7fffffffdea0) at src/plist.c:1425
1425            assert(!ppack_isempty(&w->b->p[w->ip]));
(gdb) p w->ip
$1 = 26
(gdb) p w->b
$2 = (pblock_t *) 0x7fffd4600000
(gdb) p w->b[0]
$3 = {{{n = 104, npacks = 26, nfpacks = 26, next = 0x0, prev = 0x7fffec200000}, 
    _pad = "h\000\000\000\000\000\000\000\032\000\000\000\000\000\000\000\032", '\000' <repeats 17 times>, " \354\377\177", '\000' <repeats 89 times>}, 
  p = 0x7fffd4600080}

[rodarima]

The window has a wrong gip, which is too low, and the hi endpoint is not stopping the step operation.

(gdb) p w->gip
$20 = 794
(gdb) p w->ip
$21 = 26
(gdb) p w->b
$22 = (pblock_t *) 0x7fffd4600000
(gdb) p w->l->b->prev
$23 = (struct pblock *) 0x7fffd4600000
(gdb) p w->l->nblocks
$24 = 4
(gdb) p w->l->nmax * 4
$25 = 4096
(gdb) p w->l->nmax * 3
$26 = 3072
(gdb) p w->hi[0]      
$27 = 3098

[rodarima]

The gip is checked at the end of pwin_next to be consistent with the local ip and current block, so the previous step must have gone correctly. Did the gip got corrupted?

[rodarima]

No, the endpoint hi is wrong. We must use the max_packs not the nmax, as gip iterates over ppacks. That is the problem, in plist_open:

w->shi = (l->nblocks - 1) * l->nmax + l->b->prev->npacks;

This could be found by doing a coverage analysis.