DEV Community: Morgan Ma

The Short Test Kept a Dead Cache

Morgan Ma — Sun, 11 Oct 2026 21:33:57 +0000

I will start with the conclusion, not the tool. Caching c_str across growth is a lifetime bug. A short unit test can still pass cleanly.

Later growth is what kills the cached pointer. Did your suite ever cross the capacity line? If it did not, the cache only looked stable.

A faster coding model does not relax object lifetime. The language rules did not get softer this year. That gap is why this small repro still matters.

The symptom

Picture a small label type in ordinary service code. It stores one string and one raw pointer. Every reset writes both the bytes and the cache.

Every suffix mutates the string and leaves the pointer. Short names still print, so the test stays green. Did that tiny append look harmless during review?

A long export name dies after one more append. AddressSanitizer then reports a heap use after free. The text of the suffix was never the real suspect.

This listing is a constructed lab repro only. It is not a story about a shipped outage. I am not claiming a customer impact number.

Compile it yourself and then judge the addresses. Snapshot each address as an integer before mutation. Comparing a dangling pointer value is not the goal.

#include <cstdint>
#include <cstdio>
#include <string>
#include <string_view>

struct NameTag {
  std::string storage;
  const char* cached = nullptr;

  void reset(std::string next) {
    storage = std::move(next);
    cached = storage.c_str();
  }

  void add_suffix(std::string_view suffix) {
    storage.append(suffix);
  }

  void force_growth() {
    const std::size_t extra = storage.capacity() - storage.size() + 1;
    storage.append(extra, 'x');
  }

  void print_cached() const {
    std::fputs(cached, stdout);
    std::fputc('\n', stdout);
  }
};

static void report(const char* label, const NameTag& tag,
                   std::uintptr_t before) {
  const auto after =
      reinterpret_cast<std::uintptr_t>(tag.storage.c_str());
  const int moved = before != after;
  std::printf("%s size=%zu cap=%zu moved=%d\n",
              label, tag.storage.size(), tag.storage.capacity(), moved);
}

int main() {
  NameTag short_tag;
  short_tag.reset("ok");
  const auto short_before =
      reinterpret_cast<std::uintptr_t>(short_tag.cached);
  short_tag.add_suffix("!");
  report("short", short_tag, short_before);
  if (short_before ==
      reinterpret_cast<std::uintptr_t>(short_tag.storage.c_str())) {
    short_tag.print_cached();
  }

  NameTag long_tag;
  long_tag.reset(std::string(64, 'a'));
  const auto long_before =
      reinterpret_cast<std::uintptr_t>(long_tag.cached);
  long_tag.force_growth();
  report("forced", long_tag, long_before);
  // Unsafe on purpose. Uncomment only under AddressSanitizer.
  // long_tag.print_cached();
  std::fputs("forced cache is stale; not reading it", stdout);
  std::fputc('\n', stdout);
}

Step 1: Freeze the failing length

Do not chase a random crash across the whole suite. Pin one input length before you pin the suffix. Change only one of those lengths at a time.

Which length first moves the c_str address? Write that number down before you change any code. A moving pointer is the bug you can measure.

A segfault is only the late and noisy symptom. I would log four fields on every single probe. Log the size, both capacities, and pointer equality.

If equality flips, stop reading the old pointer. Why read an address you already proved stale? The integer snapshot is the evidence, not the print.

Step 2: Build a sanitizer binary

Pretty logs are not a substitute for a hard fault. You want the sanitizer to trap the bad read. The command below is the local bar to clear.

c++ -std=c++20 -g -O1 -fno-omit-frame-pointer -fsanitize=address,undefined sso_cache.cpp -o sso_cache
./sso_cache

Why choose -O1 instead of a fully unoptimized build? Some reallocations hide when optimization is fully off. Why keep frame pointers in this sanitizer build?

The report then names a function you actually wrote. Did you forget debug symbols on the compile line? Then the report gives an address, not a source line.

Undefined behavior checks belong in that same binary. A bad pointer read is not your only nearby risk. Signed size math can sit quietly beside this bug.

Step 3: Split SSO from heap growth

Small string optimization is the liar in this story. A short string may store bytes inside the object. Then c_str points into that internal object buffer.

An append that still fits does not move it. Your unit test cheers, and you merge the patch. Cross local capacity and the bytes hit the heap.

Later growth can free that heap buffer entirely. The cached pointer still names the old block. That is use after free, not a compiler mystery.

Is the local capacity always fifteen characters long? Sometimes it is fifteen, and sometimes it is twenty-two. Another standard library can pick a third size.

Do not hardcode a threshold you found online. Measure capacity on the exact toolchain you ship. A blog number is not an ABI guarantee for you.

One long input is still not a proof of safety. A heap string can append without reallocating yet. Capacity may already be larger than the live size.

So grow until capacity actually changes underneath you. Then read the old pointer only under ASan. If it does not trap, you are not testing the bug.

Append one more byte than the spare capacity. That call forces reallocation without a hardcoded SSO size. The helper in the listing does exactly that.

Use this matrix before you trust any green run. Same binary, four seeds, two very different suffixes. The last column is the lie a short test tells.

seed length	suffix	what you should expect	what a short test misses
1	1 char	often no move under SSO	false confidence
15	1 char	may cross the local buffer	the real edge
16	1 char	heap already; slack may hide it	one long case is weak
64	force past capacity	pointer must move	this is the production shape

Step 4: Shorten the pointer lifetime

The fix is not a smarter cache of the pointer. The fix is a shorter lifetime for that address. Take the pointer at the use site instead.

void print_live(const std::string& storage) {
  std::fputs(storage.c_str(), stdout);
  std::fputc('\n', stdout);
}

Or store an offset and rebuild after each mutation. Prefer the use-site call whenever you can. An offset is easy to get wrong after erase.

A copied buffer is stable and costs an allocation. Reserve plus a cache is only a sized bet. Would you approve that bet in code review?

I would reject it and ask for the use-site call. The bet dies when a later suffix exceeds reserve. Production names are longer than the sample you tried.

This is a different bug from a view into a temporary. A temporary dies at the end of the full expression. This cache dies later, only when capacity changes.

Do not merge those two tests into one assertion. Each bug needs its own length story and oracle. A passing temporary test says nothing about growth.

Step 5: Treat the model as a suspect list

A model is a suspect list, not a verdict. That list can speed the first hour of debugging. It still cannot see the heap you actually have.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode's free model access can list those suspects for you. Think of SSO, iterator invalidation, or a moved-from string. The free server option can host a clean compile of the file.

I would not treat that machine as production hardware. I do not know its library, quota, or offer lifetime. So I will not invent those numbers in this draft.

I would ask one question of that extra compile. Does capacity move on the same lengths as yours? A model may suggest reserve and then cache c_str.

That patch passes the short test and fails later. Ask for three patches, then delete every raw cache. Any pointer kept across a non-const call must go.

You still need the sanitizer run after that edit. A fluent explanation is not evidence of safety. Did the patch name a capacity log, or only a vibe?

What this workflow will not prove

Do not trust a green run on one standard library. The three major libraries disagree on local capacity. A free server with another library is a second sample.

It is not a waiver for your production toolchain. Do not ask the model to confirm pointer stability. It cannot inspect your allocator or your heap.

Paste the capacity log and ask for the first retain. Then you delete that line and rerun the probe. If the model argues with the log, keep the log.

Do not disable ASan to get a clean screenshot. A silent binary is how this class of bug ships. If the free server image lacks sanitizer support, stop.

Compile the same probe on a machine that has it. Matching log lines across machines is still useful. A missing trap is not a successful test result.

Who should skip this

Skip this workflow if you cannot rebuild with sanitizers. The printf guard hides the crash on purpose. Without ASan, a lucky print can still be undefined.

Looking right in a terminal is not a proof. Skip this article if your real bug is a data race. Capacity logs will not catch two threads appending.

You need ThreadSanitizer, a mutex, or both tools. This walkthrough does not cover that race fix. Mixing those bugs will waste a full afternoon.

Skip cached pointers in parsers that retain input. If the caller mutates the source, your offset dies too. Own a copy, or end the borrow before the next write.

Document that bound next to the function, not in chat. Skip the free server as your only integration fleet. A shared free image can change under your feet.

I am not claiming that it will change tomorrow. This draft has no contract for duration or hardware. Keep the repro inside your own pipeline first.

Use the extra machine only as a second opinion. Who should not use the free box as a stamp? Anyone who needs a matched production ABI should not.

Step 6: Run this test plan

Save the listing as sso_cache.cpp before you edit it.
Build with the sanitizer command from step two.
Record moved for lengths 0, 1, 15, 16, 22, 23, 24, 64, and 4096.
Repeat with a one-byte suffix and a sixty-four byte suffix.
On any move, read the old pointer only under ASan.
Confirm the report names print_cached, not a mystery frame.
Replace the cache with a use-site c_str call.
Rerun the same matrix after that ownership change.

Pointer movement may remain, and that can be legal. Reading the old address cannot remain in the binary. Step eight is the real pass condition for this bug.

What stays true after the patch

So what should you remember after running this repro? Stability is a measured property of one toolchain. It is not a feeling you get from a short fixture.

Growth changes addresses even when the text looks fine. Small string optimization makes the short case lie. Want a second compiler for this same matrix?

MonkeyCode's free server option is enough to start. Bring sanitizer flags, or do not trust that run.

The Warning Died and the Length Field Lied

Morgan Ma — Sat, 10 Oct 2026 17:58:37 +0000

A silenced narrowing cast can still ship a truncated length.
I built a lab repro so you can watch that lie form.
Would you have merged the cast just to keep CI green?

The conclusion first

Reject oversized frames before you store a short length.
A green binary is not proof that the length still fits.
Ask a model for causes, never for a silencing patch.

The symptom I froze

The silenced program should print a stored length of 16.
The buffer should still hold 65552 payload bytes after the pack.
The accept check should return true, which ought to scare you.

How can a short length bless a much longer buffer?
No sanitizer fired, and no exception left the function.
The happy path used 12-byte frames, so it stayed green.

Why did every fixture stay under a 16-bit ceiling?
Nobody sent a payload past 65535, so the lie never printed.
A green suite can be a small-input suite in disguise.

Why the check passed

The check asked whether length was within the buffer.
Sixteen is inside 65552, so the predicate returned true.
Truncation forged a small length, and the guard believed it.

That's the pitfall I want you to remember.
A bounds check can pass because the length was damaged.
Did your last review look for that shape of bug?

The arithmetic, without drama

65552 is 0x10010, and a 16-bit store keeps 0x0010.
The high half vanishes, and 16 remains in the field.
The compiler can warn, unless a cast already hid it.

I'm walking a constructed listing, not a customer outage.
You should compile it, because my confidence is not your proof.
Treat every number below as something you can recalculate.

1. Freeze one bad line

Save the printed line before you rename the function.
I kept the triple stored=16, actual=65552, and accept=1.
If the line changes, you are debugging a different bug.

2. Cut until one file remains

I cut the story down until one main remained.
I kept one oversized size, not a loop of random sizes.
Did the false accept survive that cut, or did it vanish?

If the false accept survives, the bug lives in pack.
That cut should take minutes, and it removes three fake causes.
Threads, disks, and clocks were no longer in the story.

3. Make the narrowing fatal

Compile with -Werror=conversion before you edit a single line.
That flag turns the narrowing conversion into a failed build.
Why was that flag absent from the default debug target?

g++ -std=c++20 -Wall -Wextra -Werror=conversion -c frame_bug.cpp
echo "bug_compile=$?"
g++ -std=c++20 -Wall -Wextra -Werror=conversion -o frame_silenced frame_silenced.cpp
./frame_silenced

If this command fails, read the first diagnostic only.
The diagnostic should mention a conversion that may change the value.
Exact wording varies, so match the meaning, not the spelling.

An explicit static_cast will not trip -Wconversion at all.
That's why the silencing patch looks like a fix.
Don't add a cast just to reach the linker.

The silenced file should compile under that same flag.
Success here is the trap, not the all-clear.
A quiet build is the thing we are trying to distrust.

Listings you can compile

Start with the implicit bug, then build the silenced twin.
The first file should fail, and the second file should link.
The silenced build should print stored=16 actual=65552 accept=1.

That line is arithmetic, so confirm it on your compiler.
If your printout differs, stop and check the integer width.

// frame_bug.cpp: implicit narrowing. Expect -Werror=conversion to fail.
#include <cstdint>
#include <vector>

struct Frame {
  uint16_t len;
  std::vector<char> bytes;
};

