Detecting Memory LeaksSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: detecting-memory-leaks
description: Detect potential memory leaks and analyze memory usage patterns in code.
  Use when troubleshooting performance issues related to memory growth or identifying
  leak sources. Trigger with phrases like "detect memory leaks", "analyze memory usage",
  or "find memory issues".
version: 1.24.0
allowed-tools: Read, Write, Edit, Grep, Glob, Bash(profiling:*), Bash(memory:*)
license: MIT
author: Jeremy Longshore <[email protected]>
tags:
- performance
- detecting-memory
compatibility: Designed for Claude Code
---
# Memory Leak Detector

Detect and diagnose memory leaks in Node.js, Python, and JVM applications by analyzing event listeners, closures, unbounded caches, and retained references.

## Overview

This skill helps you identify and resolve memory leaks in your code. By analyzing your code for common memory leak patterns, it can help you improve the performance and stability of your application.

## How It Works

1. **Initiate Analysis**: The user requests memory leak detection.
2. **Code Analysis**: The plugin analyzes the codebase for potential memory leak patterns.
3. **Report Generation**: The plugin generates a report detailing potential memory leaks and recommended fixes.

## When to Use This Skill

This skill activates when you need to:

- Detect potential memory leaks in your application.
- Analyze memory usage patterns to identify performance bottlenecks.
- Troubleshoot performance issues related to memory leaks.

## Examples

### Example 1: Identifying Event Listener Leaks

User request: "detect memory leaks in my event handling code"

The skill will:

1. Analyze the code for unremoved event listeners.
2. Generate a report highlighting potential event listener leaks and suggesting how to properly remove them.

### Example 2: Analyzing Cache Growth

User request: "analyze memory usage to find excessive cache growth"

The skill will:

1. Analyze cache implementations for unbounded growth.
2. Identify caches that are not properly managed and recommend strategies for limiting their size.

## Best Practices

- **Code Review**: Always review the reported potential leaks to ensure they are genuine issues.
- **Regular Analysis**: Incorporate memory leak detection into your regular development workflow.
- **Targeted Analysis**: Focus your analysis on specific areas of your code that are known to be memory-intensive.

## Integration

This skill can be used in conjunction with other performance analysis tools to provide a comprehensive view of application performance.

## Prerequisites

- Access to application source code in ${CLAUDE_SKILL_DIR}/
- Memory profiling tools (valgrind, heapdump, etc.)
- Understanding of application memory architecture
- Runtime environment for testing

## Instructions

1. Analyze code for common memory leak patterns
2. Identify unremoved event listeners and callbacks
3. Check for unbounded cache growth
4. Review closure usage and retained references
5. Generate report with leak locations and severity
6. Provide remediation recommendations

## Output

- Memory leak detection report with file locations
- Pattern analysis for event listeners and caches
- Memory usage trends and growth patterns
- Code snippets highlighting potential leaks
- Recommended fixes with code examples

## Error Handling

If memory leak detection fails:

- Verify code file access permissions
- Check profiling tool installation
- Validate code syntax and structure
- Ensure sufficient memory for analysis
- Review runtime environment configuration

## Resources

- Memory profiling tool documentation
- Memory leak detection best practices
- JavaScript/Node.js memory management guides
- Performance optimization resources

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.