Sporadic access violation when repeatedly evaluating IsCombedTIVTC() — possible TFM object lifetime issue

[Deanna444]

This is actually a Claude-identified bug report:

Sporadic access-violation crash (exit 0xCCCCCCCC), possibly related to per-frame TFM object construction in IsCombedTIVTC

Summary

Sporadic crashes — process exit code -858993460 (0xCCCCCCCC as unsigned 32-bit, the MSVC debug-heap "uninitialized/freed memory" fill pattern) — occur intermittently when processing long clips through scripts that call IsCombedTIVTC() as a per-frame conditional-filter expression (inside WriteFile/FrameEvaluate). The crash is non-deterministic: at least one affected file crashed on one run and completed cleanly on an immediately following re-run with no changes to script, settings, or file.

Environment

• TIVTC 1.0.30.0 (also checked against the 1.0.28 source tree — IsCombedTIVTC.cpp and the relevant TFM.cpp code are unchanged between the two per the changelog)
• AviSynth+ 3.7.5
• Windows 10 x64, invoked via ffmpeg's avisynth demuxer (-f avisynth -i script.avs -f null -)
• Source: D2VSource-decoded MPEG-2 .d2v files. Affected files span clean 3:2 telecine, native interlaced video with heavy combing, mixed/random cadence, and one genuinely progressive (non-interlaced) source — no content-type pattern identified.

Observed pattern

Crashes have occurred in two structurally different scripts whose only common element is a per-frame call to IsCombedTIVTC(cthresh=9, MI=80, chroma=false, blockx=16, blocky=16, metric=0, opt=4):

1. A script combining TFM() + TDecimate() + IsCombedTIVTC() in one WriteFile chain, run full-length (42,000–90,000+ frames).
2. A separate, unrelated script containing only D2VSource → SeparateFields → FrameEvaluate → IsCombedTIVTC() — no TFM or TDecimate filter object at all — sampled over ~9,000 frames.

Both crashed with the same exit code, on different files, at different points in their respective runs. No other filter or code path is common to both.

Structural observation (source-reviewed; not confirmed as root cause)

Create_IsCombedTIVTC in IsCombedTIVTC.cpp constructs a brand-new TFM object on every single evaluated frame, uses it once, then destroys it:

TFM *f = new TFM(args[0].AsClip(), -1, -1, 1, 5, "", "", "", "", false, false, false, false,
    15, args[1].AsInt(9), args[2].AsInt(80), chroma, args[4].AsInt(16),
    args[5].AsInt(16), 0, 0, "", 0, 0, 12.0, 0, 0, "", false, args[6].AsInt(0), false, false, false,
    args[7].AsInt(4), env);
AVSValue IsCombedTIVTC = f->ConditionalIsCombedTIVTC(n, env);
delete f;

This is a fundamentally different usage pattern from TFM() used directly as a filter, which constructs one object per clip and reuses it via child->SetCacheHints(CACHE_GENERIC, 3). Over a 40,000–90,000-frame file, IsCombedTIVTC used this way means 40,000–90,000+ construct/allocate/destroy cycles of a full TFM object (whose constructor alone is ~860 lines) in a single run.

This pattern seems consistent with the symptoms observed:

• Non-determinism — allocation-churn-triggered heap issues are typically harder to reproduce deterministically than logic errors.
• The crash appearing in two otherwise-unrelated scripts whose only shared element is this construct/destroy cycle.
• The specific 0xCCCCCCCC signature, consistent with a use-after-free, double-free, or uninitialized-read class of bug rather than a clean logic error.

I checked for the more obvious explanations first and ruled them out: no shared static/global mutable state in TFM.cpp/TFM.h that would explain a cross-thread race, and the destructor's file-write paths (output, outputC) are both empty strings in IsCombedTIVTC's construction call, so no file I/O happens in these particular objects' destructors.

I have not identified a specific defective line — I don't have a debugger or memory-sanitizer (ASan / Dr. Memory / Application Verifier) set up against this build to confirm it live. I'm reporting the pattern in case it's already a known area of concern, or worth a look by someone who can reproduce and instrument it directly.

Reproduction

