Bug #13333
spellcheck1 doesn't zero table memory
100%
Description
Having mostly ignored the wsdiff noise that ocasionally pops up between hlista and hlistb, I decided to reverse course and dig into it. I went down a few bad paths on trying to understand why there was wsdiff noise. I first modified the Makefile so the different targets used different intermediate file names, in case we were clobbering each other there. That, of course didn't change things. Next, I verified that the intermediate outputs were the same between runs. This allowed me to verify that the issue was in the output of the spellin1
binary, not in its inputs. The inputs were always (thankfully) the same between runs.
I then began a process of instrumenting the binary. I first verified that we were always reading the input the same across runs, which we were. Next, I manually dumped the output data in a way that was easier to diff to see what the differences were. It turned out we were always seeing a difference in a single word of the table
variable data. The hindex
table was always the same between runs. As a result, I ended up comparing the results of the append()
function. Critically we were always passing the same values to append. So I then looked at the before and after of updating entries.
Once I did that and looked at the results, things became clear. There was one entry in the table that had different values because they had different starting values. Looking more closely at how table
is allocated, we just malloc() it and rely on the contents to be the same. What's surprising is how consistently similar things are between runs with only a single index having a different value. However, as is clear, relying on this in and of itself is probably wrong and while it needs further understanding of the underlying mechanism, the stored hash in the table is probably not found due to the table having garbage in it for some entries (but not most).
Related issues