{
"repo": "slab-hunter",
"timestamp": "2026-01-16T23:55:52.323Z",
"entryPoint": "index.js",
"exports": {
"packageJson": {
"main": "index.js"
}
},
"api": {
"file": "index.js",
"exports": [
{
"type": "default",
"name": "setupSlabHunter"
}
],
"classes": [
{
"name": "LeakOverview"
}
],
"functions": [
{
"name": "monkeyPatchBuffer"
},
{
"name": "allocUnsafeMonkeyPatch"
},
{
"name": "getLeakOverview"
},
{
"name": "setupSlabHunter"
}
]
},
"readme": {
"content": "# Slab Hunter\n\nHunt down Buffer slabs which are retaining more memory than they should.\n\nWarning: this is a debugging tool, do not use it in production code.\n\nIt detects two behaviours indicative of potential memory leaks:\n- Slab retainers: long-lived buffers which are part of a slab.\n - A typical leak here is caused by using `Buffer.allocUnsafe()` or `Buffer.from()` for long-lived buffers.\n - The solution is to [unslab](https://github.com/holepunchto/unslab) the buffers, or to use `b4a.allocUnsafeSlow()` instead.\n- Big buffers which are long-lived\n - A typical leak here is data being loaded from a networked stream or file-system stream, where the data of a single data-event is all loaded on a shared slab, and some long-lived data is defined using `Buffer.subarray()` or similar, which does not copy out the data.\n - The solution for such a leak is to take a heap snapshot, based on which you can figure out which buffers are retaining the overall slab, and to explicitly [unsla",
"sections": [
"intro",
"usage",
"api"
],
"hasApi": true,
"hasExamples": true,
"exampleCount": 6,
"examples": [
"npm i -g slab-hunter\nslab-hunter <entrypoint>",
"slab-hunter index.js",
"const setupSlabHunter = require('slab-hunter')\n\nconst getLeakStats = setupSlabHunter()\nsetInterval(() => {\n console.log(getLeakStats())\n}, 1000 * 60 * 2)"
]
},
"patterns": []
}