Frame pack(const std::vector<char>& payload) {
  Frame frame;
  frame.len = payload.size();
  frame.bytes = payload;
  return frame;
}

int main() {
  std::vector<char> big(65552, 'x');
  return pack(big).len;
}

// frame_silenced.cpp: the cast hides the warning and keeps the lie.
#include <cstdint>
#include <iostream>
#include <vector>

struct Frame {
  uint16_t len;
  std::vector<char> bytes;
};

Frame pack(const std::vector<char>& payload) {
  Frame frame;
  frame.len = static_cast<uint16_t>(payload.size());
  frame.bytes = payload;
  return frame;
}

bool accept_buggy(const Frame& frame) {
  return frame.len <= frame.bytes.size();
}

int main() {
  std::vector<char> big(65552, 'x');
  Frame frame = pack(big);
  std::cout << "stored=" << frame.len
            << " actual=" << frame.bytes.size()
            << " accept=" << accept_buggy(frame) << "\n";
  return accept_buggy(frame) ? 0 : 1;
}

4. Ask for causes, not a patch

MonkeyCode is relevant here only as a guess list.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
I used free model access to list causes, not to edit code.

I forbade a patch, a refactor, and a style cleanup.
I did not claim a model name, because none was verified here.
I will not call it open source without a repository link.

Free model access is the only availability claim I will use.
A quota number would be a guess, so I will not print one.
A free server option is not a hardware spec sheet.

The replies were mixed, which is the useful part.
One reply blamed a data race in a single-threaded main.
Another blamed allocator reuse without a dangling pointer.

The tempting reply said to cast the size and continue.
Would you have taken that reply because it compiled?
Which guess can a single-threaded main even support?

I rejected the cast reply before I touched the file.
A helpful tone is not evidence, and it never was.
The printed numbers already pointed at a short store.

5. Put the file on a second machine

I'd place this file on a free server option next.
I want a different box, not a heroic specification.
I will not name a CPU, a region, or an uptime promise.

Those facts were not supplied as stable primary sources.
If the plan page differs, the plan page wins.
Check that page yourself before you script a job.

Copy the file, compile it, and compare the printed line.
If the second box prints a different length, stop.
You may be mixing ABIs, and that is a new bug.

6. Add the failing test before the fix

I wrote the expectation while the bug still passed.
The test sends 65552 bytes and demands rejection.
A test that only sends 12 bytes would rubber-stamp the lie.

Remember that 65535 must pass, and 65536 must fail.
This test is part of the lab listing, not a coverage report.
Run it, and do not trust a screenshot of my terminal.

// frame_fixed.cpp: reject first, then cast.
#include <cassert>
#include <cstdint>
#include <vector>

enum class Status { Ok, TooBig };

Status pack_checked(const std::vector<char>& payload, uint16_t* len) {
  if (payload.size() > 65535u) {
    return Status::TooBig;
  }
  *len = static_cast<uint16_t>(payload.size());
  return Status::Ok;
}

int main() {
  std::vector<char> symptom(65552, 'x');
  std::vector<char> edge(65536, 'x');
  std::vector<char> max_ok(65535, 'x');
  uint16_t len = 0;
  assert(pack_checked(symptom, &len) == Status::TooBig);
  assert(pack_checked(edge, &len) == Status::TooBig);
  assert(pack_checked(max_ok, &len) == Status::Ok);
  assert(len == 65535);
  return 0;
}

If the assert does not fire on the old function, your test is wrong.
Wire this file to the fixed function, not to the silenced one.
A test that calls pack_silenced will stay green forever.

7. Fix the contract, then allow the cast

I reject any payload larger than UINT16_MAX first.
Only then do I store the size in a uint16_t.
The cast is now a checked conversion, not a gag.

The receiver must not treat a shorter length as a valid frame.
A smaller length than the buffer is a protocol error here.
Equality with the original size is the check I want.

8. Re-run debug, optimized, and sanitized builds

I want three commands, and I want the same rejection.
Optimization must not revive a truncated store through new inlining.
Sanitizers may stay silent, because this bug is not a wild pointer.

Does that silence mean the program is safe?
No, it means you asked the wrong detector.
Warnings were the detector, and the boundary test is the lock.

g++ -std=c++20 -Wall -Wextra -Werror=conversion -O0 -o frame_dbg frame_fixed.cpp
g++ -std=c++20 -Wall -Wextra -Werror=conversion -O2 -o frame_opt frame_fixed.cpp
g++ -std=c++20 -Wall -Wextra -Werror=conversion -fsanitize=address,undefined -o frame_san frame_fixed.cpp
./frame_dbg && ./frame_opt && ./frame_san
echo "all_exit=$?"

A small decision table

I use this table when a warning and a model disagree.
It is a habit, not a score and not a benchmark.

What you see	Next move
Narrowing warning on a length field	Keep that warning fatal
Every fixture fits in the short field	Add one oversized payload
Model says cast and continue	Reject that reply
Bounds check uses the stored short length	Treat the check as suspect
Oversized payload returns TooBig	Review the other call sites
Debug and -O2 disagree	Stop and diff the checks

Read the row, then do only that next move.
Do not skip to a rewrite because the table feels slow.
Slow is cheaper than a frame parser that trusts a lie.

Limits you should say out loud

This file is a teaching repro, and your protocol may differ.
A 16-bit length is the stand-in, not a claim about your wire.
This repro assumes size_t is wider than 16 bits.

I did not measure throughput, latency, or cost per token.
I did not verify a token grant, a hardware SKU, or a duration.
Free access can be limited, changed, or removed without this page updating.

A model can sound sure while naming a race you do not have.
A second machine can hide an ABI mismatch if you skip the printout.
If your compiler lacks -Wconversion, do not assume you are safe.

I would not call this a security audit.
I would not paste secrets into the prompt to get a better guess.

Who should not use this flow

Skip it if you need a validated, signed build environment.
Skip it if the failing input contains private customer data.
Skip it if you cannot reduce the bug to a file you can share.

Skip it if the failure needs a logic analyzer, not a compiler.
A free server is a spare desk, not a certified lab.
A chat box is a bad place for a private crash dump.

What I want you to reuse

Freeze the bad line before you debate names.
Cut unrelated code until one translation unit remains.
Turn the relevant warning into an error before you edit.

Ask for three causes, and ban the patch.
Write the boundary test while the bug still passes.
Recompile on a second machine and compare one line.

One invitation, then stop

If you need a spare compile box, MonkeyCode's free server option can start you.
Read the live plan page before you automate against it.
Then run this repro, and keep the warning fatal.

That is the only invitation in this piece.
I will not pretend the tool found the bug.
The arithmetic found it, and the test kept it dead.

Would I ship the silenced file because CI turned green?
I would not ship it, not even with a green badge.
The tool only sped up a list of wrong guesses.

The Flush Printed a View After the Owner Died

Morgan Ma — Fri, 09 Oct 2026 14:29:48 +0000

A green debug run does not prove a view owns its bytes. Release can reuse that stack slot before the flush reads it. I start every split-brain crash with that suspicion.

This is a labeled reconstruction, not a ticket I closed. I did not run this harness for the numbers in this draft. The failure mode is still common enough to practice on purpose.

What broke

The exporter looks fine in an unoptimized test binary. A background flush can print junk names under -O2. Sometimes the process dies inside the stream insert for a view.

Why would optimization change a string that tests already checked? Because the view never held storage of its own. The temporary owner died at the end of the capture function.

1. Freeze the symptom

I keep one tiny input and one thread schedule. I do not add logs that allocate before the crash is stable. Extra allocations can hide the exact reuse I need to see.

I record the compiler, the flags, and the sanitizer set. I also record whether the flush ran on another thread. Those three notes stop me from chasing a different bug.

2. Bisect the flags

I rebuild the same source at -O0 and at -O2. I add AddressSanitizer and UndefinedBehaviorSanitizer to both builds. I leave frame pointers on so the stack stays readable.

g++ -std=c++20 -O0 -g -fno-omit-frame-pointer \
  -fsanitize=address,undefined repro.cpp -o repro_dbg
g++ -std=c++20 -O2 -g -fno-omit-frame-pointer \
  -fsanitize=address,undefined repro.cpp -o repro_rel
./repro_dbg ; echo dbg:$?
./repro_rel ; echo rel:$?

These commands are an unexecuted example for your own machine. I am not claiming a specific sanitizer line from a past run. Run them locally and keep the raw log beside the diff.

3. Draw the lifetime

Ask one blunt question at every return boundary. Who owns the bytes after this function returns to the caller? If the answer is only a view, mark that path as guilty.

Here is the broken capture shape from the lab harness. It is intentionally small so the bug cannot hide in helpers. Read it as a proposal you should compile, not as a trophy.

#include <iostream>
#include <string>
#include <string_view>
#include <thread>
#include <vector>

struct Sample {
  std::string_view name; // does not own bytes
};

Sample capture(int id) {
  std::string tmp = "job-" + std::to_string(id);
  return Sample{tmp}; // view dangles when tmp dies
}

int main() {
  std::vector<Sample> batch;
  batch.reserve(8);
  for (int id = 0; id < 8; ++id) {
    batch.push_back(capture(id));
  }

  std::thread flush([&batch] {
    for (const Sample& sample : batch) {
      std::cout << sample.name << "\n";
    }
  });
  flush.join();
  return 0;
}

The function builds a local string and returns a view into it. The local dies before the vector finishes storing that sample. The flush thread then reads storage that no longer exists.

Why did the unoptimized binary sometimes still look fine? The dead stack slot had not been overwritten yet. Optimization and the second thread reused that slot sooner.

4. Reject the plausible wrong fix

A coding assistant will often suggest a mutex around the flush. That can silence a data race that is not this bug. A lock does not extend the life of a dead temporary.

Another common patch copies the view into a second view. Copying a view copies the pointer, not the characters. You still have no owner after the capture function returns.

I write those wrong patches down so I do not reapply them. Then I ask which object is still alive at the use site. If nothing owns the bytes, the patch is only theater.

5. Fix ownership, then retest both builds

The sample should store a string, not a non-owning view. Views stay at the edges, where a caller still owns memory. I do not keep a view in a container that outlives its source.

struct Sample {
  std::string name; // owns its bytes
};

Sample capture(int id) {
  Sample out;
  out.name = "job-" + std::to_string(id);
  return out;
}

I rerun both optimization levels with the same sanitizer flags. I also add a test that reads the batch after capture returns. A test that only prints inside capture will hide this exact bug.

Should the flush still exist after the ownership fix? Yes, but it is no longer the prime suspect. I keep the thread so the schedule stays honest.

6. Where a free assistant and a free server fit

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I use free model access to list lifetime hypotheses, not to declare a verdict. I ask for three causes ranked by how fast the owner dies. I discard any fix that does not name a living owner.

A free server option can host the two-flag rebuild if your policy allows it. I still treat quota, hardware, and uptime as unknown here. I will not quote a token total I have not verified today.

Paste only a public harness into a hosted assistant. If the code is confidential, run the matrix on your own machine. Would a polished answer alone be enough to merge?

No, I still want the crash or the clean log in my terminal. If you want this checklist on a throwaway sample, start with that free access. Keep the merge on your sanitizer log, not on the model's prose.

7. Limitations

This harness will not catch every dangling use you can write. A custom allocator can confuse AddressSanitizer's default allocation story. Short-string optimization can also mask a nearby but different bug.

Do not use this workflow to support a benchmark claim. I published no timings, no token totals, and no hardware notes. Those numbers change, and I will not invent them here.

Skip the hosted path if your team needs a real air gap. Skip it if policy forbids sending source to a vendor tool. Skip it if you need a guaranteed queue or a named model.

I cannot promise those properties from this article alone. Also skip the drill when the bug is a logic error. Sanitizers will not notice a wrong business rule in the name.

You still need an assertion on the value you meant to export. Who checks that the exported name still matches the id? I do, with one expect after the flush joins.

What I keep

I ask who owns the bytes before I ask why it crashed. I compare unoptimized and optimized builds before I trust a green test. I store owning strings in objects that must outlive the read.

A view is a borrow, and a borrow needs a living owner. If you cannot point at that owner, you do not have a fix. Is this reconstruction enough to ship a production patch alone?

No, it is a drill for the questions, not a certificate of safety. Your tree still needs your log, your flags, and your own review.

The View Named a Dead Temporary

Morgan Ma — Thu, 08 Oct 2026 10:18:34 +0000

A green compile can still hand you a dead view. I hit that lie inside a tiny reconstructed lab. The crash was a plain C++ lifetime bug.