I don't yet have a minimal, isolated repro script — the crash has only been observed inside a larger production pipeline, and is sporadic enough that it hasn't reproduced on an immediate identical re-run of at least one affected file. Happy to try to construct a minimal case (e.g., a tight loop of IsCombedTIVTC calls over a long synthetic clip) if that would help — let me know if that's useful before I spend the time on it.

Exit code reference

-858993460 = 0xCCCCCCCC (unsigned 32-bit) — the MSVC debug-heap fill pattern used to mark freed or uninitialized memory. Not a normal AviSynth+/ffmpeg error code.

[pinterf]

A minimal repro is always welcomed, thanks.

[Deanna444]

Summary

Sporadic crashes — process exit code -858993460 (0xCCCCCCCC as unsigned 32-bit, the MSVC debug-heap "uninitialized/freed memory" fill pattern) — occur intermittently when processing long clips through scripts that call IsCombedTIVTC() as a per-frame conditional-filter expression (inside WriteFile/FrameEvaluate). The crash is non-deterministic: at least one affected file crashed on one run and completed cleanly on an immediately following re-run with no changes to script, settings, or file.

Update: this is now confirmed reproducible with a minimal, fully synthetic script (no source file, no TFM()/TDecimate() object at all) — see "Minimal repro results" below. That run also surfaced a more specific finding: the crash happens after all per-frame IsCombedTIVTC evaluations have already completed successfully, not mid-loop.

Environment

• TIVTC 1.0.30.0 (also checked against the 1.0.28 source tree — IsCombedTIVTC.cpp and the relevant TFM.cpp code are unchanged between the two per the changelog)
• AviSynth+ 3.7.5
• Windows 10 x64, invoked via ffmpeg's avisynth demuxer (-f avisynth -i script.avs -f null -)
• Source (production case): D2VSource-decoded MPEG-2 .d2v files. Affected files span clean 3:2 telecine, native interlaced video with heavy combing, mixed/random cadence, and one genuinely progressive (non-interlaced) source — no content-type pattern identified.
• Source (minimal repro): synthetic BlankClip, no source file — see below.

Observed pattern

Crashes have occurred in three structurally different scripts whose only common element is a per-frame call to IsCombedTIVTC(cthresh=9, MI=80, chroma=false, blockx=16, blocky=16, metric=0, opt=4):

1. A production script combining TFM() + TDecimate() + IsCombedTIVTC() in one WriteFile chain, run full-length (42,000–90,000+ frames) on real .d2v sources.
2. A separate, unrelated production script containing only D2VSource → SeparateFields → FrameEvaluate → IsCombedTIVTC() — no TFM or TDecimate filter object at all — sampled over ~9,000 frames.
3. A minimal, fully synthetic repro script — BlankClip → SeparateFields → FrameEvaluate → IsCombedTIVTC(), 200,000 fields, no source file, no TFM/TDecimate — see results below.

All three crashed with the same exit code. No filter or code path is common to all three beyond the IsCombedTIVTC per-frame call itself.

Minimal repro results

Script (synthetic, no external file dependency):

LoadPlugin("<path>/tivtc.dll")
c = BlankClip(length=100000, width=720, height=480, pixel_type="YV12", fps=30000, fps_denominator=1001, color=$808080)
c = SeparateFields(c)
FrameEvaluate(c, "current_frame")
c = WriteFile(c, "<path>/log.txt", "string(IsCombedTIVTC(cthresh=9,MI=80,chroma=false,blockx=16,blocky=16,metric=0,opt=4))", append=true)
return c

Run via: ffmpeg -f avisynth -i script.avs -an -fps_mode drop -f null -

Run 100 times in a row (automated, unattended). Result: 2 of 100 runs crashed, both with exit code -858993460, matching the production crashes exactly.

New finding, from inspecting the two crashed runs' own WriteFile output logs:

• Both logs are complete — 200,001 lines each (one line per field evaluated), no truncation, no malformed entries, ending on a normal, well-formed line. Every single per-frame IsCombedTIVTC call in both crashed runs succeeded and was written out before the crash occurred.
• Both crashed runs took the same elapsed time (~75–77 seconds) as every clean run in the same batch — the crash isn't cutting the run short partway through; the full frame loop finishes normally first.

