Dumps happen when an ABAP program runs and something goes wrong that cannot be handled by the program. Dumps that happen in the customer namespace ranges (i.e. own-developed code), can usually be fixed by the programmer. Dumps that happen in SAP standard code probably need a fix from SAP.

The different sections (in no particular order) and how they help

Some of these sections contain useful information, others not. Depending on the exact failure, some sections may contain very little.

Short Text

Not much information to be found here, except a brief description of the nature of the cause of the dump.

What happened?

Slightly more information.

What can you do?

Sometimes there’s helpful hints here, most often it’s just standard information.

Error Analysis

Here is the technical explanation of what went wrong

How to correct the error

Hints are given for the keywords that may be used to search on the note system. Various combinations of keywords may be suggested. By using these to search the notes system (formerly known as OSS), you might find a note, or some notes, that fix the problem. For failures in standard SAP objects, this should always be your first port of call in resolving the error.

This section may give other hints on resolution, so read carefully.

System Environment

This information can be useful for determining the release level. However, for this information, I usually go to System->Status on the failing system. It tells you the SAP release and the Basis support pack level, as well as information about the operating system and hardware.

User and Transaction

Information about where the error occurred. The client, the use rid, the language, transaction. the program, screen and screen line number of the failure.

Information on where terminated

A little more information about where the program stopped – the function module, for example, the main program, and the exact place in the code that the failure happened.

Source Code Extract

Here you can see a portion of the code around the area where the failure happened. If no code can be seen, then usually that indicates an issue at the Basis level. If you click on the code, you are navigated to the editor.

Contents of system fields

The values of some of the most important system fields (i.e. the sy- variables) are displayed here. Of particular use are sy-msgno, sy-msgid and sy-msgv1 to sy-msgv4. You can take the values of these and check messages via transaction SE91. In this way you can sometimes find further information about the cause of the error. If you know the message id and message number, you can see what the error text would have been, and in SE91, find the long text of the message. The message id and number is also useful for searching for notes.

If you want to debug through to the point of failure, take a note of sy-msgno. Go to a new screen, and type /h to enter the debugger. Then start your transaction, and once you are in ABAP code, create a watchpoint on sy-msgno to stop the debugger at the place where it gets your noted value.

Other system fields may also contain useful information.

Active Calls/Events

Here you have the call stack – the list of programs / modules / function modules / methods and forms at the time of failure.

Chosen variables

A very helpful section. If a dump happens while you are running a transaction on-line, you have the option to enter the debugger, which allows you to check the values of variables. If the dump cannot be reproduced, or occurs only in background, or any other reason, then this section can give very useful hints. The values of variables from each level of the call stack appear here. The size of tables is shown, which can be useful for finding the cause of running out of memory. In later versions of SAP, you can even see the first few entries in tables.

Other sections

The remaining sections I have not found to be particularly useful for the ABAP developer, though they may be extremely interesting for SAP or Basis consultants. I shall not describe these sections.

Notes on different kinds of dump

As I come across new situations, I shall add to this document from time to time.

RAISE_EXCEPTION

A function module raise an exception that was not intercepted by a program higher up in the stack. If this occurs in a customer program, then the developer needs to handle the exception in the calling program. If it happens in a SAP program, then it may be an unexpected situation. It is often useful for this kind of failure to look at the values of sy-msgid and sy-msgno. You should also search for notes containing the message id and number, and/or important keywords from the “How to correct the error” section.

RFC_ATTACH_GUI_FAILED

This commonly happens when an RFC enabled function module is run, that then goes on to do something connected with screen handling. As it does not have a screen, it fails. It can also happen if SAPGui (or components of it, such a BEX) have a problem, or are incorrectly installed.

LOAD_PROGRAM_LOST

The program you were running was changed while you were running it. In a BI (and other similar environments) this happens quite often if you are in sections of the system that generate code – such as developing routines in transformations. There is not much to do but restart the transaction you were running. To avoid this in RSA1, if you are doing lots of complicated development, it is a good idea to restart the transaction from time to time.

DBIF_RSQL_SQL_ERROR

Indicates a problem occurred in the database. You may find more information in the system log via SM21. The exact nature of the failure is usually seen in the “How to correct the error” section. If this occurs in standard SAP code, then there may be a corrective note. It may be connected with database set up, so if the cause is not obvious (like a malformed dynamic SQL from one of your own programs), it may be worth talking to your basis team.

MESSAGE_TYPE_X

If this message comes up, it means the program met a situation that it just did not know what to do with. In the “Error Analysis” section you will see the short and long text of the error message. Sometimes the error indicates inconsistent data, sometimes as Rob Dielemans points out, it can be used deliberately during the development process.

If, during development you simply want to know if a certain piece of code gets executed at all (usually background stuff, like workflow ), you just code a type X message with some values such as sy-uname, or other variable you are interested in. This is a very good way to exactly find out the value of a parameter when differences can occur in debugging.

ASSIGN_TYPE_CONFLICT

Most likely a programming error. This message indicates that an ASSIGN is occurring that is going to an incorrectly typed field-symbol. Check the Source Code Extract to see exactly where the problem occurs, and carefully check that the typing of the object matches.

OBJECTS_OBJREF_NOT_ASSIGNED_NO

An attempt was made to access an object (the class type is given), that had not been instantiated. Most likely a programming error.

TSV_TNEW_PAGE_ALLOC_FAILED and MEMORY_NO_MORE_PAGING