The log line looked fine in the first debugger stop. Two calls later the same line read freed memory. Why did a boring helper kill a calm test?

The view named bytes that had already died. I rebuild this case so you can rerun it. I am not reporting a measured production incident.

The helper that lied

Here is the whole trap in one function. Read the return type before you read the body. Does a view own anything in that signature?

#include <iostream>
#include <string>
#include <string_view>

// Reconstructed lab bug. This return is undefined behavior.
// Do not ship it. Expect ASan to report stack-use-after-return.
std::string_view label_for(int code) {
    std::string tmp = "code=" + std::to_string(code);
    return tmp;
}

int main() {
    std::string_view label = label_for(7);
    std::cout << label << "\n";
    return 0;
}

The local string dies when the function returns. The returned view still holds its old data pointer. The caller prints that pointer and walks off a corpse.

Six moves I reuse

I use six moves, and I keep their order. I do not open with a request for a patch. A patch before a hypothesis just moves the lie.

1. Freeze the symptom

I write the failure as one boring sentence. The print of that returned label reads freed stack memory. I pin that sentence in a comment above the file.

If a later edit does not match it, I stop. The symptom is the contract for the rest of the hunt. A clever patch that misses the sentence is noise.

2. Shrink until the lie is obvious

I delete every line that is not the crash. Can you still fail inside thirty lines of C++? If you cannot, you are debugging a story.

I want one file and one compile command. Anything else can wait until the small file fails. Shrinking is the move I skip when I am tired.

3. Make the sanitizer the judge

I trust AddressSanitizer more than my own eyes here. A quiet run can still be an inlining accident. So I force a frame and I keep symbols.

c++ -std=c++17 -O1 -g -fno-omit-frame-pointer \
  -fsanitize=address,undefined -o label_bug label_bug.cpp
ASAN_OPTIONS=detect_stack_use_after_return=1 ./label_bug

I expect ASan to report a stack use after return. If the run stays silent, I am not finished. I change the optimization level and I try again.

Your compiler may want a different use-after-return switch. Read that switch in your compiler manual before you trust silence. A missing detector is not a clean bill of health.

4. Ask for a hypothesis, not a rewrite

This is the only step that needs a model. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I paste the file plus the sanitizer summary.

I ask which object dies before the read. I do not ask the model to just fix it. A rewrite can hide a second lifetime bug.

A hypothesis is something I can fail in a test. That difference is the whole point of this step. MonkeyCode's free model access covers that one question.

The free server option covers the sanitizer compile. I do not treat either offer as a fixed quota. I read the current limit in the product UI.

A remembered token number is already a risk. Stale limits waste the session before the bug dies. I will not repeat a number I cannot verify today.

I will not call the project open source from memory either. Read the project page for the license and the tree. A remembered license is as stale as a remembered quota.

5. Prove it, then change ownership

I want a check that fails on the dangling return. I want that same check to pass after the fix. If I cannot name that check, I do not patch.

#include <cassert>
#include <string>
#include <string_view>

std::string owned_label(int code) {
    return "code=" + std::to_string(code);
}

int main() {
    std::string owned = owned_label(7);
    std::string_view label = owned;
    assert(label == "code=7");
    // Owner stays alive for the read above.
    // Later mutation must be read through owned, not label.
    owned.push_back('!');
    assert(owned == "code=7!");
    return 0;
}

The factory now returns an owning std::string object. The view is only a local alias of that owner. It must not escape the scope that owns the bytes.

If the caller needs the text later, return the string. If the caller only peeks, pass a view inward. Which of those two jobs is your helper doing?

6. Re-run, then lock the regression

I compile the fixed file with the same sanitizer flags. I also build the fix with no optimization and with O2. Why do I bother with two optimization levels?

Lifetime bugs love to hide behind inlining choices. One green binary is a coincidence, not a conclusion. I want both binaries to pass before I call it fixed.

c++ -std=c++17 -O0 -g -fno-omit-frame-pointer \
  -fsanitize=address,undefined -o label_ok label_ok.cpp
./label_ok
c++ -std=c++17 -O2 -g -fno-omit-frame-pointer \
  -fsanitize=address,undefined -o label_ok_o2 label_ok.cpp
./label_ok_o2

Then I keep the bad pattern in the test notes. Future me needs the trap, not only the patch. A deleted repro is how this bug returns next month.

A table I reuse on the next crash

I do not improvise the first probe anymore. I match the symptom to one row, then I stop. Extra theories are how I waste the afternoon.

Symptom	First probe	Likely lie	Fix shape
Crash just after return	ASan stack-use-after-return	View of a temporary	Return std::string
Crash after a long append	ASan heap-use-after-free	Pointer across realloc	Keep the owner
Garbage only at O2	UBSan plus two opt levels	Lifetime or aliasing	Narrow the API
Clean sanitizer, bad log	Print data() addresses	View rebound too early	Log the owner

I do not skip the row that matches the crash. I do not add a row just because it sounds clever. The table is a brake, not a brainstorm.

Patches I reject on sight

Models love a short return type of string_view. That signature is fine only when the caller owns the text. A factory that builds the text cannot return a view.

A common suggested fix stores the text in a static. That change can silence AddressSanitizer on this file. It also shares one buffer across every caller.

Is a quieter bug actually a real fix? No, the next call overwrites that shared buffer. Two threads assigning that static string create a data race.

I reject any function that returns a view of a local. I reject a patch I cannot explain in one sentence. If the model cannot name the owner, I discard it.

Where a free server fits

I use the free server as a clean compile box. I want a machine that does not share my local cache. A second toolchain catches a flag I forgot at home.

I upload only the repro file and the compile line. I never upload secrets, tokens, or customer logs. A compile box is not a place to park production data.

If the server image is older than my laptop, I note it. A miss on an old standard library is still data. It is not proof about my release compiler.

I match the language flag before I compare results. I match the sanitizer set before I trust a green run. Otherwise I am comparing two different compiled programs.

Who should skip this

Skip this if the bug needs your real production heap. A thirty-line file will not reproduce that class of failure. Shrink only after you know the crash is local.

Skip this if policy forbids pasting source into a host. Use a local compiler and keep the same six moves. The method does not require a hosted model at all.

Skip this if you need a certified compiler build. A free server image may not be that exact build. Do not pretend a mismatch is a release sign-off.

Skip this for kernel work or a sanitizer-hostile runtime. This lab assumes an ordinary hosted C++ toolchain. If ASan cannot link, this workflow is the wrong tool.

Limits I will not blur

This repro is a reconstruction, not a field report. I did not time the compile, and I did not benchmark a model. I am not naming a model build or a hardware shape.

Free model access and a free server option are the claims I rely on. Those claims can change without a blog post. Check the live page before you plan a long job.

A clean run here does not bless your whole codebase. It blesses one rule about ownership and views. Factories return owning strings, and views stay local.

I still let a model draft the hypothesis sentence. I do not let the model close the bug report. The sanitizer closes it, and the regression keeps it closed.

The cousin that looks like a win

There is a cousin bug that looks like a win. You store data from a heap string, then you append. The append reallocates, and the old pointer dies.

A short append may stay inside the small-string buffer. I force a long append so the heap path is real. If the pointer still looks fine, you missed the realloc.

#include <iostream>
#include <string>

int main() {
    std::string owned(64, 'a'); // already past the small-string buffer
    const char* raw = owned.data();
    owned.append(64, 'b'); // growth, not a tiny append
    // Bug: raw dangles if append reallocated. Read owned instead.
    std::cout << raw << "\n";
    return 0;
}

The sanitizer report now says heap use after free. The debugging moves do not change at all. You still name the owner before you touch the pointer.

I keep both traps in one folder on the compile box. One file returns a view of a temporary string. The other file keeps a pointer across a long append.

Same question every time: who owns the bytes now? If the answer is the temporary, you already lost. If the answer is the string might move, you already lost.

What I want left running

Run the bad file before you run the fixed file. Did ASan fail on the first binary and pass on the second? If not, your flags are wrong and your lesson is fake.

If you already have a free server session, use it for that pair. Paste the failing report back into the hypothesis prompt. Leave secrets off the box, and leave the model off the merge button.

The CAS Succeeded on a Recycled Generation

Morgan Ma — Wed, 23 Sep 2026 16:55:11 +0000

The lock-free path failed on reuse, not enqueue. Pointer-only CAS cannot see a recycled node. I treat every successful compare_exchange as a suspect now.

The symptom that looked impossible

The consumer printed a value nobody had pushed. Logs showed a matching pointer value. The compare_exchange call had returned true.

So who wrote the garbage into that node? I reconstructed it in a tight recycle loop. Two worker threads were already enough here.

Did I need a big machine for this? No extra hardware made the race clearer. I needed a tiny pool and a stalled load.

What I thought the code guaranteed

I started from a Treiber-style stack in the lab. Pop swapped head from node A to node B. A later push recycled A back into that list.

A returned with a brand new next pointer. The stalled pop still compared against pointer A. That pointer comparison was the entire bug.

Here is the broken sketch I used. Treat it as a lab reconstruction only.

// reconstruction: pointer-only Treiber stack (broken under reuse)
#include <atomic>
#include <cstdint>

struct Node {
    std::atomic<Node*> next{nullptr};
    int value{0};
};

struct Stack {
    std::atomic<Node*> head{nullptr};

    void push(Node* n) {
        Node* h;
        do {
            h = head.load(std::memory_order_acquire);
            n->next.store(h, std::memory_order_relaxed);
        } while (!head.compare_exchange_weak(
            h, n,
            std::memory_order_release,
            std::memory_order_acquire));
    }

    Node* pop() {
        Node* h;
        Node* n;
        do {
            h = head.load(std::memory_order_acquire);
            if (!h) return nullptr;
            n = h->next.load(std::memory_order_acquire);
        } while (!head.compare_exchange_weak(
            h, n,
            std::memory_order_release,
            std::memory_order_acquire));
        return h;
    }
};

Looks textbook, right? It is textbook stack code. Textbook code assumes nodes never return from a pool.

The reuse pool that made it real

I did not malloc on every single push. I kept a free list for the datapath. That choice is normal. It is also how ABA becomes real.

The free list handed A back to a pusher. Pop still held A in a local. Identity matched. Contents did not.

Walk the race in order. Number it. Do not skip a step.

Thread T1 loads head A and next B.
Thread T2 pops A, then pops B after that.
Thread T2 pushes X, then recycles A as head.
Head is A again, but A's next is X.
T1 compare_exchange swaps head from A to B.
B is free or live elsewhere, so the stack is corrupt.

The CAS succeeded on the old pointer. The generation was already gone. Why did my first tests miss that race?

The tests that lied

Single-thread tests never recycle under a stalled load. Address sanitizer missed the bug too. ASan tracks use-after-free, not legal reuse.

My pool was not calling free at all. Poisoned malloc would not have helped here. I needed a reuse stress, not a quiz.

Here is the harness I run in the lab. It is a reconstruction, not a production trace.

// reconstruction: reuse stress against a bounded node pool
#include <atomic>
#include <cstdint>
#include <random>
#include <vector>

void recycle(std::vector<Node*>& free_list, Node* n) {
    n->value = 0x7F7F7F7F; // poison after pop
    free_list.push_back(n);
}

Node* lease(std::vector<Node*>& free_list) {
    if (free_list.empty()) return nullptr;
    Node* n = free_list.back();
    free_list.pop_back();
    return n;
}

void reuse_stress(Stack& s,
                  std::vector<Node*>& local_free,
                  std::atomic<bool>& stop) {
    std::mt19937 rng{std::random_device{}()};
    while (!stop.load(std::memory_order_relaxed)) {
        Node* n = lease(local_free);
        if (!n) {
            n = s.pop();
            if (!n) continue;
            recycle(local_free, n);
            continue;
        }
        n->value = static_cast<int>(rng() & 0x3fffffff);
        int published = n->value;
        s.push(n);
        Node* out = s.pop();
        if (!out) continue;
        // invariant: a recycled slot must not surface stale identity
        if (out->value == 0x7F7F7F7F) {
            std::abort(); // reconstruction tripwire
        }
        (void)published;
        recycle(local_free, out);
    }
}

Run several workers against one tiny pool. Keep the pool smaller than the thread count. That pressure forces the ABA window open.

Did your CI do that to lock-free code? Mine did not at first. Happy-path tests are a trap here.

Build lines I actually type for this reconstruction:

g++ -std=c++17 -O2 -pthread aba_repro.cpp -o aba_repro
./aba_repro
g++ -std=c++17 -O1 -g -fsanitize=thread -pthread aba_repro.cpp -o aba_tsan
./aba_tsan

