BUKYA NARESH

Posted on Jul 29

Building a Zero-Copy Cloud Billing Parser in C11: Tracing an mmap() Lifetime Bug published: true

#c #systemsprogramming #linux #finops

Enterprise cloud billing exports (like AWS CUR 2.0 or Azure Cost Management) scale into multi-gigabyte matrices, feature unpredictable column order anomalies, and cause rounding drift when parsed using floating-point types.

Billing Data Gateway resolves this structural inefficiency. It is a zero-dependency C11 systems core designed to ingest, auto-detect, and map heterogeneous hyperscaler billing datasets into an immutable in-memory array known as the Intermediate Financial Model (IFM).

To achieve maximum throughput under hardware constraints, the architecture enforces a strict invariant: zero dynamic heap allocations (malloc/calloc) inside the row processing loops.

📐 Ingestion Pipeline Architecture

Data flows end-to-end within virtual memory, maintaining a layout-decoupled footprint:

POSIX mmap() Engine: Projects raw file descriptors straight into the process virtual address space, maximizing kernel-to-userland page fault transfer speeds.
Dynamic Provider Registry: Scans the first byte rows at runtime to identify the source hyperscaler schema signature, cleanly loading the correct vendor adapter.
Schema Inversion Adapters: Normalizes out-of-order column sequence drift at runtime using dynamic lookup tracking index arrays.
Zero-Copy Tokenizer: Winds token positions using fixed slice windows (str_slice_t) tracking pointer coordinates and lengths, bypassing string allocation costs.
Fixed-Point Currency Core: Parses cost figures natively out of raw text blocks straight into int64_t micro-currency coordinates ($1.00 = 1,000,000 µ$), completely isolating the system from floating-point inaccuracies.

💥 The Crash: A Dangling Pointer in Zero-Copy Memory Space

While implementing a zero-allocation streaming JSON output module (-f json), the engine hit a hard memory protection violation:
Segmentation fault (core dumped)

Because a zero-copy parser does not duplicate strings into heap memory, every str_slice_t points straight to the virtual memory addresses paged by the mmap() initialization call.

The GDB Investigation Trace

Instead of guessing or hacking random logic modifications, the pipeline was compiled with full debug symbols (-g) and executed under the GNU Debugger (gdb).

Capturing the function backtrace (bt) isolated the exact breakdown lane inside the standard library string measurement functions:
__strnlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76

Selecting the loop context frame and printing the record state variable (print records[0]) exposed the root architectural mismatch:

usage_start_raw = {
    ptr = 0x7ffff7fbc0d8 <error: Cannot access memory at address 0x7ffff7fbc0d8>, 
    len = 10
}

The Diagnosis

The length field was valid (10), but the pointer was pointing to a memory coordinate address space that the operating system kernel reported as unreadable.

Tracing the code pipeline layout upstream revealed the lifecycle leak: the parsing function wrapper successfully processed the rows, stored the memory pointers in the record array, and then closed the memory map (mmap_close()) to clean up resources before returning control to main().

The moment the downstream JSON serializer attempted to stream out the slices, it was dereferencing dead, unmapped virtual pointers.

🛠️ The Memory Ownership Refactor

To preserve the zero-copy capability safely, the memory page lifetime must span the entire lifecycle of both the parsing modules and the output serialization planes.

Root Ownership: Transferred the mmap_file_t resource structure allocation wrapper entirely to the top-level application lifecycle execution context (main.c).
Deferred Teardown: File mapping boundaries are initialized at the absolute system ingress point and unmapped (mmap_close()) only after all downstream output formats finish streaming out.

/* Output System serialization runs safely while the memory map remains alive */
if (format_arg && strcmp(format_arg, "json") == 0) {
    serializer_write_json(stdout, records, out_count);
    free(records);
    mmap_close(&mfile); /* Safe close out after serialization reads finish */
    return 0;
}

📊 Result & External Validation

Recompiling under aggressive compilation target profiles (-Wall -Wextra -O3), the architecture successfully streams high-speed records straight into pipe configurations, verified as 100% syntactically correct JSON via external Linux pipeline tools:

./billing-gateway -i data/aws_cur_shifted.csv -f json | jq .

Verified Stream Snapshot

[
  {
    "source_line": 2,
    "provider": "AWS_CUR",
    "account_id": "",
    "resource_id": "",
    "usage_start_raw": "1700000000",
    "billed_cost": 45.800000
  }
]

💡 Key Architectural Lessons

Memory Ownership is Strategy: In zero-copy processing systems, data structures are bound to the lifetime of their files. Component ownership design must match the data usage spectrum.
Evidence Over Speculation: GDB and shell pipeline tools (jq) tell the absolute truth. Never rewrite consumer code when your upstream data coordinates are corrupted.

💻 Deep Dive into the Codebase Matrix

The source core files, integration test harnesses, and throughput profiling suites are live and public:
👉 GitHub Repository: https://github.com/CloudOps-Financial-Platform/billing-data-gateway

DEV Community