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."
"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."
,,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:
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.
http://scn.sap.com/docs/DOC-48962.pdf
http://help.sap.com/abapdocu_70/en/ABENRFC_SYS_FAIL.htm
*SCN