Thread sanitizer can still miss ABA here. ABA is not a data race on paper. It is a logic race on node identity.

A second bug sitting on the same path

I also read the payload before the CAS succeeded. That is another defect. The slot can be recycled during that load.

Is the value field even stable then? No, not under a pool. I moved the payload copy to after a successful tagged CAS.

If you only fix ABA, you can still tear a payload. Stamp the identity first. Then copy the value out.

Where an assistant helped, and where it did not

I asked an assistant for a lock-free stack sketch. It emitted the pointer-only CAS above. It also emitted tidy happy-path tests.

Those tests compiled on the first try. They never reused a node under a stalled pop. They could not see the generation gap.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I used MonkeyCode's free model access to draft candidates. I used the free server option to run the reuse harness. Neither step proved the CAS. The harness did.

Would I skip the assistant next time? No. I skip trusting its tests.

The tagged index fix

I needed identity plus generation in one CAS key. Packed pointers are cute and brittle. A pool index plus a stamp is clearer.

// reconstruction: index + generation CAS (pool-backed)
#include <atomic>
#include <cstdint>
#include <limits>
#include <vector>

struct Slot {
    std::atomic<uint32_t> next;
    int value;
};

struct Head {
    uint32_t idx;
    uint32_t gen;
};

constexpr uint32_t kNil = std::numeric_limits<uint32_t>::max();

struct TaggedStack {
    std::atomic<uint64_t> head;
    std::vector<Slot> slots;

    static uint64_t pack(Head h) {
        return (uint64_t(h.gen) << 32) | uint64_t(h.idx);
    }
    static Head unpack(uint64_t v) {
        return Head{uint32_t(v), uint32_t(v >> 32)};
    }

    explicit TaggedStack(std::size_t n) : slots(n) {
        head.store(pack(Head{kNil, 0}), std::memory_order_relaxed);
        for (auto& s : slots) s.next.store(kNil, std::memory_order_relaxed);
    }

    void push(uint32_t idx, int value) {
        slots[idx].value = value;
        uint64_t cur;
        do {
            cur = head.load(std::memory_order_acquire);
            Head h = unpack(cur);
            slots[idx].next.store(h.idx, std::memory_order_relaxed);
        } while (!head.compare_exchange_weak(
            cur, pack(Head{idx, unpack(cur).gen + 1}),
            std::memory_order_release,
            std::memory_order_acquire));
    }

    bool pop(int& out) {
        uint64_t cur;
        Head h;
        uint32_t nxt;
        do {
            cur = head.load(std::memory_order_acquire);
            h = unpack(cur);
            if (h.idx == kNil) return false;
            nxt = slots[h.idx].next.load(std::memory_order_acquire);
        } while (!head.compare_exchange_weak(
            cur, pack(Head{nxt, h.gen + 1}),
            std::memory_order_release,
            std::memory_order_acquire));
        out = slots[h.idx].value; // copy after the tagged CAS
        return true;
    }
};

The CAS key is now index and generation together. A recycled index fails the stamp. That is the entire fix in this lab.

Pop must bump generation too. Miss that bump and ABA returns. I missed it once in this reconstruction.

Do not copy the snippet blindly into a datapath. Wire pop, push, and recycle together. Then rerun the tiny pool until it holds.

Decision table I keep above the keyboard

Observation	Likely cause	Next probe
CAS true, value impossible	Recycled identity / ABA	Shrink the pool, add stamps
CAS true, list truncated	Lost update on next store	Recheck memory orders on next
Hang under load	Missing progress on weak CAS	Bound the spin, then yield
TSAN silent, values wrong	Logic race, not data race	Histogram generations
ASan silent, values wrong	Custom pool, no real free	Poison the slot on recycle
Value torn after a pop	Read before CAS succeeded	Copy payload after the stamp

If the pool never reuses, you will never see this. Lucky is not the same as correct.

Numbered debugging workflow I reuse

Freeze the node type and record index plus generation together.
Log CAS old and new packed words as one sample.
Force a tiny recycle pool, like four slots and eight threads.
Assert each pop value was published after the last recycle.
Histogram generations per index; a flat line means no stamp.
Only then change the algorithm under the same harness.

Skip step three and you will ship the textbook stack. I almost did that here.

Limitations

This tagged-index scheme needs a bounded pool. It does not replace a memory reclaimer. It does not prove linearizability for the stack.

It does not help if you CAS the wrong word. Epoch reclamation is a different tool. Hazard pointers are a different tool.

I did not implement those reclaimers here. An assistant will still emit pointer-only CAS. So will old blog posts on a tired night.

Who should not use this approach

Do not drop this into a packet path untested. Do not ship lock-free code from a unit test that never reuses. Do not pack pointers if your ABI allows non-canonical addresses.

If you can take a mutex, take a mutex. A latency budget is not a personality trait.

Students learning atomics should start with a mutexed stack. Then break it on purpose in a lab. Then add the stamp and the reuse harness.

What I will not claim

I will not quote a speedup from this note. I did not measure one for this reconstruction. I will not name models or invent a quota.

The lesson is smaller than a product pitch. A true CAS can still be wrong. Reuse is the missing test, not another happy path.

Stamp the identity or take a mutex. That is the whole retrospective.

The Checksum Passed on Uninitialized Padding

Morgan Ma — Tue, 22 Sep 2026 15:12:31 +0000

The checksum was hashing padding, not your fields.
That fact explains both the mismatch and the crash.
I rebuilt a small harness so you can see it.

What failed

Two processes hashed the same header and still disagreed.
Source, flags, and sizeof(Header) all matched on paper.
So which byte actually moved between the two runs?

I printed twelve bytes for sizeof on this x86_64 box.
Named fields used seven bytes in total.
Five bytes had no name in my source.

The first hypotheses were noise

Was it endianness across the two hosts?
Was it ARM alignment versus x86 alignment?
Those questions feel mature, but they were still wrong.

I swapped byte order in a unit test.
The mismatch did not move an inch.
I added a packed attribute next, and hashes matched.

Did packing fix the hash, or hide the holes?
Packing also misaligned uint32_t len on this ABI.
An aligned load of that field becomes undefined.

Treat model output as a queue

I wanted a cheap second list of guesses.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
I used MonkeyCode's free models and free server for that guess loop.

I asked why two header digests would diverge.
The reply named endianness, then packing, then memset.
I compiled each guess, ran it, and threw it out.

The model does not get a merge vote here.
A failing harness does, and that is the method.
Would you trust a packing attribute you did not measure?

Root cause

The compiler inserted padding after the first field.
I never initialized those bytes or named them.
A plain Header h; left stack garbage in the holes.

I set type, then len, then flags by hand.
The digest walked sizeof(Header) with a byte loop.
Process A hashed zeros; process B hashed leftover 0x7f bytes.

Same fields produced different object bytes and a different digest.
Packing deleted the holes, so the garbage vanished.
It also broke alignment for the 32-bit length field.

A memset of the struct can paper over this.
It still hashes ABI wallpaper, which I do not want.
The digest should see fields, not padding policy.

Debug workflow I will reuse

Follow this order and do not skip the dump.

Print sizeof(Header) and every offsetof for the fields.
Hexdump the whole object, not only the named fields.
Compare those dumps from both processes, byte by byte.
Park model guesses in a list and do not apply them yet.
Hash each field in a defined order and ignore holes.
Rebuild with ASan, then rebuild with packing turned off.

Step two is the one people skip.
They print fields with operator<< and call it done.
Padding never goes through operator<<, so remember that dump.

Lab harness

This reconstructed example is not a production dump.
Compile the file and run it twice in a row.

#include <cstddef>
#include <cstdint>
#include <cstdio>
#include <cstring>

struct Header {
    uint8_t  type;
    uint32_t len;
    uint16_t flags;
};

static uint32_t fnv1a(const void* p, size_t n) {
    const auto* b = static_cast<const uint8_t*>(p);
    uint32_t h = 2166136261u;
    for (size_t i = 0; i < n; ++i) {
        h ^= b[i];
        h *= 16777619u;
    }
    return h;
}

static uint32_t checksum_fields(const Header& h) {
    uint32_t x = fnv1a(&h.type, sizeof(h.type));
    uint32_t y = fnv1a(&h.len, sizeof(h.len));
    uint32_t z = fnv1a(&h.flags, sizeof(h.flags));
    x ^= y;
    x *= 16777619u;
    x ^= z;
    return x;
}

static void dump(const char* tag, const Header& h) {
    const auto* b = reinterpret_cast<const uint8_t*>(&h);
    std::printf("%s:", tag);
    for (size_t i = 0; i < sizeof(Header); ++i) {
        std::printf(" %02x", b[i]);
    }
    std::printf("\n");
}

int main() {
    alignas(Header) unsigned char junk[256];
    std::memset(junk, 0x7f, sizeof(junk));

    Header a;
    a.type = 1;
    a.len = 32;
    a.flags = 0x10;

    Header b;
    b.type = 1;
    b.len = 32;
    b.flags = 0x10;

    std::printf("sizeof=%zu\n", sizeof(Header));
    std::printf("off type=%zu len=%zu flags=%zu\n",
                offsetof(Header, type),
                offsetof(Header, len),
                offsetof(Header, flags));
    dump("a", a);
    dump("b", b);
    std::printf("raw a=%08x raw b=%08x\n",
                fnv1a(&a, sizeof(a)),
                fnv1a(&b, sizeof(b)));
    std::printf("fields a=%08x fields b=%08x\n",
                checksum_fields(a),
                checksum_fields(b));
}

On many stacks the two raw hashes will differ.
The field hashes should match on every run.
That split is the bug on one screen.

Build it with this boring compiler command.

c++ -std=c++17 -O2 -Wall -Wextra -Wpadding -o pad pad.cpp
./pad
./pad

Run the binary twice and compare the raw lines.
If they match, paint the stack with junk first.
I fill a throwaway buffer before the headers.

The junk buffer sits above Header a on purpose.
Now the holes have a color and the dump gets loud.
Ask one question while you stare at those 7f bytes.

Which of those bytes did your protocol actually define?

The fix I actually kept

I value-initialize the object, then hash fields only.

Header h{};
h.type = 1;
h.len = 32;
h.flags = 0x10;
auto digest = checksum_fields(h);

Header h{} zeros padding on this platform.
I still refuse to hash sizeof(Header) for a protocol.
Wire formats need a field list, not an ABI snapshot.

I also added a static layout check for surprises.

static_assert(offsetof(Header, type) == 0);
static_assert(offsetof(Header, len) == 4);
static_assert(offsetof(Header, flags) == 8);

That assert does not freeze padding across ABIs.
It only catches a surprise move in this build.
If you need a wire struct, write an explicit encoder.
Do not ship a packed attribute as your hash function.

A tiny encoder is boring, and that is the point.

std::array<uint8_t, 7> encode(const Header& h) {
    std::array<uint8_t, 7> out{};
    out[0] = h.type;
    std::memcpy(&out[1], &h.len, 4);
    std::memcpy(&out[5], &h.flags, 2);
    return out;
}

Hash out.data() and out.size(). Never hash &h.
Endianness now lives in one function you can test.
Padding does not get a vote anymore. See the difference?

Decision table

Use this table before you touch attributes.

Move	Hash stable?	Alignment safe?	Use as protocol?
Initialize, then hash `sizeof`	maybe	yes	no
Packed struct, hash `sizeof`	often	no	no
`memset`, then hash `sizeof`	often	yes	no
Field-by-field digest	yes	yes	yes
Explicit encoder buffer	yes	yes	yes

Maybe means it depends on leftover stack bytes.
Often means you hid the holes without defining them.
Only the last two rows count as a design.

Limitations

This is not a cryptography article at all.
The FNV-1a loop is a detector, not a boundary.
Do not paste proprietary headers into any remote tool.

Layout is ABI specific, even for this tiny struct.
x86_64 System V is not your MCU firmware ABI.
ASan will not always flag padding in a byte loop.
Defaulted equality can also read those padding bytes.

The free compile loop is for throwaway guesses only.
It is not an SLA and not your release builder.
Secrets, customer traces, and keys stay on your machine.

Who should not use this approach

Skip the remote guess loop if the struct is private.
Skip packing if you load fields with SIMD or atomics.
Skip memset if a constructor must actually run.

If you need a stable wire hash, write a schema.
If you need speed, hash the encoder buffer you built.
Do not fix padding by deleting it in a public header.

What I keep from this

