DEV Community: SickleFire

M-vis v0.5.0-rc1 update

SickleFire — Tue, 07 Jul 2026 12:11:10 +0000

[0.5.0-rc1] - 2026-07-6
Added

CI/CD Mode: Full programmatic integration layer with JSON/CSV export, differential leak detection (--diff-only), configurable sampling, and growth rate monitoring.
Enhanced TUI: keyboard-driven process selection, quick action buttons.
Improved Leak Detection: Better Linux heap walk via /proc/maps, optimized memory diff algorithms for large heaps.

Catching Memory Leaks in CI with `mvis` v0.5.0-rc1

mvis now ships as a reusable GitHub Action, so you can drop heap monitoring and leak detection straight into your existing workflow — no manual binary download, no custom scripts. This post walks through setting it up using the v0.5.0-rc1 pre-release.

What the action does

Under the hood, the action:

Downloads the right mvis binary for the runner's OS and architecture (Linux, Windows, or macOS — Intel or Apple Silicon).
Builds a mvis ci command from your inputs.
Runs it against a PID, a fuzzy process name, or a command you want it to spawn and watch.

Basic usage

- name: Run mvis memory audit
  uses: SickleFire/m-vis@v0.5.0-rc1
  with:
    version: v0.5.0-rc1
    spawn: ./target/release/my_app
    max-memory: 512
    duration: 60

This spawns my_app, watches it for 60 seconds, and fails the step if it ever exceeds 512 MB RSS.

On Windows, max-memory currently depends on the underlying heap-walk succeeding. If the walk itself errors out for some reason, mvis can still complete the step rather than failing loud — worth keeping in mind if a step passes suspiciously easily.

Choosing a target

You need exactly one of these three inputs:

Input	Use case
`spawn`	You want `mvis` to launch and own the process. Must be the last thing you configure — anything after it in the composite action's internal command line gets treated as arguments to your spawned command, not to `mvis`.
`pid`	You already have a running process (e.g. started in an earlier step) and just want to attach.
`process-name`	Fuzzy-match against running processes by name — handy when the PID isn't known ahead of time.

Note: spawn currently needs a path with a separator in it — ./my_app, build/my_app.exe — even when the binary sits right in the working directory. A bare filename like spawn: my_app.exe fails with program not found, because the path-resolution logic doesn't fall back to checking the current directory the way a shell normally would. Always prefix with ./ (or the equivalent relative path) to be safe.

# Attach to an already-running process by PID
- name: Start server
  run: ./server & echo "pid=$!" >> "$GITHUB_OUTPUT"
  id: server

- name: Monitor it
  uses: SickleFire/m-vis@v0.5.0-rc1
  with:
    version: v0.5.0-rc1
    pid: ${{ steps.server.outputs.pid }}
    duration: 120
    max-memory: 1024

Monitoring flags

max-memory — fail the step if RSS crosses this many MB.
leak-check — compares a baseline snapshot against the end state and fails if net-retained memory looks like a leak rather than expected steady-state growth.
duration — how long to watch before mvis exits (in seconds). If omitted, mvis watches until the target process exits on its own.

You can combine max-memory and leak-check in the same run — mvis will fail the step on whichever condition trips first.

A note on macOS

The macOS binaries are ad-hoc signed with an entitlements file so mvis can inspect another process's memory. This is still being hardened for CI use — if you're running the smoke-test / action-triggered flow on macos-latest and see it hang rather than pass or fail cleanly, that's a known area under active investigation rather than a config mistake on your end. Linux and Windows runners aren't affected.

Full example: fail PRs on memory regressions

name: Memory check
on: [pull_request]

jobs:
  memory-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build app
        run: cargo build --release

      - name: Run mvis memory audit
        uses: SickleFire/m-vis@v0.5.0-rc1
        with:
          version: v0.5.0-rc1
          spawn: ./target/release/my_app
          max-memory: 256
          leak-check: true
          duration: 45

That's it — one job, no custom scripting, catching memory regressions before they merge.

Author:

SickleFire

See M-vis, leave a star, a bug report and PR is always welcomed!

Designing a cross-platform terminal memory visualizer in Rust

SickleFire — Sun, 28 Jun 2026 08:14:27 +0000

The Why

Before diving into the design of m-vis, let's first get into why. The spark for this project came while I was building a 3D interactive model viewer in C++ using OpenGL. As the complexity of the renderer grew, so did a notoriously frustrating problem: memory leaks. Tracking down stray allocations in a real-time, graphics-heavy application quickly turned into a tedious game of whack-a-mole.

