TSV_TNEW_PAGE_ALLOC_FAILED

The ABAP runtime ran out of memory while growing an internal table or string.

The program asked the kernel to allocate another memory page for an internal table or large string and the work process had no more memory available.

Symptom

ST22 shows:

Runtime Errors         TSV_TNEW_PAGE_ALLOC_FAILED
Short text             No more storage space available for extending an internal table.

The dump line is the statement that triggered the last growth — an APPEND, INSERT, a SELECT INTO TABLE, or a string operation. The work process memory limit (set in the system profile) has been reached.

Cause

Common trigger	Explanation
SELECT * FROM bigtable INTO TABLE @lt_all with no UP TO N ROWS	Reads millions of rows into memory
Unbounded LOOP building a result table	Result grows without limit
Large file upload parsed row-by-row into a table	File is larger than available WP memory
Deep string concatenation in a loop	String grows to hundreds of MB
Recursive method calls building intermediate tables	Memory accumulates across the call stack

Work process memory limit

The limit is controlled by the profile parameter abap/heap_area_dia (dialog) and abap/heap_area_nondia (background). Typical values are 2 GB for dialog, 4–8 GB for background. Raising the limit postpones the dump but does not fix the root cause.

Reproduce

DATA lt_all TYPE STANDARD TABLE OF bkpf.

" On a system with millions of accounting documents, this dumps:
SELECT * FROM bkpf INTO TABLE @lt_all.

Fix

Add UP TO N ROWS for ad-hoc queriesProcess data in chunks (package cursor)Use a background job for large datasetsAvoid intermediate tables with LOOP + DELETE

SELECT * FROM bkpf
  INTO TABLE @DATA(lt_sample)
  WHERE bukrs = @lv_bukrs
  UP TO 1000 ROWS.

DATA lt_chunk TYPE STANDARD TABLE OF bkpf.

SELECT * FROM bkpf
  INTO TABLE @lt_chunk
  PACKAGE SIZE 5000
  WHERE bukrs = @lv_bukrs.

  " lt_chunk holds at most 5000 rows per iteration
  LOOP AT lt_chunk INTO DATA(ls_doc).
    " process
  ENDLOOP.
ENDSELECT.

Move the processing to a background job (SM36). Background work processes have a higher memory ceiling and are not subject to dialog timeout limits. For very large datasets, also consider splitting by key range (by BUKRS, date range, etc.) across multiple jobs.

" Instead of selecting everything and then filtering:
SELECT * FROM bkpf INTO TABLE @DATA(lt_all)
  WHERE bukrs = @lv_bukrs.
DELETE lt_all WHERE waers <> 'EUR'.   " still allocated all rows

" Select only what you need:
SELECT * FROM bkpf INTO TABLE @DATA(lt_eur)
  WHERE bukrs = @lv_bukrs
    AND waers = 'EUR'.

This dump usually cannot be caught

TSV_TNEW_PAGE_ALLOC_FAILED is a kernel-level abort — by the time it fires, the runtime has already exhausted its allocation attempts. Class-based exception handlers (TRY ... CATCH) do not intercept it. The only real fix is to reduce memory consumption.

Prevention

• Never write SELECT * FROM <large_table> INTO TABLE without a WHERE clause and UP TO N ROWS for interactive programs.
• Use PACKAGE SIZE cursors or background jobs for bulk processing.
• Monitor memory usage with transaction SM50 (active work processes) and ST05 (SQL trace + row counts).
• Add UP TO 1 ROWS as a safeguard on queries where you only need to check existence.
• Regularly profile large programs with SAT (ABAP runtime analysis) to catch unbounded table growth early.

See also

• TIME_OUT — related dump when processing takes too long
• Transaction SM36 — schedule background jobs
• Transaction SM50 — work process monitor (memory column)
• Transaction ST05 — SQL trace with row count
• Transaction SAT — ABAP runtime analysis

Comments