Print the holes, name them, then stop hashing them.
Models will offer packing first, so ask for a dump instead.
Did the digest match because fields matched, or because garbage matched?

Your local compiler is enough to run the harness.
I only needed a disposable queue of wrong answers.

The Window Treated Wraparound as a Stale Packet

Morgan Ma — Mon, 21 Sep 2026 13:22:32 +0000

A sixteen-bit sequence window can reject good packets. Mine did that after a quiet wrap. The unit tests never crossed 65535, so they stayed green.

I reconstructed the failure in a local harness. I did not invent production metrics. Do you trust a window that never wrapped in CI?

The core miss

Packets arrived in order on a ring counter. The decoder looked healthy in traces. The log still shouted stale_seq and dropped them.

Last accepted sequence sat near 65500. New sequences arrived as 20, 21, 22. Why would twenty look older than sixty-five thousand?

Because I compared them as plain integers. I did not compare them as a ring.

Where the draft came from

I wanted a tiny deduper for binary telemetry frames. I asked a coding model for a first helper. I used MonkeyCode for that draft only. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Free model access and the free server option were enough for a stub. They were not enough for a wrap proof.

Labeled example. This is the broken check I compiled.

// Broken: treats wrap as a jump into the past.
bool is_fresh(uint16_t seq, uint16_t last) {
    return seq > last;
}

Looks honest, right? Tests used seq = 1, 2, 3, 4. Every assert passed. I never asked for a wrap fixture. That miss was mine.

Symptom to evidence

I did not start with protocol theory. I started with printed numbers.

Print seq and last as decimal and hex.
Print int16_t(seq - last) as a signed delta.
Dump the last sixteen accepted values.
Replay the same pair against a wrap fixture.
Fail the build if the ring delta disagrees.

The signed delta told the truth fast. seq - last was 20 minus 65500. That is a large negative. The ring delta is +56. See the gap?

A wrap fixture you can compile

Do not argue with a log line. Make the wrap fail in one file.

#include <cassert>
#include <cstdint>
#include <iostream>

bool is_fresh_broken(uint16_t seq, uint16_t last) {
    return seq > last;
}

// Ring check: forward distance must stay in the lower half.
bool is_fresh_ring(uint16_t seq, uint16_t last) {
    uint16_t delta = static_cast<uint16_t>(seq - last);
    return delta != 0 && delta < 32768u;
}

int main() {
    uint16_t last = 65500;
    uint16_t seq = 20;

    std::cout << "broken " << is_fresh_broken(seq, last) << "\n";
    std::cout << "ring   " << is_fresh_ring(seq, last) << "\n";
    std::cout << "delta  " << static_cast<uint16_t>(seq - last) << "\n";

    assert(!is_fresh_broken(seq, last));
    assert(is_fresh_ring(seq, last));

    last = 20;
    assert(!is_fresh_ring(20, last));  // duplicate
    assert(!is_fresh_ring(10, last));  // behind on the ring
    assert(is_fresh_ring(21, last));   // next value

    std::cout << "wrap fixture ok\n";
}

Keep the build boring. One translation unit. No extra flags.

g++ -std=c++17 -Wall -Wextra -Wconversion -o wrap_seq wrap_seq.cpp
./wrap_seq

Broken returns false. Ring returns true. That is the whole bug.

What the green tests hid

The original tests were not wrong on their inputs. They were incomplete on the type. uint16_t is a ring. A short increasing list is not a ring.

I added three cases after the first fail. Each case is one assert. That is the whole suite I needed.

Monotone increase far from the modulus.
Duplicate of last must drop.
Forward wrap, such as 65500 then 20.
Backward wrap, such as 20 then 10.

Did the model propose case three? Not in my draft. Would I have noticed without printing hex? Probably not.

Decision table for the next review

Use this table before you keep a comparison. Fill it with your real width.

Pair (`last` -> `seq`)	Integer `>`	Ring delta	Keep?
10 -> 11	true	1	yes
10 -> 10	false	0	no
10 -> 9	false	65535	no
65500 -> 20	false	56	yes
20 -> 65500	true	65480	no

The third and fourth rows are the trap. Integer order and ring order disagree there. If your tests never hit those rows, your tests are theatre.

Numbered debug workflow I reuse

This is the reusable part. The product is incidental.

Freeze one failing pair of numbers from logs.
Write those two numbers into a unit test first.
Print unsigned values, hex values, and the modular delta.
Classify the pair with the table above.
Only then change the comparison.
Re-run the wrap fixture under -Wconversion.

Why print hex? Because 65500 does not look like 0xffdc in your head. The hex makes the modulus obvious. Why freeze the pair first? Because a moving capture will gaslight you.

The fix I actually kept

I did not switch to int and pray. I did not widen the field on the wire. I subtracted in the unsigned domain and tested the half range.

bool is_fresh_ring(uint16_t seq, uint16_t last) {
    uint16_t delta = static_cast<uint16_t>(seq - last);
    return delta != 0 && delta < 32768u;
}

Half range is a choice, not a law. It assumes reordering stays below 32768. My stream is in-order telemetry. That assumption holds here. It will not hold for a lossy UDP mesh. Know your reorder bound.

I also stopped treating “model wrote a test” as coverage. A generated test that never wraps is a comment. Compile it. Then mutate the counter.

Command notes for the same harness

Run the fixture under sanitizers once. Do not skip that on a “pure logic” file.

g++ -std=c++17 -fsanitize=address,undefined -o wrap_seq wrap_seq.cpp
./wrap_seq

Then force the wrap in a tiny loop. Watch the first failure index.

uint16_t last = 0;
for (uint32_t i = 1; i < 70000; ++i) {
    uint16_t seq = static_cast<uint16_t>(i);
    if (!is_fresh_ring(seq, last) && seq != last) {
        std::cerr << "fail at i=" << i << "\n";
        break;
    }
    last = seq;
}

If is_fresh_broken sits in that loop, it dies at 65536. That number should have been in the first review. It was not.

Limitations

This write-up is a comparison postmortem. It is not a protocol design guide. Sixteen-bit sequence numbers are a constraint I inherited. They are not a recommendation.

The half-range test drops far-future jumps. That is intended for my in-order path. It is wrong if you must accept large gaps. It is also wrong if duplicates can arrive after a full half window.

I did not benchmark throughput. I did not claim a latency win. I only claimed the broken integer compare fails a wrap fixture. Sanitizers will not catch this by themselves. The values are defined unsigned arithmetic. You still need the fixture.

Free model drafts will happily emit seq > last. They pattern-match textbook loops. They do not owe you modular arithmetic. If you paste the helper and ship, you own the wrap.

Who should not use this approach

Do not copy this check into crypto windows. Do not copy it into authenticated replay defenses. Those need a spec, not a blog delta.

Skip this if your sequence field is already 32 or 64 bits and cannot wrap in the process lifetime. Skip this if a library already implements RFC-style serial number comparison and you can call it. Skip this if you cannot print the failing pair. Guessing without numbers is how I wasted the first hour.

Also skip the “generate tests and relax” loop. If the model never saw 65535, the suite cannot save you. You still write the wrap row.

What I keep from the mess

Short counters lie at the modulus. Green tests can lie with them. Print the modular delta before you rewrite the helper.

I still use a free model for boilerplate. I do not use it as evidence. The evidence is the fixture above. Steal that fixture if you maintain a similar window. The rest is optional.

The Empty Check Passed on a Full Ring

Morgan Ma — Sun, 20 Sep 2026 11:31:33 +0000

The ring reported empty after a full lap. Full and empty shared one modulus check. I lost every payload and still kept green tests.

Why did review miss this quiet bug? The happy path never filled the whole buffer.

The Symptom

I filled a four-slot ring inside a unit test. I pushed four times and never popped once. Then empty() returned true and dropped the batch.

There was no crash and no sanitizer line. CI never failed an assert on this path.

The alias is defined behavior, so UBSan stayed quiet. The only signal was a missing payload later.

Does that failure sound like a data race? It was not a race in this file.

I had one thread and one tight loop. I also had one copied empty predicate.

Build the Smallest Liar

Follow this sequence without skipping a dump. Do not start with a million slot ring.

Build a ring whose capacity is a tiny power of two.
Push exactly cap items with no intervening pops.
Call empty() before you pop a single item.
Watch empty() return true while live bytes remain.

I keep the liar in a file named ring_empty_lie.cpp. The core of the liar sits below this paragraph.

#include <cstddef>
#include <iostream>
#include <vector>

struct Ring {
    std::vector<int> buf;
    std::size_t cap;
    std::size_t r = 0;
    std::size_t w = 0;

    explicit Ring(std::size_t n) : buf(n, 0), cap(n) {}

    // Bug: modulus equality cannot tell full from empty.
    bool empty() const { return (w % cap) == (r % cap); }

    void push(int v) {
        buf[w % cap] = v;
        ++w;
    }

    bool pop(int& out) {
        if (empty()) return false;
        out = buf[r % cap];
        ++r;
        return true;
    }
};

int main() {
    Ring ring(4);
    for (int i = 1; i <= 4; ++i) ring.push(i);
    std::cout << std::boolalpha
              << "empty=" << ring.empty()
              << " w=" << ring.w
              << " r=" << ring.r << "\n";
    int x = 0;
    int n = 0;
    while (ring.pop(x)) ++n;
    std::cout << "popped=" << n << "\n";
    return n == 0 ? 1 : 0;
}

Compile the file with sanitizers and low optimization.

g++ -std=c++17 -O1 -g -Wall -Wextra -fsanitize=address,undefined \
    -o ring_empty_lie ring_empty_lie.cpp
./ring_empty_lie
echo $?

You should see empty=true and popped=0 on stdout. The process exits with status one here. That print shows the entire protocol bug.

Walk the Cursors

Dump cursor state at the failing assert. Do not guess those residues from memory.

Print raw w and r before any modulus.
Print w % cap and r % cap after that.
Print how many pushes you actually issued.
Compare occupied w - r against the cap.

After four pushes, w is four and r is zero. w % 4 is zero and r % 4 is zero.

The predicate says empty with four live slots. Occupied is four, so the check disagrees.

Who holds the truth in this dump? The occupied count holds the real truth. The modulus check is the real liar.

On larger rings the same lie waits. It only needs one exact capacity fill. Most of my tests stopped one below capacity.

Root Cause

I wanted one cheap empty check in the hot path. I copied the textbook head equals tail rule. I then stored unbounded cursors and reduced them with modulus only inside the check.

The head equals tail rule needs a gap. It fails when full wraps to the same residues.

I left no unused gap slot in the ring. I also skipped a separate occupancy count. Full and empty became the same picture.

Was this undefined behavior under the standard? No, it was only a wrong invariant.

Sanitizers do not know your ring protocol. They only know invalid memory use here. This bug never left the ring object.

Wrong Fixes I Almost Shipped

I almost added a boolean is_empty flag. That flag drifts as soon as two writers exist.

I almost used w minus r with 32-bit cursors. That form wraps too, just much later.

I almost kept modulus and reserved one slot. That design works if full is tested.

I still needed a test that fills to the new full. Without that test I would ship the next lie.

Debugging Sequence I Now Reuse

I run these steps on every silent drop. I refuse to start this hunt with threads.

Shrink capacity to four or eight slots.
Drive exact fills for cap-1, cap, and cap+1.
Record cursors on every push and every pop.
Assert w minus r against the visible occupancy.
Add threads only after the single-thread oracle is mean.

Why start with this brutal step order? Tiny rings lap inside a single test.

Huge rings hide the residue collision for days. Threads on a lying empty() only add noise.

Artifact: Oracle Asserts and a Decision Table

These are proposed tests, not a production incident dump.

#include <cassert>
#include <cstddef>
#include <vector>

struct Ring {
    std::vector<int> buf;
    std::size_t cap;
    std::size_t r = 0;
    std::size_t w = 0;

    explicit Ring(std::size_t n) : buf(n, 0), cap(n) {}

    std::size_t occupied() const { return w - r; }
    bool full() const { return occupied() == cap; }
    bool empty() const { return occupied() == 0; }

    bool push(int v) {
        if (full()) return false;
        buf[w % cap] = v;
        ++w;
        return true;
    }

    bool pop(int& out) {
        if (empty()) return false;
        out = buf[r % cap];
        ++r;
        return true;
    }
};

int main() {
    Ring ring(4);
    int x = 0;
    assert(ring.empty());
    assert(ring.push(1) && ring.push(2) && ring.push(3));
    assert(!ring.full());
    assert(ring.push(4));
    assert(ring.full());
    assert(!ring.empty());  // the old check failed here
    assert(ring.occupied() == 4);
    assert(!ring.push(5));  // must reject
    assert(ring.pop(x) && x == 1);
    assert(ring.push(5));
    assert(ring.occupied() == 4);
    return 0;
}

