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 user id, 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 raised 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.
