Interpreting a short dump

[Taffy programmer]

I have inherited a program which is short dumping with TSV_TNEW_PAGE_ALLOC_FAILED in the production system. This is a memory problem, and the following text is on the short dump:

Error analysis
The internal table "???" could not be further extended. To enable
error handling, the table had to be delete before this log was written.
As a result, the table is displayed further down or, if you branch to
the ABAP Debugger, with 0 rows.

At the time of the termination, the following data was determined for
the relevant internal table:

Memory location: "Session memory"
Row width: 2362
Number of rows: 0
Allocated rows: 591424
Newly requested rows: 4 (in 147855 blocks)

The code looks like this:

Code: Select all

   94   CALL FUNCTION 'CHANGEDOCUMENT_READ_RANGES'
   95     EXPORTING
   96       date_of_change                = gv_prev_run_date
   97       objectclass_tab               = git_objectclass_tab
   98       time_of_change                = gv_prev_run_time
   99 *      username_tab                  = git_username_tab
  100       date_until                    = gv_date
  101       time_until                    = gv_time
  102 *   IMPORTING
  103 *     ET_CDRED_STR                  =
  104     TABLES
  105       editpos                       = git_chngdoc
  106    EXCEPTIONS
  107      no_position_found             = 1
  108      wrong_access_to_archive       = 2
  109      time_zone_conversion_error    = 3
  110      OTHERS                        = 4
  111             .
  112   IF sy-subrc EQ 0.
  113
  114 * Begin of Insert by 007 - A0001309 - ISDK901585 on 13.08.08
>>>>>     DELETE git_chngdoc WHERE username IN git_username_tab.
  116 * End of Insert by 007 - A0001309 - ISDK901585 on 13.08.08

I think this means that table git_chngdoc is massive, so is causing the memory problem. How do I work out if this is the case? Lower in the dump, in the 'Chosen variables' bit, is the following:

GIT_CHNGDOC
Table IT_29[591422x2362]
\PROGRAM=ZIDM_SAP_CAS_PROPERTY\DATA=GIT_CHNGDOC
Table reference: 18
TABH+ 0(20) = 907B4574FE070000A0D05F72FE0700000000000
TABH+ 20(20) = 120000001D0000003E0609003A090000FFFFFFF
TABH+ 40(16) = 04000000A007000004000000C9248001
store = 0x907B4574FE070000
ext1 = 0xA0D05F72FE070000
shmId = 0 (0x00000000)
id = 18 (0x12000000)
label = 29 (0x1D000000)
fill = 591422 (0x3E060900)
leng = 2362 (0x3A090000)
loop = -1 (0xFFFFFFFF)

Does the bit in bold mean that the table has 591422 entries, or is it something else entirely?

Ta

[wilhitern1]

You (the program) definitely blew up memory. I believe you are understanding it's statement correctly. I've never used that function before, but logically it must be building the itab and your date/time range is to large. (I think I remember) Someone once told me that on a 64 bit architecture that problem goes away. I'd imagine that means to be replaced be the other logical failure. Program never ends.