I pin this decision table next to the test.

Observation	Likely cause	Next probe
empty() after exactly cap pushes	residue collision	print w, r, w%cap, r%cap
missing payload, no crash	overwrite or false empty	shrink cap, replay
ASan silent, test green	protocol bug, not UB	add occupancy oracle
fails only on long soak	32-bit cursor wrap	64-bit cursors plus tests
fails only with threads	real race on r/w	TSan after the oracle exists

Keep the table beside the failing binary. It beats rereading the same cursor dump.

Commands I Actually Type

I want a failing binary before any theory. Then I want a log of both cursors.

g++ -std=c++17 -O1 -g -fsanitize=address,undefined -o ring_fix ring_fix.cpp
./ring_fix

g++ -std=c++17 -O1 -g -fsanitize=thread -o ring_tsan ring_fix.cpp
# only after the single-thread oracle is in place

GDB helps when the assert fires too late.

gdb -q ./ring_empty_lie
(gdb) break Ring::empty
(gdb) run
(gdb) print w
(gdb) print r
(gdb) print cap
(gdb) print (w % cap) == (r % cap)

Ask the debugger the same occupancy question. Do not ask your memory for residues.

Where a Scratch Model Fits

I still write the occupancy oracle by hand. I only want extra negative cases after that.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I draft fill-boundary tests with MonkeyCode free model access. I compile throwaway variants on the free server option.

I paste every candidate into the local sanitizer build. The model does not get to decide green.

Ask it for cap-1, cap, and cap+1 cases. Ask it for a wrap after a single pop.

Do not ask it to certify the ring. You own the occupancy assert in review.

Need a spare box for those extra cases? The free server option is one path. Keep the verdict on your own machine.

Limitations

This workflow does not catch a true data race. TSan comes after the sequential oracle exists.

Occupancy w minus r assumes r never outruns w. Thirty-two bit cursors still wrap under long soaks. Use sixty-four bit positions unless lifetime is proven.

Generated tests are only the cases you named. They omit the case you did not describe.

A free model will repeat head equals tail from blogs. That is how I got the first lying check.

The free server is not your release builder. Do not put secrets on a shared scratch box. Do not treat a remote compile as a sanitizer run.

Who Should Not Use This Approach

Skip it if you cannot shrink the ring. Skip it if you ship without a local ASan build.

Skip it if you need a proved wait-free queue. Skip it if packed cursors need a different model.

Do not use generated tests as the only gate. Do not skip the occupancy oracle after a clean model reply.

What I Keep

I keep three fills in every ring test. I keep occupied() next to empty() in the header.

I keep capacity tiny until the protocol is mean. I keep sanitizers on the laptop that signs off.

The modulus check was cheap in the hot path. It was also a liar under an exact fill. Cheap predicates still need an occupancy oracle.

The Fast Path Read a Stale Frame Header

Morgan Ma — Sat, 19 Sep 2026 09:33:58 +0000

The production path can fail while every unit test stays green. I rebuilt a small frame reader that proves it. Would you catch a torn header without a second thread?

The Core Failure

I started from a quiet symptom, not a crash. Frames looked complete, then a length field jumped backward. That is a data race in disguise, not a parser bug.

ASan stayed silent on my first single-thread harness. TSan flagged the overlap on the second run. That gap is the lesson I keep relearning.

The Setup I Used

This walkthrough is a reconstructed teaching case on purpose. It is not a postmortem from a named employer. The types stay small so you can compile them.

I kept one reusable buffer for a cheap fast path. The generated sketch made that same reuse choice. Does that pattern look like your last review?

// Labeled example: reconstructed harness, not production code.
#include <atomic>
#include <cstdint>
#include <cstring>
#include <iostream>
#include <span>
#include <thread>
#include <vector>

struct Slot {
    std::vector<std::uint8_t> bytes;
    std::atomic<bool> ready{false};
};

static void write_frame(Slot& slot, std::uint32_t id, std::uint32_t n) {
    slot.ready.store(false, std::memory_order_release);
    slot.bytes.resize(8 + n);
    std::uint32_t header[2] = {id, n};
    std::memcpy(slot.bytes.data(), header, 8);
    std::memset(slot.bytes.data() + 8, static_cast<int>(id), n);
    slot.ready.store(true, std::memory_order_release);
}

static bool read_fast(Slot& slot, std::uint32_t expect_id) {
    if (!slot.ready.load(std::memory_order_acquire)) {
        return true;  // idle is not a failure in this sketch
    }
    // BUG: span aliases the recycled buffer. No snapshot.
    std::span<const std::uint8_t> view{slot.bytes};
    if (view.size() < 8) {
        return false;
    }
    std::uint32_t id = 0;
    std::uint32_t n = 0;
    std::memcpy(&id, view.data(), 4);
    std::memcpy(&n, view.data() + 4, 4);
    if (id != expect_id) {
        return false;
    }
    if (view.size() != 8 + n) {
        return false;
    }
    for (std::size_t i = 0; i < n; ++i) {
        if (view[8 + i] != static_cast<std::uint8_t>(expect_id)) {
            return false;  // payload from another frame
        }
    }
    return true;
}

Symptom First, Theory Later

I refused to start with a redesign. I wanted the lie on record. What did the reader actually observe?

Log the header id and the first payload byte together.
Keep the writer on a tight recycle loop.
Pin the reader to a std::span, not a copy.
Run one thread until you feel falsely safe.

The single-thread run stayed clean for thousands of frames. That is how the false confidence forms. Have you stopped at that green bar before?

# Labeled commands: local check, not a claimed benchmark.
c++ -std=c++20 -O1 -g -fsanitize=address -o frame_asan frame.cpp
./frame_asan

ASan reported nothing useful on that path. The bug is a schedule, not a use-after-free. Address sanitizers do not invent extra threads for you.

Blind Alleys I Walked

I blamed endian conversion first. The dump looked swapped on a bad frame. That was a torn four-byte mix, not a byte-order bug.

I blamed std::vector reallocation next. Resizing in place can still reuse storage. The span outlived the logical frame, not the allocation.

I blamed memory_order_relaxed after that. Stronger flags did not freeze the bytes. The reader still held a view into a mutating slot. Why would an atomic flag protect the payload?

Make the Overlap Inevitable

I added a writer that never rests. I added a reader that never copies. Then the failure stopped being rare.

// Labeled example: adversarial schedule for the teaching harness.
int main() {
    Slot slot;
    std::atomic<bool> stop{false};
    std::atomic<int> bad{0};

    std::thread writer([&] {
        std::uint32_t id = 1;
        while (!stop.load(std::memory_order_relaxed)) {
            write_frame(slot, id, 64);
            id = (id == 1) ? 2 : 1;
        }
    });

    std::thread reader([&] {
        while (!stop.load(std::memory_order_relaxed)) {
            bool ok_one = read_fast(slot, 1);
            bool ok_two = read_fast(slot, 2);
            if (!ok_one && !ok_two) {
                bad.fetch_add(1, std::memory_order_relaxed);
            }
        }
    });

    std::this_thread::sleep_for(std::chrono::milliseconds(200));
    stop.store(true, std::memory_order_relaxed);
    writer.join();
    reader.join();
    std::cout << "mismatches=" << bad.load() << "\n";
    return bad.load() ? 1 : 0;
}

c++ -std=c++20 -O1 -g -fsanitize=thread -o frame_tsan frame.cpp
./frame_tsan

TSan named the overlapping memcpy and the payload scan. That is the root cause with a file and line. Do you still want to argue with the sanitizer trace?

Root Cause in One Sentence

The fast path published a view, not a snapshot. The writer reused the same bytes under that view. Tests never created a second scheduler, so they could not fail.

The header id and length were not one atomic word. A reader could mix id from frame one with n from frame two. Payload bytes could change mid-scan. That is a torn frame, not a flaky parser.

The Fix I Actually Trust

I stopped returning std::span from a recycled slot. I copied the frame into a local vector first. The copy is the snapshot. The later parse only reads that snapshot.

// Labeled example: snapshot before parse.
static bool read_safe(Slot& slot, std::uint32_t expect_id) {
    if (!slot.ready.load(std::memory_order_acquire)) {
        return true;
    }
    std::vector<std::uint8_t> snap = slot.bytes;  // copy, then parse
    if (snap.size() < 8) {
        return false;
    }
    std::uint32_t id = 0;
    std::uint32_t n = 0;
    std::memcpy(&id, snap.data(), 4);
    std::memcpy(&n, snap.data() + 4, 4);
    if (id != expect_id) {
        return false;
    }
    if (snap.size() != 8 + n) {
        return false;
    }
    for (std::size_t i = 0; i < n; ++i) {
        if (snap[8 + i] != static_cast<std::uint8_t>(expect_id)) {
            return false;
        }
    }
    return true;
}

A copy is not free. It is cheaper than a silent mix of two frames. If you need zero-copy, you need generation counters and retired slots. Are you ready to maintain that protocol?

A Reusable Debug Sequence

Use this sequence on the next green, lying test.

Write down the impossible observation in one line.
Name every object the reader aliases, not owns.
Ask which thread may mutate those bytes now.
Add a second thread before adding assertions.
Build once with ASan and once with TSan.
If only TSan complains, stop hunting parser typos.
Snapshot first, then parse, then measure cost.

I keep a tiny decision table next to the harness. It stops me from swapping tools at random.

Observation	First tool	Do not start with
Wrong value, no crash	TSan + two threads	Extra log lines only
Crash on free	ASan + shrinking repro	Rewriting the algorithm
Fails at -O2 only	Lifetime of views	Microbenchmarks
Fails once per hour	Forced overlap loop	Longer CI timeouts

Where a Scratch Model Helped

I already knew the symptom. I needed meaner schedules, not prettier code. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I used MonkeyCode's free model access to list aliasing mistakes I still forget. I used the free server option as a scratch compile box for the harness. I discarded any suggestion that removed the second thread.

Generated tests tried to sleep_for and call that concurrency. Sleep is not a happens-before edge. I threw those tests away. The useful output was a checklist of views, not a patch I could merge.

Limitations

This snapshot fix does not make the slot lock-free. It does not prove wait-free progress. It does not replace a real frame protocol with sequence numbers.

TSan can miss bugs if you block intercepts. ASan can miss bugs if you never free. A green sanitizer run is evidence, not a theorem.

The teaching harness uses a single slot. Production queues add padding, caches, and batching. Those features create new aliases. Copy this pattern, not this file.

I did not measure throughput here on purpose. A number without a machine description becomes folklore. Run your own clock on your own hardware.

Who Should Not Use This Approach

Do not use a span-over-recycle design in safety-critical parsers. Do not ship it because an assistant called it a fast path. Do not treat free model access as a substitute for TSan.

Skip this workflow if you cannot run thread sanitizer. Skip it if your runtime forbids extra copies on the hot path. Skip it if you need a vendor SLA I did not claim.

Skip generated adversarial tests if you will not read them. A test that never starts a second thread is camouflage. It makes the next review harder, not easier.

What I Keep After the Fix

I keep the two-thread harness in the repo. I keep the decision table above the parser. I keep the rule that views do not outlive a recycle.

The interesting AI news this week is not a new slogan. It is how easy green tests become. Engineering still starts when a second thread can lie to you.

If you want a scratch box for this same harness, MonkeyCode's free server option is one place to park the repro and break the test on purpose.

The Parse Succeeded on a Partial Token

Morgan Ma — Fri, 18 Sep 2026 07:54:59 +0000

The parser returned success on clearly junk input. The leftover suffix never reached a single test.

I burned a morning on a green suite. Why did every generated fixture stay so quiet?

This walkthrough is reconstructed from a common failure. Treat the function names as teaching examples. The reusable debugging method is the whole point.

The symptom that looked like a win

The config token was the literal 4096k. The job then allocated only 4096 bytes.

The log printed a completely happy parse line. No error branch ran at all.

Was the allocator wrong this time? Was the log lying to me?

Neither guess survived the first hex dump. The parser stopped at the first non-digit. It still returned success to the caller.

What I guessed first

I blamed errno before reading any input bytes. I blamed the C locale right after that.

The on-disk file was plain ASCII throughout. The process locale was already set to C. Those early guesses were pure debugging theater.

I needed the leftover pointer from from_chars. Did std::from_chars actually consume the trailing k?

Why the suite stayed green

