dotnet/runtime · critical

Out of memory!

Error message

Out of memory!

What it means

Printed by FIFO<T>::PUSH in asmtemplates.h when the grow path's 'new T*[m_ulArrLen]' returns NULL. The array pointer is left unchanged but PUSH still writes to m_Arr at the (now too small) index — a latent correctness issue. As with 215, throwing new makes this branch effectively dead under standard semantics.

Source

Thrown at src/coreclr/ilasm/asmtemplates.h:104

				if(m_ulOffset)
				{
					memcpy(m_Arr,&m_Arr[m_ulOffset],m_ulCount*sizeof(T*));
					m_ulOffset = 0;
				}
				else
				{
                    m_ulArrLen = GrowBuffer(m_ulArrLen);
					T** tmp = new T*[m_ulArrLen];
					if(tmp)
					{
						if(m_Arr)
						{
							memcpy(tmp,m_Arr,m_ulCount*sizeof(T*));
							delete [] m_Arr;
						}
						m_Arr = tmp;
					}
					else fprintf(stderr,"\nOut of memory!\n");
				}
			}
			m_Arr[m_ulOffset+m_ulCount] = item;
			m_ulCount++;
		}
    };
    ULONG COUNT() { return m_ulCount; };
    T* POP()
    {
        T* ret = NULL;
        if(m_ulCount)
        {
            ret = m_Arr[m_ulOffset++];
            m_ulCount--;
        }
        return ret;
    };
    T* PEEK(ULONG idx) { return (idx < m_ulCount) ? m_Arr[m_ulOffset+idx] : NULL; };

View on GitHub (pinned to 290d5ab72c)

Solutions

  1. Reduce input size or split the assembly.
  2. Run 64-bit ilasm with more memory.
  3. Raise process memory limits.
  4. If patching ilasm, change 'new T*[...]' to 'new (std::nothrow) T*[...]' consistently and bail cleanly, or let std::bad_alloc propagate.
Defensive patterns

Strategy: validation

Validate before calling

# shrink input before assembling; aim for well under available memory
ILSIZE=$(stat -c%s big.il 2>/dev/null || stat -f%z big.il)
[ "$ILSIZE" -lt 268435456 ] || echo "big.il is $((ILSIZE/1024/1024))MB - consider splitting"

Prevention

When it happens

Trigger: FIFO (queue) template used by ilasm grows its backing array via GrowBuffer() (50% up to 2048) but the new allocation fails. Happens when assembling inputs that push many items through the queue.

Common situations: Large IL with many named items routed through a FIFO; memory-constrained process; 32-bit address space.

Related errors


AI-assisted analysis of dotnet/runtime@290d5ab72c (2026-08-06). Data as JSON: /api/errors/abd895871d490afa. Report an issue: GitHub.