I realized I didn't just want to fix my code; I wanted to fundamentally solve the problem of how we detect, track, and understand memory leaks in the first place. That frustration is what drove me to build a tool that makes memory management visual, intuitive, and painless.

The Vision

I envisioned this project to prioritize user experience and simplicity above all else. Not only that it must be cross-platform; Because of this Rust is the perfect choice, because of its compiler make cross-compilation remarkably smooth.

A memory visualizer is useless if it slows down the target application so much that it alters its runtime behavior or masks the very bugs you are trying to find. In graphics-heavy or real-time applications like a 3D model viewer, keeping execution overhead to an absolute minimum is mandatory. Because of that requirement, non-invasive memory scanning techniques are used.

The Architecture

M-vis has 3 distinct stages:

Memory Provider (OS Layer)
Core Engine
UI (CLI, TUI)

The Memory Provider is the most interesting stage because this stage gathers heap and region metadata that the Core uses. However, one of our requirements is it must be a cross-platform. So how does the Memory Provider know which Operating System you are running on without adding a bunch of messy runtime checks?

The answer is Rust's conditional compilation. We can tell the compiler which code to run, based on your toolchain.

The Memory Provider Trait

To bridge the gap between platform-specific chaos and a clean, unified architecture, we need a strict contract. In Rust, that means defining a trait.

The Core Engine shouldn't care whether it is talking to Linux's /proc filesystem or the Windows Win32 API; it just needs data. By defining a single interface, every operating system module must implement the exact same behaviors.

/// Abstraction over OS-specific memory inspection APIs.
pub trait MemoryProvider {
    /// Returns all virtual memory regions mapped into the process with the given `pid`.
    fn walk_regions(&self, pid: u32) -> Result<Vec<Region>, String>;
    /// Returns all heap blocks (both used and free) for the process with the given `pid`.
    fn walk_heap(&self, pid: u32) -> Result<Vec<HeapBlock>, String>;
    /// Returns loaded modules for the process with the given `pid`.
    ///
    /// Pass `"-t"` as `flag` to restrict the output to tampered or injected modules only.
    fn list_modules(&self, pid: u32, flag: String) -> Result<Vec<ModuleInfo>, String>;
}

This is the Memory Provider trait that every operating system backend must implement. Its core job is translation. It maps messy, platform-specific memory data into clean, platform-agnostic data structures—specifically HeapBlock and Region—that our core engine can easily understand.

Region Struct:

pub struct Region {
    pub base: usize,
    pub size: usize,
    pub state: RegionState,
    pub kind: RegionKind,
    pub protect: RegionProtect,
    pub name: String,
}

Heap Block:

pub struct HeapBlock {
    pub address: usize,
    pub size: usize,
    pub is_free: bool,
    pub vm_protect: RegionProtect,
}

The Core

The Core is the central engine of m-vis, responsible for two primary tasks: process scanning and data differentiation. It takes the platform-agnostic blocks provided by the OS layer and processes them to identify trends and track allocations.

We won't dive deep into the Core's internals in this post, as our primary goal is to look at the cross-platform engineering behind gathering the data itself.

The UI (CLI & TUI)

The final stage of the architecture is the presentation layer. Once the Core Engine has processed the raw memory data into identifiable trends, it hands that data package off to the user interface.

To keep the project lightweight and accessible, the UI layer is split into two modes:

CLI Mode: A traditional command-line interface designed for quick, scriptable, or text-only memory snapshots. It is perfect if you want a fast terminal output without any visual overhead.
TUI Mode: This is where m-vis comes to life. Written natively in Rust using Ratatui, the Terminal User Interface transforms the raw allocation into interactive blocks, Leak delta chart, and Allocation tables.

Conclusion

By designing a clean Memory Provider trait and leaning on Rust's compile-time conditional compilation, the tool stays completely cross-platform without adding any runtime bloat.

Building m-vis started because I was exhausted of encountering memory leaks in OpenGL/C++. My personal frustration turned into a passion project that will not only help me but will also make finding memory leaks effortless for other people.

Check out m-vis: https://github.com/SickleFire/m-vis

Authors:

SickleFire - Owner
Djo - Community Manager

Visualizing the Slope: Introducing the m-vis Real-Time Leak Delta Chart

SickleFire — Tue, 09 Jun 2026 11:14:35 +0000

Debugging memory leaks by watching a wall of flashing text numbers is a guessing game. You can see the numbers moving, but you entirely miss the trends, spikes, and rhythm of your application.

