A binary field has no pin, so an Aria header clock is reported as a real difference #13

New issue

Open

opened 2026-09-28 05:51:27 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 05:51:27 -03:00

(Migrated from github.com)

bt-layer-measure pins a text difference by measuring the controls: at a
position they vary, the free region between their common prefix and suffix must
be one length, within a cap, and in the character class they used there. A
binary gets no such pin, because bytes carry no shape, so a coincidence in
position and magnitude is overlapping and has to be cleared by hand.

The mariadb gate run of 2026-09-28 shows what that costs. 32 of 167 differing
state paths come out real, almost all *.MAI, and the reason is one field.
Bytes 180 to 183 of an Aria index header, one based, are a four byte big endian
integer:

control        1790574106   0x6ab9fe1a
control-again  1790574278   0x6ab9fec6
control-third  1790574436   0x6ab9ff64
unit           1790574596   0x6aba0004
steps: 172, 158, 160

1790574106902134 / 10^6 is 1790574106, and that numerator is user.frm's
microsecond timestamp in the same directory, so the field is a wall clock
Unix second and SOURCE_DATE_EPOCH does not touch it. It moves in every
build, and the unit's value crossed into byte 181 where the three controls had
not, so it differs outside the floor.

More control captures cannot fix this. Byte 181 carries every 2^16 s, 18.2
hours; builds are about 160 s apart, so two consecutive controls straddle it
with probability about 0.24 percent and an expected single crossing needs on
the order of 410 consecutive control builds. Byte 180 carries every 2^24 s, 194
days. For any finite control set there is always a higher byte that did not
carry inside the window, and the spread required grows by 256 per byte. The
pull request that adds the tool says so, and says not to ask the build host for
more controls on this account.

Expected: the pin the tool already has for text, applied to a binary field. At
a run of differing offsets, read the enclosing fixed width big endian integer
and admit it only when all four hold:

the controls' values at that field increase strictly in capture order;
the unit's value exceeds every control's;
the unit's step over the last control lies inside the range of the controls'
own steps, 158 to 172 in the run above;
the field's lower bytes are among the offsets the controls vary at.

Every one of those is a measurement of the controls rather than an inference
about the unit, which is the standard the free region pin already meets, and it
is stricter than downgrading any monotone run, which was declined for being
inference. Under it the field above is noise legitimately, since 1790574596
beats 1790574436 by 160, and a planted value fails on the step range or on
failing to continue the sequence.

Not in Keel-Linux/buildtasks#11 on purpose. That pull request adds the
instrument and publishes its first measurement honestly, 32 paths recorded as
an open item pointing here, and no waiver written over them, which the tool
refuses in any case because a waiver only ever clears overlapping. Landing a
new inference rule in the same change as the instrument, in order to make the
instrument's first subject pass, is how the defect that pull request exists to
fix came about.

`bt-layer-measure` pins a text difference by measuring the controls: at a position they vary, the free region between their common prefix and suffix must be one length, within a cap, and in the character class they used there. A binary gets no such pin, because bytes carry no shape, so a coincidence in position and magnitude is `overlapping` and has to be cleared by hand. The mariadb gate run of 2026-09-28 shows what that costs. 32 of 167 differing state paths come out `real`, almost all `*.MAI`, and the reason is one field. Bytes 180 to 183 of an Aria index header, one based, are a four byte big endian integer: control 1790574106 0x6ab9fe1a control-again 1790574278 0x6ab9fec6 control-third 1790574436 0x6ab9ff64 unit 1790574596 0x6aba0004 steps: 172, 158, 160 `1790574106902134 / 10^6` is `1790574106`, and that numerator is `user.frm`'s microsecond timestamp in the same directory, so the field is a **wall clock Unix second and `SOURCE_DATE_EPOCH` does not touch it**. It moves in every build, and the unit's value crossed into byte 181 where the three controls had not, so it differs outside the floor. **More control captures cannot fix this.** Byte 181 carries every 2^16 s, 18.2 hours; builds are about 160 s apart, so two consecutive controls straddle it with probability about 0.24 percent and an expected single crossing needs on the order of 410 consecutive control builds. Byte 180 carries every 2^24 s, 194 days. For any finite control set there is always a higher byte that did not carry inside the window, and the spread required grows by 256 per byte. The pull request that adds the tool says so, and says not to ask the build host for more controls on this account. Expected: the pin the tool already has for text, applied to a binary field. At a run of differing offsets, read the enclosing fixed width big endian integer and admit it only when all four hold: 1. the controls' values at that field increase strictly in capture order; 2. the unit's value exceeds every control's; 3. the unit's step over the last control lies inside the range of the controls' own steps, 158 to 172 in the run above; 4. the field's lower bytes are among the offsets the controls vary at. Every one of those is a measurement of the controls rather than an inference about the unit, which is the standard the free region pin already meets, and it is stricter than downgrading any monotone run, which was declined for being inference. Under it the field above is `noise` legitimately, since 1790574596 beats 1790574436 by 160, and a planted value fails on the step range or on failing to continue the sequence. Not in Keel-Linux/buildtasks#11 on purpose. That pull request adds the instrument and publishes its first measurement honestly, 32 paths recorded as an open item pointing here, and no waiver written over them, which the tool refuses in any case because a waiver only ever clears `overlapping`. Landing a new inference rule in the same change as the instrument, in order to make the instrument's first subject pass, is how the defect that pull request exists to fix came about.