SAP Dumps

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 aresy-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.

SYSTEM_FAILURE: "Screen displayed without connection to user".

In a remote function call, one of the following messages is displayed for the RFC exception SYSTEM_FAILURE:
"CPIC server sent screen &P1 &P2 (termination)"
(&P1 = program name, &P2 = screen number)
As of Release 3.0F:
"Screen display without connection to user."

ABAP runtime error 

• On the RFC client: CALL_FUNCTION_REMOTE_ERROR
  ,,Long text : ,,"CPIC server sending screen ... (termination)"

On the RFC server: DYNPRO_SEND_IN_BACKGROUND
,,Long text: ,,"Screen display without connection to user."

Cause and conditions

The system tried to display a screen or list using an RFC connection.
This error can occur in the following circumstances:

RFC communication between two ABAP systems or within an ABAP system. The following errors can occur:

If you run the calling program in a background process and the server program tries to output screens or lists, the communication is always broken, regardless of the user type. Make sure that the RFC server program always runs in a dialog process.

If you run the calling program in a dialog process, the action leads to the communication being terminated because the user has insufficient authorization. The user in the RFC connection is not of the type DIALOG. Check the user profile (transaction SU01 or Tools -→ Administration, Users -→ User maintenance -→ User, background, or BDC, the function module called will terminate as soon as it tries to display a screen or list. This occurs if the target system is an ABAP system with a kernel of Release 3.0E or lower (you can check this with the 'Release info' function in transaction SM51.

If the RFC communication is between an ABAP system and an external program such as a C or Visual Basic program, the communication is always broken when a screen is output, regardless of the user type. The exception to this is if the external program has a SAP GUI (RFC with SAP GUI). For further information, consult the system log (transaction SM21) or the error message 'Screen output without connection to user'. You can also refer to the dump analysis (transaction ST22).

Solution

In the case of RFC communication between two ABAP systems or within an SAP system, you can solve the problem as follows:

If you run the calling program in a background job, you must modify the function modules called so that they do not display any screens or lists.

If you run the calling program in a dialog process, use an RFC user with user type 'Dialog'.

If the RFC communication is between an ABAP system and an external program that does not have RFC with SAP GUI, you must change the function modules called so that they do not display any screens or lists.

Ref- 

http://scn.sap.com/docs/DOC-48962

http://scn.sap.com/docs/DOC-48962.pdf
http://help.sap.com/abapdocu_70/en/ABENRFC_SYS_FAIL.htm

*SCN