This indicates that your process ran out of memory. This may be a programming issue – check the size of internal tables, and how much data you are selecting. Perhaps there is an eternal loop that just keeps adding to a table. It may be a hardware issue – that there simply isn’t enough memory available. This type of error can be hard to track down, as the place where memory is actually exhausted may vary. “What can you do” shows the amount of memory of the various kinds that were available. There may be information in the “Error analysis” section that shows exactly which internal table could no longer be stretched to contain more data.

UNCAUGHT_EXCEPTION

This is the object oriented equivalent of RAISE_EXCEPTION. It means that a class-based exception was raised in a method / function module / form that was not caught higher up. Usually this indicates a programming error. I’ve seen attempts to fix this, using CATCH cx_root, and then continuing processing. This is a very bad way of fixing the error, as it just ignores the cause of the exception. Ignoring an exception like this is like ignoring non-zero sy-subrc.

COMPUTE_INT_ZERODIVIDE

Exactly what it says – an attempt has been made to divide by zero. This is either a data or programming error. In fact, it’s always a programming error as any division should always check if the denominator is zero, and correct raise an error condition if it is.

RFC_NO_AUTHORITY

Simple one this. The user that tried to execute an RFC enabled function module, via RFC, was not authorised via authorisation object S_RFC to run the function module. The name of the function module is in the Short Text. The name of the user id is in the “What happened?” section.

TIME_OUT

There is a Basis setting that sets a limit for the run time of a transaction or report- typically fifteen minutes. If a dialogue process exceeds this limit, the kernel spots it and stops the program with a TIME_OUT dump. Common causes are:

  • User selecting too much data – like all companies, or all controlling areas.
  • A programming error resulting in a endless loop
  • Inefficient programming. For example, using STANDARD tables instead of HASHED or SORTED, loops within loops, selecting the same data again and again etc.

The common solution is to extended the allowed run time. However, this should be the very last resort, as it only fixes the symptom, not the root cause, and, as data volumes increase, you are likely to hit the new limit eventually. It is much better to fix the program. Where users select too much data, for example, the selection screen can be adjusted to prevent this. If a wide selection is needed, perhaps the program can be run in background – and if necessary, populate a database table that can be reported on.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

    1. Raymond Giuseppi

      Just some error types (from a local tracking tool)

      • CONNE_IMPORT_WRONG_COMP_LENG
      • CONVT_NO_NUMBER
      • DBIF_RSQL_INVALID_CURSOR
      • DYNP_TOO_MANY_RADIOBUTTONS_ON
      • DYNPRO_SEND_IN_BACKGROUND
      • GETWA_NOT_ASSIGNED
      • OBJECTS_OBJREF_NOT_ASSIGNED
      • RAISE_EXCEPTION
      • STRING_OFFSET_TOO_LARGE
      • SYSTEM_CANCELED
      • SYSTEM_ON_COMMIT_INTERRUPTED
      • TSV_LIN_ALLOC_FAILED
      • TYPELOAD_NEW_VERSION

      But actually every exception associated with every Abap statement and some kernel C function (be it catcheable or not) can raise a dump, so many many errors.

      (0) 
  1. Rob Dielemans

    Nice and concise information, you could add to the MESSAGE_TYPE_X dump that this is also used on purpose.

    If in development you simply want to know if a certain piece of code gets executed at all (usually background stuff, like workflow ), you just code an x message with some values like sy-uname. This is also a very good way to exactly find out the value of a parameter when differences can occur in debugging.

    Cheers!

    (0) 
  2. Caetano Almeida

    Hi Matthew

    Excellent document. I will bookmark and use it to answer threads in the future.

    One of the most frequent short dumps is SAPSQL_ARRAY_INSERT_DUPREC, which happens when system is trying to insert a records that already exists on database. The issue may be related to an incorrect number range or to a database inconsistency.

    I would also add dump MEMORY_NO_MORE_PAGING which happens when system runs out of paging memory and EXPORT_TOO_MUCH_DATA.

    BR
    Caetano

    (0) 
  3. Horst Keller


    SELECT DISTINCT errid

      FROM snapt

      INTO TABLE @DATA(dumps
     
    ORDER BY errid.

    cl_demo_output=>display( dumps ).

    Wanna document ’em all? 😉

    But seriously, for most ABAP statements the keyword documentation contains a list of runtime errors that might occur and also important, if they can be handled using an exception class. You can use the full text search capability of the ABAP Keyword Documentation to search for runtime errors there. OK, there are also errors coming from the environment that are not connected to specific statements.

    In fact, I think the class based exceptions connected to system exceptions are even more important for programmers, e.g. CX_SY_ZERODIVIDE for COMPUTE_INT_ZERODIVIDE because you can handle them (for consultants searching for errors it might be the other way round). A dump only occurrs if a system exception isn’t handled appropriately or cannot be handled at all. Normally, the documentation explains what you can do and what you can’t. And if you do unallowed things, e.g. inserting duplicates into tables with unique keys or running programs longer than allowed – well of course an error occurs and if you cannot handle the exception, you must prevent it with other means, e.g. by not inserting duplicates or restricting the amount of data to be processed in a dialog step.

    Cheers!

    Horst

    (0) 
    1. Matthew Billingham Post author

      I had a bit of an ulterior motive. I got irritated by the number of posts for dumps. By having a list of the most common, it gives me grounds for rejecting those posts with the comment “FAQ – Please search” – knowing that the information is there for those who search.

      (0) 

Leave a Reply