Project

General

Profile

Actions

Bug #13333

closed

spellcheck1 doesn't zero table memory

Added by Robert Mustacchi 8 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Category:
cmd - userland programs
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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

Related to illumos gate - Bug #10525: wsdiff output is not correct for a binary fileClosedAndy Fiddaman2019-03-10

Actions
Actions #1

Updated by Robert Mustacchi 8 months ago

  • Related to Bug #10525: wsdiff output is not correct for a binary file added
Actions #2

Updated by Electric Monk 8 months ago

  • Gerrit CR set to 1077
Actions #3

Updated by Robert Mustacchi 8 months ago

I tested this by checking the outputs of the hash checker and the input files and then ran several builds and verified that I no longer saw any wsdiff noise.

Actions #4

Updated by Electric Monk 8 months ago

  • Status changed from New to Closed
  • % Done changed from 70 to 100

git commit 2e8cdddb340293882c888e83152059f02ec5d59b

commit  2e8cdddb340293882c888e83152059f02ec5d59b
Author: Robert Mustacchi <rm@fingolfin.org>
Date:   2020-12-02T16:08:39.000Z

    13333 spellcheck1 doesn't zero table memory
    Reviewed by: Andy Fiddaman <andy@omnios.org>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

Actions

Also available in: Atom PDF