{"record":{"id":"854672a4d2bdb68c","repo":"dotnet/runtime","slug":"out-of-memory-in-indx256-indexstring","errorCode":null,"errorMessage":"\nOut of memory in Indx256::IndexString!\n","messagePattern":"\nOut of memory in Indx256::IndexString!\n","errorType":"console","errorClass":null,"httpStatus":null,"severity":"critical","filePath":"src/coreclr/ilasm/asmtemplates.h","lineNumber":234,"sourceCode":"    void ClearAll(bool DeleteObj)\n    {\n        if(DeleteObj) delete item;\n        item = NULL;\n        ClearOneTable(tableLow, DeleteObj);\n        ClearOneTable(tableHigh, DeleteObj);\n    };\n\nprivate:\n    T** IndexStringOneTable(Indx256*& table, BYTE value, BYTE* next, T* pObj)\n    {\n        // Ensure that child table exists.\n        if(table == NULL)\n        {\n            table = new Indx256[INDX256_TABLE_SIZE] {};\n            if(table == NULL)\n            {\n                _ASSERTE(!\"Out of memory in Indx256::IndexString!\");\n                fprintf(stderr,\"\\nOut of memory in Indx256::IndexString!\\n\");\n                return NULL;\n            }\n        }\n\n        // Find the child node for the current BYTE at continue at the next BYTE.\n        return table[value].IndexString(next,pObj);\n    }\n\n    T* FindStringOneTable(Indx256* table, BYTE value, BYTE* next)\n    {\n        if(table == NULL)\n        {\n            // If there are no child nodes, then there is nowhere to\n            // look for this key.\n            return NULL;\n        }\n\n        return table[value].FindString(next);","sourceCodeStart":216,"sourceCodeEnd":252,"githubUrl":"https://github.com/dotnet/runtime/blob/290d5ab72cc1102813fbc0406fb186ceadabc340/src/coreclr/ilasm/asmtemplates.h#L216-L252","documentation":"Printed by Indx256::IndexStringOneTable in asmtemplates.h when 'new Indx256[INDX256_TABLE_SIZE] {}' returns NULL. The function also fires an _ASSERTE (debug break in chk builds) and returns NULL, propagating NULL up IndexString. Indx256 is a 256-way trie used to index named labels/symbols in ilasm.","triggerScenarios":"Adding a new unique key (label/symbol name) to the trie requires allocating a fresh 128-element child table; that allocation fails. Happens with extremely large numbers of distinct names (e.g. ildasm-style IL_<hex> labels from huge methods).","commonSituations":"Assembling IL generated from very large methods or many types; the trie is documented as memory-intensive; OOM under memory pressure or 32-bit.","solutions":["Reduce the number of distinct labels/symbols in the input (split methods/assemblies).","Use 64-bit ilasm with higher memory.","If patching, replace the dense Indx256 with a hashtable (the header comment suggests this), which would drastically cut memory.","Raise process memory limits."],"exampleFix":null,"handlingStrategy":"validation","validationCode":"# the trie is memory-heavy; limit distinct label count by splitting methods\nLABELS=$(grep -cE '^[[:space:]]*IL_[0-9a-f]+$' big.il)\n[ \"$LABELS\" -lt 1000000 ] || echo \"~$LABELS distinct labels - Indx256 may exhaust memory\"","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Reduce distinct label/symbol counts by splitting large methods or assemblies.","Use 64-bit ilasm with high memory limits.","If patching ilasm, consider replacing Indx256 with a hashtable per the header comment."],"tags":["ilasm","memory","out-of-memory","indx256","trie"],"analyzedSha":"290d5ab72cc1102813fbc0406fb186ceadabc340","analyzedAt":"2026-08-06T19:57:01.276Z","schemaVersion":2},"datasetVersion":"2026-08-06T23:17:07.152Z"}