To solve this, m-vis has introduced: the Real-Time Leak Delta Chart.

By translating raw allocation differentials into a live, scrolling historical timeline right inside your terminal, m-vis shifts memory debugging from a game of parsing numbers to simple, immediate pattern recognition.

What is the Leak Delta Chart?

The Leak Delta Chart is a dedicated visual component in the TUI that maps the output of the core LeakDelta engine over time. Instead of showing you the total size of your application's memory, it charts the net balance of every single cycle (Allocated Bytes minus Freed Bytes).

The chart centers around a Zero Baseline Axis:

Above the Axis (Positive): Represents net memory accumulation (the app claimed bytes it didn’t return).
Below the Axis (Negative): Represents net memory reclamation (the app actively cleaned up more than it took).

What it looks like in your terminal:

This graph illustrates an application experiencing a persistent memory leak. The steady upward trend above the baseline indicates that memory is continuously being allocated but not properly released.

Try it Out

m-vis is built to be simple to use, lightweight, and completely cross-platform.

If you want to move past parsing raw text numbers and actually see your memory behavior, check out the project on GitHub:

Check out m-vis on GitHub

Let me know what you think in the comments, or what features you'd love to see added to the TUI next!

Mvis: Memory Debugging Made Simple and Accessible

SickleFire — Sun, 03 May 2026 16:25:43 +0000

Debugging memory leaks has always been one of those tasks developers dread.

Tools like Valgrind or WinDbg are powerful, but they’re either platform‑specific or too complex for quick diagnostics. I wanted something different: a tool that gives developers answers fast.

That’s the philosophy behind Mvis — a Rust‑based memory visualizer and leak detector.

Why Mvis

Mvis is built around three guiding principles:

Simplicity: One command should be enough to get useful insights.

Accessibility: Debugging shouldn’t be locked behind steep learning curves.

Cross‑platform: Whether you’re on Windows or Linux, the workflow should feel the same.

Or as I like to put it:
“One command. All platforms. No configuration hell.”

What it can do

Even in its early stage, Mvis already supports:

Process scanning: Inspect allocations of active processes.
Heap‑level analysis: See heap structures in detail.
DLL tracking: Monitor loaded libraries.
Leak detection: Identify processes with growing, unreleased allocations.
Stack tracing: Capture call stacks to pinpoint allocation sources.

Supported OS: Windows and Linux.

Quick Usage Examples

# visualize memory map
mvis scan myapp.exe -a

# detect leaks
mvis leak leaking_app.exe 10

# multi-sample leak detection
mvis leak-m myapp.exe 10 3

Outputs are clear and exportable to JSON(Scan), making analysis and visualization easy.

Example: Leak Detection

mvis leak leaking_app.exe 10

Insights

One of the first problems I encountered was:

How do I make Mvis work on both Windows and Linux?

The answer turned out to be simple: platform abstraction.
Mvis defines abstractions for memory regions and heap blocks, which means the core logic doesn’t depend on OS‑specific quirks.

Because of this design, it’s possible to extend support to other platforms in the future — as long as they implement the same abstraction layer Mvis uses..

Roadmap

Mvis is still early but functional. Here’s what’s coming next:

TUI frontend for heap analysis (lightweight by design).
Heap fragmentation visualization.
Realtime heap scanning.
macOS support.
Performance improvements.

Try it out

SickleFire / m-vis

lightweight cross-platform memory visualizer tool

mvis

mvis: Memory debugging for developers who just want answers Simple. Fast. Works everywhere.

Why mvis?

Existing tools are either platform-specific (Valgrind, WinDbg) or too complex for quick diagnostics. mvis gives you memory insights with a single command on any platform.

Our design philosophy is built around simplicity and accessibility because We believe memory debugging should be accessible, not a PhD requirement.

"One command. All platforms. No configuration hell."

Status

Early but functional. Core scanning and leak detection work on both platforms. See the roadmap below for what's coming.

Features

Process Scanning: Inspect memory allocations of active processes.
Heap-Level Analysis: Dive into heap structures for detailed debugging.
DLL Tracking: Monitor and list all DLLs loaded by a target.
Memory Leak Detection: Identify and monitor processes with growing, unreleased allocations.
Stack Tracing: Capture call stacks to pinpoint allocation sources and trace execution paths.
Supported OS…

View on GitHub

Feedback, contributions, and ideas are welcome. Let’s make memory debugging easier for everyone.