> >( >( so what's going on here
>
> the latest information shows that some non-numeric data is being
> parsed as a number ... maybe a wrong link pointer is being placed,
> like maybe a length field is being written as a pointer who knows
>
> the two regions of interest seem separate for me. maybe i can ferry
> enough information from one to another to discern a cause
i got a reprieve i can hold them near each other a little
> > > (Pdb) list
> > > 31 addr8 = memoryview(id).cast('Q')[0]
> > > 32 l8 = max((self.q[addr8]+self.idsize-1)//self.idsize,1) + 1
> > > 33 self.q[addr8] = self.q[0]
> > > 34 self.q[addr8+1] = l8
> > > 35 self.q[0] = addr8
> > > 36 -> self.fsck()
> > > 37 def alloc(self, data, replacing=[]):
> > > 38 self.fsck()
> > > 39 l8 = max((len(data)+self.idsize-1)//self.idsize,1) + 1
> > > 40 addr8 = 0
> > > 41 assert self.q[addr8] != 0
> > > (Pdb) p addr8
> > > 1
> > > (Pdb) p id
> > > b'\x01\x00\x00\x00\x00\x00\x00\x00'
so this is what was deallocated. there was an allocated region at
0x1<<3 ... i think? [.. addr8 = memoryview(id).cast('Q')[0] ...] yeah
the id is an address in quadwords.
now below i didn't see a region starting at 0x1 in the regions list.
:/ [scrolls down] oh no wait there totally was one :D :s
ok so here ummm it's working on address 1 quadwords O_O O_O O_O
> > > (Pdb) p self.q[addr8]
> > > 11
this is after address so this should be the link. it says the next one
is the region at 11<<3.
> > > (Pdb) p l8
> > > 4
this is the calculated length of the region in quadwords
> > > (Pdb) p addr8
> > > 1
> > > (Pdb) p l8
> > > 4
> > > (Pdb) p self.w[addr8*self.idsize:addr8+self.idsize+4*self.idsize]
> > > <memory at 0x7f0a3b9d9840>
> > > (Pdb) p
> > > self.w[addr8*self.idsize:addr8+self.idsize+4*self.idsize].tobytes()
> > > b'\x0b\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00k
> > > brown fox jum\x00\t'
and here's the raw data of the region. 0x0b is 11, the link to the
next deallocated region. 0x4 is the length of the region in quadwords
-- 32 bytes.
it looks reasonable at a glance but something obviously is wrong;
while trying to sleep i was wondering maybe the l8 quantity is
inconsistent. another thought is maybe quadwords vs raw lengths is
inconsistent, or somehow elsewise a disalignment. but usually it's
been because of a logic case i left out, like how the regions list
isn't updated during shrink.
> > >
> > > the 'k brown fox jum' content looks believable. additionally, the fsck
> > > prior to the deallocation passed [ :S ]
> >
> > (Pdb) down
> > > /home/karl3/projects/rep/rep/i.py(114)fsck()
> > -> assert l8 <= self.yq - addr8
> > (Pdb) list
> > 109 passed_regions.append(region)
> > 110 assert region[1] <= self.yq - addr8
> > 111 addr8 += region[1]
> > 112 else:
> > 113 l8 =
> > max((self.q[addr8]+self.idsize-1)//self.idsize,1) + 1
> > 114 -> assert l8 <= self.yq - addr8
> > 115 addr8 += l8
> > 116 assert addr8 == self.yq
> > 117 def shrink(self):
> > 118 self.fsck()
> > 119 unused = 0
> > (Pdb) p addr8
> > 4
so here we are at address 4, not address 1. glancing down to `p
regions` below, address 4 .. hrm ... [ ... regions.append([addr8,
self.q[addr8+1]]) ... ] ... there's no address 4. 4 is the length of
address 1.
so this might be a bug in fsck ??? ... 0442
regions[] only contains deallocated regions. this is a branch for an
allocated region. it's like the region after region 1 ...? (shouldn't
that be 5?)
i'm closer !!!!! ummmmmmmmmmmmmm 0444
so regions contains a region starting at 1. additionally,
passed_regions is empty. [this debugging session found left open it's
slightly possible it came from a different codebase slightly, but it
has the passed_regions local]. passed_regions is set when processing a
deallocated region >( so i don't know why addr8 is 4 ... yet !
what i can do is simulate the behavior of the function. addr8 started at 1.
YAY I FOUND A BUG !!!! yay bug :D
the regions are sorted in reversal, likely with intent to pop things
from it like a stack.
but region[0] is checked instead of popping or using region[-1]. i
modified the algorithm partly and didn't sufficiently propagate the
changes.
this does not fully explain the condition but it's part. it shows why
passed_regions is empty.
0448
here's new lines:
assert regions[-1][0] >= addr8
if regions[-1][0] == addr8:
0449
so i guess that what must have happened would have been uh
l8 = max((self.q[addr8]+self.idsize-1)//self.idsize,1) + 1
address 1 would have been treated as allocated, and the value
considered an allocated length. (11).
uhh ? but addr8 isn't 11+1=12. it's 4 :/ uhhh hehe oh but it's converted !
(Pdb) p max((11+self.idsize-1)//self.idsize,1) + 1
3
there we go. 3+1==4. so we found the bug! this was the bug!!
bug tracking is hard, little tiny footprints, but they're there !
> > (Pdb) p self.q[addr8]
> > 30809871133208422
> > (Pdb) p l8
> > 3851233891651054
> > (Pdb) p regions
> > [[11, 501], [1, 4]]
> > (Pdb) p passed_regions
> > []