Taken together, this narrows the hypothesis: the fault isn't necessarily happening at the moment the process crashes, and isn't happening mid-loop. It's consistent with a heap-corruption pattern where the actual bad write happens earlier (plausibly during one of the ~200,000 construct/destroy cycles, per the structural observation below) but only manifests as a fault later — during WriteFile's final flush/close, AviSynth environment teardown, or process exit — once something touches the already-corrupted memory. I can't confirm this without a debugger/memory-sanitizer session; flagging it as the most consistent explanation of what's been observed, not a confirmed mechanism.

Separate, unexplained, not claimed to be related: both crashed logs show 200,001 lines against an expected 200,000 (BlankClip(length=100000) doubled by SeparateFields). One extra field appears to have been evaluated. Noting this because it's a real discrepancy in the evidence, not because I have a theory connecting it to the crash.

Structural observation (source-reviewed; not confirmed as root cause)

Create_IsCombedTIVTC in IsCombedTIVTC.cpp constructs a brand-new TFM object on every single evaluated frame, uses it once, then destroys it:

TFM *f = new TFM(args[0].AsClip(), -1, -1, 1, 5, "", "", "", "", false, false, false, false,
    15, args[1].AsInt(9), args[2].AsInt(80), chroma, args[4].AsInt(16),
    args[5].AsInt(16), 0, 0, "", 0, 0, 12.0, 0, 0, "", false, args[6].AsInt(0), false, false, false,
    args[7].AsInt(4), env);
AVSValue IsCombedTIVTC = f->ConditionalIsCombedTIVTC(n, env);
delete f;

This is a fundamentally different usage pattern from TFM() used directly as a filter, which constructs one object per clip and reuses it via child->SetCacheHints(CACHE_GENERIC, 3). Over a 200,000-frame run (or 40,000–90,000-frame production file), IsCombedTIVTC used this way means tens to hundreds of thousands of construct/allocate/destroy cycles of a full TFM object (whose constructor alone is ~860 lines) in a single run.

This pattern seems consistent with the symptoms observed:

• Non-determinism — allocation-churn-triggered heap issues are typically harder to reproduce deterministically than logic errors. Consistent with the 2/100 reproduction rate above.
• The crash appearing across production and minimal-synthetic scripts alike, with TFM/TDecimate present in some and completely absent in others — the only constant is this construct/destroy cycle.
• The specific 0xCCCCCCCC signature, consistent with a use-after-free, double-free, or uninitialized-read class of bug rather than a clean logic error.
• The crash manifesting only after the full frame loop completes (new finding above) — consistent with corruption that occurs during the loop but only faults later, once torn-down state is touched again.

I checked for the more obvious explanations first and ruled them out: no shared static/global mutable state in TFM.cpp/TFM.h that would explain a cross-thread race, and the destructor's file-write paths (output, outputC) are both empty strings in IsCombedTIVTC's construction call, so no file I/O happens in these particular objects' destructors.

I have not identified a specific defective line — I don't have a debugger or memory-sanitizer (ASan / Dr. Memory / Application Verifier) set up against this build to confirm it live. I'm reporting the pattern in case it's already a known area of concern, or worth a look by someone who can reproduce and instrument it directly.

Reproduction

The minimal script above is attached/linked and reproduces the crash at roughly a 2% per-run rate — running it several times in a row (not just once) is necessary to observe it, given the non-determinism. Happy to share the small automated runner used to batch these attempts, or to try narrowing the reproduction rate further (e.g., testing whether clip length, opt= value, or thread count changes the rate) if that would help.

Exit code reference

-858993460 = 0xCCCCCCCC (unsigned 32-bit) — the MSVC debug-heap fill pattern used to mark freed or uninitialized memory. Not a normal AviSynth+/ffmpeg error code.

[pinterf]

Could you please check it with the latest 1.0.32 release?
Also, use the latest Avisynth+ from https://github.com/pinterf/AviSynthPlus/releases
Thanks.

[Deanna444]

IsCombedTIVTC_Crash_Repro_Report.txt
IsCombedTIVTC_Crash_Repro_Runner_DIAG.log
repro_run_015_log.txt
repro_run_029_log.txt
repro_run_047_log.txt
repro_run_065_log.txt

