DEV Community: Aditya Gaurav

Fixing Fatal Process Aborts in TensorFlow Lookup Tables

Aditya Gaurav — Sat, 12 Sep 2026 05:25:24 +0000

Few things in Python development are more disruptive than a sudden SIGABRT or core dumped error that crashes the entire Python interpreter. In managed environments, invalid inputs should raise catchable exceptions like ValueError or tf.errors.InvalidArgumentError. When a C++ kernel assertion fails instead, your process dies instantly without giving your application a chance to recover.

While investigating open issues in the tensorflow/tensorflow repository, I found an issue (#125503) where calling lookup table export operations with mismatched data types triggered an immediate crash.

Here is the breakdown of why it happened, how to trace it in TensorFlow's C++ kernels, and how we resolved it.

The Minimal Reproduction

Consider a standard tf.lookup.StaticHashTable initialized with int64 keys and values:

import tensorflow as tf

table = tf.lookup.StaticHashTable(
    tf.lookup.KeyValueTensorInitializer(
        tf.constant([0], dtype=tf.int64),
        tf.constant([1], dtype=tf.int64),
    ),
    default_value=-1,
)

# Exporting with mismatched string types
tf.raw_ops.LookupTableExportV2(
    table_handle=table.resource_handle,
    Tkeys=tf.string,
    Tvalues=tf.string,
)

Running this script immediately terminates the Python process:

Check failed: dtype() == expected_dtype (7 vs. 9)
*** Check failure stack trace: ***
Aborted (core dumped)

The error 7 vs. 9 refers to TensorFlow's internal enum data types: DT_INT64 (7) versus DT_STRING (9).

Tracing the Root Cause

In TensorFlow, lookup tables are managed in tensorflow/core/kernels/lookup_table_op.cc.

When you interact with a lookup table via operations like LookupTableFind, LookupTableInsert, or LookupTableImport, the C++ kernel first performs signature verification:

// LookupTableFindOp validates both inputs and outputs
DataTypeVector expected_inputs = {expected_input_0_, table->key_dtype(),
                                  table->value_dtype()};
DataTypeVector expected_outputs = {table->value_dtype()};
OP_REQUIRES_OK(ctx, ctx->MatchSignature(expected_inputs, expected_outputs));

ctx->MatchSignature(...) checks whether the data types requested by the Op match the actual runtime types of the underlying table. If there is a mismatch, it returns an errors::InvalidArgument status, which safely bubbles up to Python as an InvalidArgumentError.

However, looking at LookupTableExportOp:

class LookupTableExportOp : public LookupTableOpKernel {
 public:
  using LookupTableOpKernel::LookupTableOpKernel;

  void Compute(OpKernelContext* ctx) override {
    lookup::LookupInterface* table;
    OP_REQUIRES_OK(ctx, GetTable(ctx, &table));
    core::ScopedUnref unref_me(table);

    // Bypassed signature matching entirely!
    OP_REQUIRES_OK(ctx, table->ExportValues(ctx));
  }
};

LookupTableExportOp never verified signatures. It immediately called table->ExportValues(ctx), which attempts to allocate the output tensors using the table's internal key_dtype() and value_dtype().

During allocation, OpKernelContext::allocate_output asserts that the allocated tensor's data type matches the Op's output specification using a hard CHECK_EQ assertion:

CHECK_EQ(dtype(), expected_dtype);

Because the assertion is hardcoded in the allocator, any type mismatch triggered a process-level abort (SIGABRT) rather than returning an error status.

The Surgical Fix

The fix was straightforward and matches the pattern established across all other lookup table kernels in lookup_table_op.cc:

class LookupTableExportOp : public LookupTableOpKernel {
 public:
  using LookupTableOpKernel::LookupTableOpKernel;

  void Compute(OpKernelContext* ctx) override {
    lookup::LookupInterface* table;
    OP_REQUIRES_OK(ctx, GetTable(ctx, &table));
    core::ScopedUnref unref_me(table);

    DataTypeVector expected_inputs = {expected_input_0_};
    DataTypeVector expected_outputs = {table->key_dtype(),
                                       table->value_dtype()};
    OP_REQUIRES_OK(ctx, ctx->MatchSignature(expected_inputs, expected_outputs));

    OP_REQUIRES_OK(ctx, table->ExportValues(ctx));
  }
};

With MatchSignature in place, any attempt to export a table with invalid Tkeys or Tvalues is intercepted before tensor allocation.

Adding Regression Coverage

We added a unit test in tensorflow/python/kernel_tests/data_structures/lookup_ops_test.py:

def testExportSignatureMismatch(self, is_anonymous):
  if is_anonymous and not tf2.enabled():
    self.skipTest(SKIP_ANONYMOUS_IN_TF1_REASON)
  table = self.getHashTable()(
      lookup_ops.KeyValueTensorInitializer(
          constant_op.constant([0], dtype=dtypes.int64),
          constant_op.constant([1], dtype=dtypes.int64)),
      -1,
      experimental_is_anonymous=is_anonymous)
  self.initialize_table(table)
  with self.assertRaises((errors_impl.InvalidArgumentError, ValueError)):
    self.evaluate(
        gen_lookup_ops.lookup_table_export_v2(
            table.resource_handle,
            Tkeys=dtypes.string,
            Tvalues=dtypes.string))

Instead of crashing, the test cleanly verifies that Python catches tf.errors.InvalidArgumentError.

The change is submitted in Pull Request #125856.

Key Takeaways for Framework Design

Never rely on allocator assertions for input validation: Low-level allocator CHECK macros protect memory integrity, but they should be impossible for user inputs to trigger.
Consistency across sibling kernels: If five operations in a file call MatchSignature, any operation omitting it is likely an oversight that risks hard crashes.
Graceful error bubbling: When writing native C++ extensions for high-level languages like Python, always validate types at the kernel boundary so the runtime can raise standard exceptions.

Building a Vercel-Style Glass HUD for KDE Plasma 6

Aditya Gaurav — Wed, 02 Sep 2026 22:51:46 +0000

Most desktop widgets look like they were designed in 2012.

When I wanted a countdown widget on my Fedora desktop to track milestones, everything in the store was either an unmaintained Plasma 5 port or a flat grey box. I wanted something closer to Vercel's obsidian glass aesthetic: deep translucent cards, crisp tabular numbers, and specular edge lighting that catches your eye without cluttering the screen.

So I spent the last few days building Ticking from scratch in pure QML and Kirigami for KDE Plasma 6.

Here are four practical lessons from taking it from a rough local script to a published widget on the KDE Store.

1. The double frame trap

If you build a custom card in QML with rounded corners, drop shadows, and glass opacity, you will probably notice an ugly grey outline surrounding your widget when you drop it on the desktop.

Plasma 6 wraps every applet in a default system frame (PlasmaCore.Types.DefaultBackground). Because my root item drew its own full-bleed HUD card, Plasma drew a second frame around my frame.

The fix was a single line in main.qml:

Plasmoid.backgroundHints: PlasmaCore.Types.NoBackground

That drops the system container and lets your custom glass HUD float directly over your wallpaper.

2. Why your custom icon turns into a question mark

I drew a custom SVG logo for the widget with a gradient chrono track and placed it in contents/icons/org.adi_il.ticking.svg. It rendered fine inside the applet, but inside KDE's Widget Explorer drawer, it showed up as a giant question mark.

The reason is subtle. The Widget Explorer is a separate system shell process. It asks the system icon loader (KIconLoader) for the icon name listed in metadata.json. Because that custom SVG only existed inside the plasmoid package folder, the system loader could not resolve it.

If you want your widget to look clean in the system drawer on every Linux distribution out of the box, use a standard freedesktop icon name in metadata.json:

{
  "KPlugin": {
    "Icon": "chronometer",
    "Id": "org.adi_il.ticking"
  }
}

Keep your custom SVG inside contents/icons/ for internal views, but give metadata.json a standard fallback like chronometer or preferences-system-time.

3. The progress bar math problem

Ticking includes a percentage bar tracking the journey toward your target date. Initially, the code set the start date to the moment the widget was installed if no start date was configured.

That created an annoying bug for anyone who installed the widget late. If a deadline was two days away and you installed the widget today, your progress showed 0.000% instead of 95%.

To fix this, I added dual graphical date pickers in the settings dialog: one for the Start Date and one for the End Date. Both automatically normalize to midnight (00:00:00 UTC), so users pick the calendar days and get an accurate elapsed percentage without fiddling with UTC timestamps.

4. Adaptive timers save laptop batteries

A live countdown with sub-second milliseconds needs to tick every 40ms (~25 FPS) for smooth animation. But running a 40ms timer continuously while the widget is collapsed in a panel will drain laptop battery for zero benefit.

In main.qml, I bound the timer interval to the widget visibility state:

Timer {
    id: tickerTimer
    interval: {
        var isVisible = (Plasmoid.expanded || Plasmoid.formFactor === PlasmaCore.Types.Planar);
        if (!isVisible) return 1000;
        if (root.stopwatchData.running || Plasmoid.configuration.showMilliseconds) return 40;
        return 1000;
    }
    running: true
    repeat: true
    onTriggered: root.updateAllMetrics()
}

When collapsed in the panel, it throttles to one second. When opened or floating on the desktop, it runs at high precision.

Ticking is open source on GitHub and live on the KDE Store:

GitHub: https://github.com/adi-IL/ticking-plasmoid
KDE Store: https://store.kde.org/p/2370240/

How a tiny naming quirk hid seventy tests in Google Mug

Aditya Gaurav — Sun, 23 Aug 2026 18:28:13 +0000

I spent my morning digging into google mug and came away with a fun debugging story.

While reading through their dot parse regex engine I noticed malformed escape sequences like incomplete unicode or empty character names were quietly passing through. A broad fallback rule was catching them and turning them into plain letters.

Looking deeper into the test folder I found an entire suite of error tests that had never been running in ci simply because the file name had a plural s at the end.

I renamed the test file so maven would pick it up, tightened the escape parser rules, and opened a pull request.

The lead maintainer reviewed it within hours, suggested adding a few more characters to the exclusion set to catch property edge cases, and merged the whole thing.

Fixing a silent parsing bug and bringing seventy tests back to life in one morning felt pretty sweet.

You can check out the merged pull request here: https://github.com/google/mug/pull/130

When Your AI Skill Calls a Ghost: Retiring Zombie Models in Anthropic Skills

Aditya Gaurav — Sun, 23 Aug 2026 13:51:13 +0000

Imagine this scenario. You build an autonomous agent pipeline. You wire in standard skills, configure your API keys, grab a cup of coffee, and watch it tackle complex tasks. Everything feels futuristic.

Then suddenly, a cold splash of reality hits your logs:

Error: 404 Not Found - model 'claude-opus-4-20250514' has been retired.

No timeout. No rate limit. Just an abrupt HTTP 404 from the Anthropic API. Your autonomous agent just spent five minutes trying to summon a ghost.

Here is the story of how dead model identifiers linger inside official agent skills, how an autonomous AI babysitter bot reviewed my pull request, and why keeping documentation in sync across files is harder than it looks.

Act 1: The Zombie Model Problem

Large Language Model development moves at breakneck speed. New checkpoints drop, older snapshots get deprecated, and eventually, older model IDs get decommissioned completely.

In the official anthropics/skills repository, the claude-api skill is supposed to be the source of truth for how agent frameworks talk to Claude. It tells agents which model strings to use, which models support adaptive thinking, and which models have reached end-of-life.

While inspecting skills/claude-api/shared/models.md and skills/claude-api/shared/model-migration.md, I noticed several prominent models were still marked as "Deprecated (retiring soon)" even though their retirement dates had already passed:

claude-opus-4-20250514 (retired June 15, 2026)
claude-sonnet-4-20250514 (retired June 15, 2026)
claude-3-haiku-20240307 (retired April 19, 2026)
claude-opus-4-1-20250805 (retired August 5, 2026)

If an agent reads this skill table to resolve friendly names (such as "opus 4" or "haiku 3"), it would attempt to call a decommissioned model ID instead of routing to modern replacements like claude-opus-4-8, claude-sonnet-5, or claude-haiku-4-5.

The fix looked simple enough: remove the outdated "Deprecated" table, move all four models into the "Retired" table, and point alias resolutions to active successors.

I submitted PR #1607 feeling satisfied. Simple documentation cleanup. Easy victory. Right?

Wrong.

Act 2: Enter the Cron Babysitter

A few hours after opening the PR, a GitHub notification popped up. A review had arrived.

Except it was not from a human maintainer. It came from an autonomous agent calling itself:

Reviewed by Hermes Agent (cron babysitter)
Verdict: Comment: correct and useful model-status update; two cross-file consistency nits.

There is something wonderfully surreal about writing open-source code for AI skills, only to have an automated AI agent run a cron job, read your git diff, and evaluate your work like a sharp-eyed proofreader.

And Hermes was not giving generic praise. It found two very real, very subtle cross-file discrepancies that I had missed:

Nit 1: The One-Day Time Slip

In model-migration.md, the old deprecated table had listed claude-3-haiku-20240307 retiring on April 19, 2026. But in my new table rows in models.md, I had typed April 20, 2026.

A single day difference. To a casual reader, April 19 versus April 20 is trivia. But to an API consumer writing automated compliance checks, date drift between sibling markdown files creates confusion.

Nit 2: The Missing Opus Row

In models.md, I had added claude-opus-4-1-20250805 to the Retired table. But in model-migration.md, I had forgotten to add claude-opus-4-1-20250805 to its corresponding migration table.

The two documentation files inside the same skill were out of sync.

Act 3: The Surgical Reconciliation

The feedback was spot on.

I checked Anthropic's official release timeline to verify the canonical retirement date: April 19, 2026 was the exact date.

Then I made two surgical updates:

skills/claude-api/shared/model-migration.md: Added claude-opus-4-1-20250805 pointing to drop-in replacement claude-opus-4-8, and standardized claude-3-haiku-20240307 to April 19, 2026:

| Retired model                 | Retired       | Drop-in replacement  |
| ----------------------------- | ------------- | -------------------- |
| `claude-opus-4-1-20250805`    | Aug 5, 2026   | `claude-opus-4-8`    |
| `claude-opus-4-20250514`      | Jun 15, 2026  | `claude-opus-4-8`    |
| `claude-sonnet-4-20250514`    | Jun 15, 2026  | `claude-sonnet-5`    |
| `claude-3-haiku-20240307`     | Apr 19, 2026  | `claude-haiku-4-5`   |

skills/claude-api/shared/models.md: Synchronized the retirement date for Haiku 3 to April 19, 2026, ensuring complete cross-file consistency.

Pushed commit bdff74f to the branch and replied to the review thread.

Takeaways from the Trenches

Agent skills are software, not static prose: In traditional documentation, a typo is a visual annoyance. In an agent skill, a stale model ID or wrong parameter definition directly breaks autonomous execution loops in production.
Watch out for multi-file documentation drift: When a repository maintains multiple guides describing the same underlying domain (like models.md and model-migration.md), always audit every sibling file when updating a status.
Embrace autonomous babysitters: Automated PR review bots running static cross-reference checks can catch real human oversights long before core maintainers sit down to triage the queue.