The generated tests used only clean decimal tokens. They covered 0, 1, and 4096 only.

They never sent a trailing unit suffix. They also never sent a trailing space.

The tests quietly agreed with the implementation. They did not encode the config spec.

Does this pattern sound familiar to you yet? AI authored both sides of the same mistake.

The loose parse I started from

Label this block as example code. I did not lift it from a private tree.

// EXAMPLE: silent prefix parse
#include <charconv>
#include <cstdint>
#include <string_view>
#include <system_error>

bool parse_bytes_loose(std::string_view text, std::uint64_t& out) {
    if (text.empty()) {
        return false;
    }
    std::uint64_t value = 0;
    const char* first = text.data();
    const char* last = first + text.size();
    auto [ptr, ec] = std::from_chars(first, last, value);
    if (ec != std::errc{}) {
        return false;
    }
    out = value; // BUG: ptr may not equal last
    (void)ptr;
    return true;
}

See the unused ptr sitting there? That unused pointer is the whole bug.

std::from_chars may succeed on a prefix. The standard allows that leftover. Do you check ptr == last in review?

Most generated snippets skip that check. They copy the ec test and stop.

A fixture that hides the failure

// EXAMPLE: tautological tests
#include <cassert>
#include <cstdint>
#include <string_view>

bool parse_bytes_loose(std::string_view, std::uint64_t&);

void test_generated_fixtures() {
    std::uint64_t n = 0;
    assert(parse_bytes_loose("0", n) && n == 0);
    assert(parse_bytes_loose("1", n) && n == 1);
    assert(parse_bytes_loose("4096", n) && n == 4096);
    // Never: "4096k", "4096K", "4096 ", "0x10"
}

Every assert matches the happy decimal path. Production input is not in that list.

Would you ship this helper today? I almost shipped it. The suite was loud and green.

Numbered debugging steps

I used this sequence on the leftover. Steal it and keep it small.

1. Freeze the raw token

Print the exact bytes before any trim. Print the length beside the hex.

Do not trim the token first. Trimming hides the suffix you need.

# EXAMPLE command
python3 -c "print(list(b'4096k')); print(len(b'4096k'))"

You should see 53, 48, 57, 54, 107. The 107 is the letter k.

2. Split success from consumption

ec == std::errc{} is not enough. Ask how far ptr actually moved.

If ptr != last, you parsed a prefix. That prefix result is not success.

3. Add one hostile fixture

Do not add twenty new cases now. Add the token from production first.

4096k is enough for the proof. Then add 4096 and the empty string.

4. Fail the old helper on purpose

Keep the loose parser in the tree. Point the new test at that helper.

Watch it return true for 4096k. Watch out == 4096 in the debugger. That mismatch is your proof, not a theory.

5. Write the strict helper beside it

Do not “improve” the loose path in place. Side-by-side diffs teach the next review.

Then flip the single call site. Then delete the loose path after the flip.

The strict helper

// EXAMPLE: reject leftover characters
#include <charconv>
#include <cstdint>
#include <string_view>
#include <system_error>

struct ByteParse {
    bool ok;
    std::uint64_t value;
    std::size_t consumed;
    char leftover; // '\0' if none
};

ByteParse parse_bytes_strict(std::string_view text) {
    ByteParse r{false, 0, 0, '\0'};
    if (text.empty()) {
        return r;
    }
    const char* first = text.data();
    const char* last = first + text.size();
    auto [ptr, ec] = std::from_chars(first, last, r.value);
    r.consumed = static_cast<std::size_t>(ptr - first);
    r.leftover = (ptr == last) ? '\0' : *ptr;
    if (ec != std::errc{}) {
        return r;
    }
    if (ptr != last) {
        return r; // leftover suffix, still not ok
    }
    if (r.consumed == 0) {
        return r;
    }
    r.ok = true;
    return r;
}

The leftover char is only for logs. Do not guess units inside this helper.

Want k to mean kibibytes later? That is a second parser. Keep this one honest.

A tiny self-check main

// EXAMPLE: compile with
// g++ -std=c++17 -Wall -Wextra -Werror parse_check.cpp -o parse_check
#include <iostream>
#include <string_view>

ByteParse parse_bytes_strict(std::string_view);

int main() {
    const std::string_view cases[] = {
        "0", "4096", "4096k", "4096K", "4096 ",
        "", "k4096", "18446744073709551616", "+4096", "0x10"
    };
    int failures = 0;
    for (auto c : cases) {
        auto r = parse_bytes_strict(c);
        const bool expect_ok = (c == "0" || c == "4096");
        if (r.ok != expect_ok) {
            std::cerr << "mismatch on '" << c << "'\n";
            ++failures;
        }
        std::cout << "in='" << c
                  << "' ok=" << r.ok
                  << " value=" << r.value
                  << " consumed=" << r.consumed
                  << " leftover=";
        if (r.leftover) {
            std::cout << r.leftover;
        } else {
            std::cout << "NUL";
        }
        std::cout << "\n";
    }
    return failures == 0 ? 0 : 1;
}

Run it and read the leftover column. That column is the actual debugger.

+4096 fails on purpose in this harness. Integer from_chars does not treat + as optional padding.

Check your standard library before you assume a sign. Do not trust a comment from a chat log.

Decision table I keep above the function

Input	`ec` looks ok?	`ptr == last`?	Ship it?
`4096`	yes	yes	yes
`4096k`	yes	no	no
`4096`	yes	no	no
empty	no	n/a	no
`k4096`	no	no	no
`0x10`	yes on `0`	no	no
overflow digits	no	maybe	no

If a generated test only covers row one, reject the patch. Ask the patch one blunt question. Which row did you actually run?

Where a free compile loop actually helped

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I used MonkeyCode's free model access on the helper text. I used the free server option to compile this harness.

The model suggested the loose from_chars call. That suggestion was not a surprise. The server did not magically know the config grammar.

I still had to add 4096k myself. Do not treat a green remote build as verification. Treat it as a faster rebuild loop only.

I will not name models in this article. I will not quote quotas either. Those figures go stale by the next post.

What the generated patch got wrong

It copied a success check from common snippets. It ignored the leftover pointer completely.

It wrote tests from the function shape. It did not write tests from the config grammar.

That is not a model scandal by itself. That is a missing oracle in the repo.

Who owns that oracle on your team? You do. The grammar still lives in your head.

A second trap in the same file

std::from_chars does not skip whitespace. A trailing space fails the strict check.

Good. A leading space also fails here. That failure is also good.

Hex prefixes fail in a sneakier way. 0x10 consumes 0, then leftover is x.

Did your generated tests include 0x10? The example suite above did not at first.

Add it, then watch leftover print x. That single character ends the argument.

Overflow is a different failure

The huge digit string is not a prefix bug. from_chars should report result_out_of_range.

Do not fold overflow into leftover handling. Keep those two failures separate in logs.

I print ok, consumed, and leftover together. I still inspect ec in the debugger.

One flag cannot describe both bugs. Two flags keep the postmortem honest.

Limitations of this method

This harness does not parse size units. It does not parse decimal bytes.

It does not handle thousand separators. It does not handle locale numerals.

from_chars is base ten in this helper. Binary sizes need a later stage.

The self-check compares views to literals. That is fine for fixed cases. It is not a fuzz campaign.

It will miss mixed suffixes like 4096kb. I did not measure wall time here. I did not claim any speedup.

Who should not use this approach

Do not use a remote compile loop for secrets. Config tokens can be secrets too.

Do not paste production files into a hosted model. Redact the token stream first.

Do not use this parser for money fields. Rounding and overflow need a written spec.

Do not skip sanitizers after the parse fix. Prefix parse is not your only bug class.

If you cannot state the grammar today, stop generating tests. Write the grammar down first.

What I keep from the failure

Green tests can encode the original bug. Partial consumes look exactly like success.

ptr == last is the real success check. The leftover char is the breadcrumb you log.

Hostile fixtures beat more happy fixtures. One production token is usually enough.

Would I trust another generated parser tomorrow? Only with that table above the function.

If you already hold a failing token, a free compile server can shorten the rebuilds.

The Key View Survived the Buffer Reset

Morgan Ma — Thu, 17 Sep 2026 05:56:09 +0000

A string_view can outlive every byte it names. That failure compiles, links, and passes shallow tests. This walkthrough is a reconstructed lab case. The map stayed honest. The key was already dead.

Do not store a view into a reusable buffer. Copy the key first, or freeze the buffer. Sanitizers will not always save you here. Why? The storage remains allocated. Only the characters change underneath.

The symptom that looked like a race

The handler returned flags for the previous user. It happened after bursts of short names. Edge logs showed the right user string. The cache still answered for someone else.

Was it a race? That was my first story. ThreadSanitizer printed nothing useful at all. AddressSanitizer printed nothing useful either. Have you trusted a quiet sanitizer too early?

I printed the key pointer beside the key text. The pointer stayed stable across later requests. The text did not stay stable. That is aliasing, not a data race.

False lead one: the hash map

I blamed std::unordered_map for mixing tenants. I swapped in an ordered map. I dumped buckets and load factor. The structure was fine. The lookup key was a ghost of the last write.

False lead two: small-string optimization

Short keys failed more often than long keys. That smelled like small-string optimization. It was a hint, not the root. Short keys reused capacity without moving. The view address never jumped. Long keys sometimes reallocated and hid the bug.

Numbered walkthrough

Follow this sequence on any similar flake.

Capture one failing input pair, then replay it in-process.
Log key .data(), .size(), and a copied character snapshot.
Run under ASan and TSan anyway. Record that they were quiet.
Disable threads. If the flake remains, drop the race theory.
Find every clear, resize, and assign on the scratch buffer.
Insert a poison fill after each reset. Watch the held key change.
Replace the stored view with an owning std::string. Retest the matrix.

Step six is the cheap microscope. You do not need a new vendor tool. You need to mutate the bytes on purpose. Does the stored key change when you poison? Then you never owned it.

Reconstructed repro

The program below is a lab sample. Treat it as a reduced case. It is not a dump of production source.

#include <algorithm>
#include <cassert>
#include <iostream>
#include <string>
#include <string_view>
#include <unordered_map>

class ScratchKeyBuilder {
public:
    std::string_view make_key(std::string const& user, int id) {
        buf_.clear();
        buf_.append(user);
        buf_.push_back(':');
        buf_.append(std::to_string(id));
        return buf_;  // view into member storage
    }

    void recycle() {
        // Next request reuses the same bytes.
        std::fill(buf_.begin(), buf_.end(), '#');
        buf_.clear();
    }

private:
    std::string buf_;
};

int lookup_or_store(std::unordered_map<std::string, int>& cache,
                    std::string_view key,
                    int value) {
    auto it = cache.find(std::string{key});
    if (it != cache.end()) {
        return it->second;
    }
    cache.emplace(std::string{key}, value);
    return value;
}

int main() {
    ScratchKeyBuilder scratch;
    std::unordered_map<std::string, int> cache;

    std::string_view k1 = scratch.make_key("ada", 1);
    int v1 = lookup_or_store(cache, k1, 100);
    scratch.recycle();

    std::string_view k2 = scratch.make_key("bob", 2);
    int v2 = lookup_or_store(cache, k2, 200);

    std::string_view stale = scratch.make_key("ada", 1);
    scratch.recycle();
    std::string ghost{stale};  // may be empty, "###", or worse

    std::cout << "v1=" << v1 << " v2=" << v2
              << " ghost='" << ghost << "'\n";
}

Build the lab case with a pedantic sanitizer command.

clang++ -std=c++20 -O0 -g -Wall -Wextra \
  -fsanitize=address,undefined \
  -fno-omit-frame-pointer \
  stale_view.cpp -o stale_view
./stale_view

Keep those flags. They are still required. They will not always fire. That silence is the trap.

Why the sanitizers stayed quiet

AddressSanitizer hunts use-after-free and out-of-bounds access. This buffer was still alive. The std::string object still owned a valid region. Recycle overwrote that region in place. That is not a free.

ThreadSanitizer hunts concurrent conflicting memory accesses. My flake survived a single thread. No race existed in the schedule. The view was simply stale after clear.

Would a fuzzer have caught it on day one? Maybe, if the corpus reused the builder. A one-shot unit test would miss it completely. That is why the buffer must be recycled inside the test. Happy-path lookup is not an ownership proof.

Root cause

The helper returned std::string_view into member storage. A later request called clear and append on that storage. Callers still held the old view. Some callers copied late, after recycle. Those copies contained the next user, or poison, or nothing.