Crash still reproducible on latest AviSynth+ (r4669) + TIVTC 1.0.32

Following your suggestion, retested with:

AviSynth+ 3.7.6_20260827_tst_r4669 — confirmed via DLL Product Name and AvsPmod's reported version, both showing AviSynth+ 3.7.5 (r4669, master, x86_64)
TIVTC v1.0.32.0 (Pinterf build)

Repro harness: synthetic BlankClip (100,000 fields) piped through IsCombedTIVTC via ffmpeg (-f avisynth), run repeatedly and unattended.

Result: 3 crashes in 65 completed runs (stopped early), all identical signature — exit=-858993460 (0xCCCCCCCC). Same failure mode as previously reported. The two candidate upstream fixes present in r4669's source (LruCache.h ghosted>1 threshold, RegisterSubFrameInRegistry leak fix) do not appear to resolve it in this build.

.avs scripts and per-run logs retained for the three crashed runs are attached. DebugView isn't usable on this Win7/10 box (Microsoft pulled the last compatible build), so any further logging would need to go through TDecimate's own display=true frame burn-in or similar.

[pinterf]

"both crashed logs show 200,001 lines against an expected 200,000"
ffmpeg probably calls frame 0 at the very beginning, to get the video format information, this must be the extra line, if somehow you could attach the frame number to the log file, you can validate this theory. (Not that it would help us in anything, but clarifies things)

[Deanna444]

Several updates in this post:

---

Confirmed your theory. I instrumented the repro script to prefix each log line with the frame number (WriteFile with "current_frame" as an extra expression) and ran another batch.

4 crashes out of 300 runs, all the same exit code (-858993460 / 0xCCCCCCCC) as before. Checked the full frame sequence in all 4 crashed logs, not just the ends:

• Every log has exactly 200,001 lines.
• Frame 0 appears twice at the very start (0, 0, 1, 2, ... 199999).
• Every other frame from 1 to 199,999 appears exactly once.
• No gaps, nothing outside the 0-199999 range.

Same pattern in all 4 independent crashes, so this isn't a one-off. Matches your explanation exactly -- looks like ffmpeg's avisynth demuxer probing frame 0 once for format info, then decoding it again as frame 0 of the real output.

So that clears up the 200,001-vs-200,000 line count -- it's a benign ffmpeg-side artifact, not related to the crash. The crash itself still reproduces at the same ~1-2% rate and I don't have anything new on its root cause yet.

The frame-numbered logs are attached.

repro_run_103_log.txt
repro_run_149_log.txt
repro_run_174_log.txt
repro_run_209_log.txt

---

Update on the IsCombedTIVTC crash. I ran the same minimal repro script through AVSMeter instead of ffmpeg -- pure AviSynth+ decode, no ffmpeg anywhere in the path.

Result: it still crashes. 5 out of 300 runs, all the same exit code (-858993460 / 0xCCCCCCCC) as every ffmpeg-hosted crash so far. Rate is comparable too -- 5/300 (1.67%) here vs 4/300 (1.33%) via ffmpeg, close enough that's probably just normal run-to-run variance, not a real difference.

Same shape as every prior crash: full frame loop completes (0 to 199999) before the process dies, not a mid-loop failure. So this rules out ffmpeg as the cause -- it's not the avisynth demuxer or anything in ffmpeg's decode path. Whatever's going on lives in AviSynth+/TIVTC itself.

Also, unrelated to the crash but maybe useful: AVSMeter's logs confirmed frame 0 is NOT probed twice the way it is under ffmpeg (single frame 0, not duplicated) -- consistent with that being ffmpeg's avisynth-demuxer probing behavior specifically, not anything AviSynth-side.

One more thing I noticed in this data, not sure if it's relevant to you: the WriteFile-based log shows an early contiguous block of frames (varies per run, roughly 14,500-15,300 frames) each logged twice, then the rest of the clip logged once. But AVSMeter's own internal frame counter reports exactly 200,000 processed in every case, no doubling. AVSMeter has multi-threading on by default, so my best guess is this is prefetch-related -- more than one GetFrame request reaching WriteFile for some early frames while the thread pool's cache is still filling, before it settles into one request per frame. Not confirmed, just the most plausible explanation given AVSMeter's own count doesn't show it. Might be nothing to do with your side at all, but flagging in case it's a useful data point.