The zero-copy shape came from a generated patch. It compiled without a single new warning. It looked modern and allocation-free. It deleted a copy I could see. It introduced an alias I could not see. Sound familiar this month?

A green compile is not an ownership proof. Lifetime lives in the next call. Lifetime also lives in comments nobody asked the model to write. AI assistance did not remove that check. It made a missing check easier to ship.

The fix

Own the key before the buffer can move again.

std::string make_key(std::string const& user, int id) {
    std::string out;
    out.reserve(user.size() + 16);
    out.append(user);
    out.push_back(':');
    out.append(std::to_string(id));
    return out;
}

If the hot path cannot allocate, freeze the buffer. Do not recycle until every view is gone. A generation counter also works as a tripwire. Stamp the view with a generation. Reject a mismatch on use.

struct GenView {
    std::string_view bytes;
    std::uint64_t generation;
};

bool valid(GenView const& v, std::uint64_t current) {
    return v.generation == current;
}

I prefer the owning string unless a profiler says otherwise. Have you measured that copy on the real path? If not, keep the copy. Fancy views are cheaper only when they stay valid.

Decision table

Use this table before you return a view from a helper.

Handle	Safe to store?	Recycle while live?	Use when
Owning `std::string`	Yes	Yes	Default cache keys
`string_view` into a member buffer	No	No	Never across requests
`string_view` into a frozen arena	Yes	Not until freeze lifts	Documented window only
Interned pointer	Yes if intern outlives cache	Intern must not evict	Extra machinery

If your case is not in the yes column, copy. Do not negotiate with the buffer. The table is the whole API review.

Test plan you can paste

Do not trust a single happy-path test. Run this matrix on every scratch builder.

Two distinct users, same builder instance, sequential requests.
Same user twice, with a recycle between the lookups.
A short key, then a longer key that forces reallocation.
A longer key, then a short key that reuses capacity.
Poison fill after clear, then read any held view.
The same sequence under ASan, TSan, and a non-sanitized -O2 build.

Pass means no cross-user hits. Pass also means poison never appears in stored keys. Fail means you still hold a view across recycle. Put step five in CI. A human will skip it later.

Where free model access actually helps

I asked for extra negative tests after I knew the bug class. I did not ask a model to rewrite the cache first. That order matters. The first patch already looked elegant.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode offers free model access and a free server option. Those two facts are the only product claims I am using here. I am not attaching model names, quotas, or timings. Those numbers go stale fast. Your own dashboard is the source of record.

Proposed workflow, labeled as a proposal, not a measured run:

Paste the reduced repro and the failing matrix.
Ask for more negative tests, not a new implementation.
Keep only tests that recycle storage or poison bytes.
Compile those tests on the free server with sanitizer flags.
Reject any patch that returns a view into member buffers.

The model is a generator. The sanitizer build is the judge. The recycle test is the oracle. Remove any one of those three and you are guessing again. If you try that matrix on a free server, keep the sanitizer flags.

Limitations

This approach will not catch every lifetime bug. It will not replace owning keys in a public cache API. It will not help if you cannot run a sanitizer build. Quiet ASan is not a proof of ownership. Quiet TSan is not a proof either.

Who should skip this pattern? Anyone shipping a view-based protocol without a freeze window. Anyone who cannot add a recycle test to CI. Anyone hoping a generated zero-copy helper is finished work. Anyone who cannot read the next caller of a returned view.

Do not use a reusable scratch buffer for keys you store. Do not keep string_view in containers that outlive the request. Do not treat a compiled helper as a lifetime review. The compiler will not object. Your next tenant might.

After the fix

I grep for string_view returns from member functions. I require a comment if the view is non-owning. I add one recycle test beside every scratch builder. That is cheap insurance. Another silent cache mix-up is not cheap.

If you run the repro, watch the ghost string first. Then make the key own its bytes. That is the whole lesson, and it still holds when the assistant writes the helper.

The Comparator Ranked a Tie as Less

Morgan Ma — Wed, 16 Sep 2026 04:09:56 +0000

The comparator treated a matching pair as less. Then std::sort walked into undefined behavior. Green tests on three unique keys will not save you.

I rebuilt the failure in a tiny harness. No vendor core dump. No secret production trace. Just a polite predicate that broke the named requirement.

Why did it look polite? It handled equality on purpose. That choice was the bug. Have you shipped that comment too?

The symptom I started from

I sorted a vector of records. Most permutations looked fine. One permutation dropped a name.

Another permutation duplicated a name. The size stayed constant. The multiset did not.

Have you seen that shape? Length matches. Contents lie. That is not a stability complaint. That is contract failure under std::sort.

I printed the vector before the call. I printed it after the call. Same size(). Different bags of values.

What I blamed first

I blamed the swap. I blamed a user-written move. I blamed a dangling string_view.

Wrong. Wrong. And wrong again. The record was a boring aggregate. Two fields. Trivial moves. No views.

So I read the comparator slowly. It even had a comment. "Handle ties by name." Cute. Deadly.

struct Rec {
    int score;
    std::string name;
};

bool by_score_then_name(const Rec& a, const Rec& b) {
    if (a.score != b.score) {
        return a.score > b.score;
    }
    return a.name <= b.name; // looks careful. it is not.
}

See the <=? Equal names return true. std::sort wants a strict weak ordering. comp(x, x) must be false.

Ask it out loud. Does comp(x, x) return false? If not, stop coding. Fix the predicate first.

Shrink the input until the law is visible

Do not debug this on ten thousand production rows. Three records can be enough. Four if you want a real tie.

Label this clearly. The listing below is a reconstructed example. It is not a client trace.

// sort_predicate_check.cpp
#include <algorithm>
#include <cassert>
#include <iostream>
#include <string>
#include <vector>

struct Rec {
    int score;
    std::string name;
};

bool bad_less(const Rec& a, const Rec& b) {
    if (a.score != b.score) return a.score > b.score;
    return a.name <= b.name;
}

bool good_less(const Rec& a, const Rec& b) {
    if (a.score != b.score) return a.score > b.score;
    return a.name < b.name;
}

template <class Cmp>
bool irreflexive(const std::vector<Rec>& v, Cmp cmp) {
    for (const auto& x : v) {
        if (cmp(x, x)) return false;
    }
    return true;
}

template <class Cmp>
bool both_ways_true(const std::vector<Rec>& v, Cmp cmp) {
    for (const auto& a : v) {
        for (const auto& b : v) {
            if (cmp(a, b) && cmp(b, a)) return false;
        }
    }
    return true;
}

int main() {
    std::vector<Rec> v{
        {10, "ada"},
        {10, "ada"},
        {7, "bek"},
        {10, "cy"}
    };

    std::cout << std::boolalpha;
    std::cout << "irreflexive bad: "
              << irreflexive(v, bad_less) << "\n";
    std::cout << "asymmetric bad: "
              << both_ways_true(v, bad_less) << "\n";
    std::cout << "irreflexive good: "
              << irreflexive(v, good_less) << "\n";
    std::cout << "asymmetric good: "
              << both_ways_true(v, good_less) << "\n";
}

Compile it with symbols. Read the booleans. Do not skip that print.

c++ -std=c++17 -O0 -g sort_predicate_check.cpp -o sort_predicate_check
./sort_predicate_check

You want this shape of output. Anything else means the law already failed.

irreflexive bad: false
asymmetric bad: false
irreflexive good: true
asymmetric good: true

The bad predicate fails before std::sort runs. That is the whole trick. Catch the contract. Do not wait for the crash.

Debug steps I now reuse

Freeze one permutation. Dump it as a brace list.
Ask comp(x, x) on every element. Demand false.
Ask both directions on every pair. Ban two trues.
Check transitivity on triples. Yes, it is tedious.
Only then call std::sort under sanitizers.

Step four is the one people skip. Why skip it? Because it is boring. Undefined behavior loves boring predicates.

c++ -std=c++17 -O1 -g -fsanitize=address,undefined \
    sort_predicate_check.cpp -o sort_san
./sort_san

Sanitizers do not always fire here. Treat a clean run as inconclusive. The pair checks are the test. The sanitizer is a spare net.

A debug standard library can help. It is not a portable promise. Keep the property checks anyway.

The patch that made it worse

I asked a coding model for a fix. It kept the tie comment. It wrote a still-illegal predicate.

bool still_bad(const Rec& a, const Rec& b) {
    if (a.score > b.score) return true;
    if (a.score < b.score) return false;
    if (a.name == b.name) return true; // "stable on equals"
    return a.name < b.name;
}

Stable on equals? std::sort is not std::stable_sort. Returning true for equals stays illegal. The draft optimized for a story. Not for [alg.sorting].

That is vibe-shaped C++. It compiles. It sounds kind. It is still undefined behavior. Would you merge it after a unique-key unit test? I would not.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I used MonkeyCode's free model access and free server option as a draft source. Not as an oracle. I pasted the ordering laws. I did not paste customer rows. Then every candidate hit the same irreflexive check.

Most drafts failed comp(x, x). Good. The harness did the engineering. The model only did the typing. A local compiler still owned the verdict.

The real fix

Use <. Never <=. Never return true for equal keys. Split fields with std::tie when the key grows.

#include <tuple>

bool good_less(const Rec& a, const Rec& b) {
    // descending score, then ascending name
    return std::tie(b.score, a.name) < std::tie(a.score, b.name);
}

Wait. Did I invert score by swapping operands? Yes. Write that once. Test it twice. A table beats a comment.

a	b	`good_less(a,b)`	`good_less(b,a)`	note
`{10, ada}`	`{10, ada}`	false	false	equal, both false
`{10, ada}`	`{10, cy}`	true	false	name order
`{10, ada}`	`{7, bek}`	true	false	higher score first
`{7, bek}`	`{10, cy}`	false	true	lower score later

If any row shows two trues, you failed. If an equal row shows a true, you failed. Print the row. Do not argue with it.

A cheap shuffle net

Four rows are not a proof. Shuffle. Repeat. Keep the asserts.

#include <numeric>
#include <random>

void fuzz_ordering(std::vector<Rec> v, unsigned seed) {
    std::mt19937 rng(seed);
    for (int i = 0; i < 200; ++i) {
        std::shuffle(v.begin(), v.end(), rng);
        assert(irreflexive(v, good_less));
        assert(both_ways_true(v, good_less));
        auto w = v;
        std::sort(w.begin(), w.end(), good_less);
        assert(w.size() == v.size());
        assert(std::is_sorted(w.begin(), w.end(), good_less));
    }
}

Two hundred shuffles. Not a benchmark. A cheap net. Illegal comparators often explode early. A quiet run still needs the pair checks.

Seed the generator. Log the seed. Replay the failing permutation. That replay is the debugging technique. The model output is not.

What I now refuse to merge

A comparator with <=. A comparator that returns true "for stability." A comparator that calls abs on the key. A comparator that reads a field the sort mutates.

Would I trust a green test that sorts three unique scores? No. Unique keys hide the tie bug. Ties are the actual test. Unique keys are theater.

I also refuse silent operator< on types I do not own. Wrapping those types is fine. Pretending they already order is not.

Limitations

This harness does not prove transitivity on infinite domains. Finite samples miss hostile keys. Floating-point keys are another swamp. NaN breaks < even when you were careful.

Debug iterators in libstdc++ or libc++ can catch some of this. They are build flags, not proofs. Do not drop property checks because a debug STL exists.

I did not measure model quality. I did not collect pass rates. One illegal <= is enough to reject a patch. Do not turn this into a leaderboard.

The free remote path is a draft source. It is not a verifier. If the code cannot leave your machine, do not paste it anywhere remote. Keep secrets local. Generate the harness locally.

Who should skip this approach

Skip it if you sort pointers and think addresses are keys. Skip it if your "tie" is a live timestamp. Skip it if you need a total order over NaN.

Do not point a remote free model at customer records. Do not use this loop as cover for missing operator< on foreign types. Do not call a unique-key sort a proof of ordering.

And do not skip step four because the sanitizer was quiet. Quiet is not evidence. Quiet is a missing assert.

The reusable bit

The technique is older than coding models. Write the ordering laws first. Irreflexive. Asymmetry. Transitivity. Then type the predicate. Then sort.

I still write two-field predicates by hand. I let a draft appear when the key has six nested fields. Then I run the table. Then I run the shuffle loop.

Did a draft type std::tie faster than I did? Sometimes. Did it catch <= alone? Not until the harness returned false.

That false is the engineering. Keep the false. Drop the story in the comment.

If you need a second draft of a synthetic comparator, MonkeyCode's free models and free server option are one place to run that loop. Keep the checks. Leave the vibes out of the merge.