The 5 crashed .avs/log pairs are attached

README.txt
repro_run_119_avsmeter.log
repro_run_119_log.txt
repro_run_131_avsmeter.log
repro_run_131_log.txt
repro_run_173_avsmeter.log
repro_run_173_log.txt
repro_run_186_avsmeter.log
repro_run_186_log.txt
repro_run_219_avsmeter.log
repro_run_219_log.txt

---

From Claude: Think I found something concrete on the IsCombedTIVTC crash. Went through IsCombedTIVTC.cpp directly.

Create_IsCombedTIVTC constructs a full TFM object with new TFM(...) and destroys it with delete f on every single call -- in our repro that's once per frame, so 200,000 construct/destroy cycles per run. That matches a heap-corruption-via-churn theory we'd been working from, now confirmed as the actual mechanism rather than a guess.

More specifically, in ConditionalIsCombedTIVTC:

int xblocks;
int mics[5] = { -20, -20, -20, -20, -20 };
int blockN[5] = { -20, -20, -20, -20, -20 };
PVideoFrame frame = child->GetFrame(n, env);
return checkCombed(frame, n, vi, 1, blockN, xblocks, mics, false, chroma, cthresh);

xblocks is declared with no initializer, right next to mics and blockN which are both explicitly zeroed/sentinel-filled. I don't have checkCombed's own source so I can't confirm whether it ever reads xblocks before writing it -- if it's a pure output param on every path this is harmless, if any branch reads-before-write it's a real bug.

What makes me think it's worth a look regardless: our crash's exit code is consistently -858993460, which as unsigned is 0xCCCCCCCC -- the standard MSVC debug-runtime fill pattern for uninitialized stack memory. Didn't want to over-read that on its own, but it lines up with the uninitialized xblocks pretty directly.

Crash reproduces at ~1.3-1.7% of runs, always after the full frame loop completes (never mid-decode), confirmed independent of ffmpeg (reproduces identically through AVSMeter with no ffmpeg in the path at all). Consistent with corruption that doesn't fault immediately but surfaces later, which fits an uninitialized-read-then-used-somewhere-downstream pattern.

If it's easy on your end, int xblocks = 0; seems like a cheap thing to test.

---

Update/retraction on the xblocks lead from my last message.

Got hold of TFMYUY2.cpp and TFMPlanar.cpp (didn't have them before) and traced checkCombedYUY2/checkCombedPlanar directly. The uninitialized xblocks isn't the cause -- withdrawing that suggestion, no need to test int xblocks = 0;.

Here's why: both functions have an early-return "cached recheck" branch --

if (mics[match] != -20) {
...
return true; // or false
}

-- and that's the only branch that skips writing xblocksi. Every other path unconditionally does xblocksi = xblocks4 before returning (TFMYUY2.cpp:70, TFMPlanar.cpp:292).

But in ConditionalIsCombedTIVTC, mics is freshly reset to {-20,-20,-20,-20,-20} immediately before the call, and match is hardcoded to 1. So mics[1]==-20 is guaranteed every single call, which means the early-return branch is never reachable from this call site -- xblocksi always gets written. And even on the branch that would skip it, xblocks is never read afterward anyway (ConditionalIsCombedTIVTC returns the checkCombed() result immediately, doesn't touch xblocks again).

So: real uninitialized declaration, still worth a defensive = 0 for hygiene, but structurally incapable of causing the crash we're seeing -- nothing ever reads it in an unwritten state on this path.

That leaves the per-frame TFM construct/destroy churn (new TFM(...) / delete f, once per frame in our repro -- 200,000 cycles/run) as the only concrete lead still standing. I don't have tooling here (no debugger, no ASan/Application Verifier access) to go further than static reading on that one. Crash rate remains ~1.3-1.7%, always after the full frame loop completes, confirmed independent of ffmpeg (reproduces identically via AVSMeter).

Sorry for the false lead -- wanted to close it out explicitly rather than leave a dead suggestion sitting in the thread.

.