ABAP ‘short dump' (German Kurzdump) is a misnomer. There is nothing ‘short' about an ABAP dump. Should the ABAP AS no longer be able to execute a program - because of an unhandled or unhandleable exception, a resource or system problem, or an error in coding - it may document the problem with 20 or more pages of diagnostic information.

Very often, a short dump contains not only the exact diagnosis of the problem that occurred but also the solution, or at least important pointers toward the solution of the problem. But experience has shown that developers often don't even read dumps - not even the highly useful Error analysis - much less make use of the diagnostic resources that short dumps offer.

The lack of attention to short dumps is understandable but regrettable.

Understandable  because the report that your program is dumping in a customer system is about the worst news you can get. It's time to drop everything and switch to emergency mode. 

Regrettable, because often developers who don't take a good look at the short dump waste a lot of time thrashing around in the debugger, trying to understand what went wrong. Taking a good look at the short dump is usually a better use of your time. And then there are the situations in which the dump is the only diagnostic resource that you have - when the dump occurred in a production system and is too sensitive to repeat, when the dump occurred several hours after the background job started, and so on.

In this pair of weblogs, we will take a quick tour through the ABAP short dump as of NetWeaver Release 7.0 EHP1, pointing out important analytic aids that it offers and how to make the best use of them.

In the first weblog, we will just get ready to analyze a dump. The weblog looks at the ABAP dump lists and how to get the most out of them, as well as at a couple of related sources of information.

Off to the Dump

If you aren't staring at a short dump on the screen in front of you, then the way to see any ABAP short dumps in your system is by starting transaction ST22.  As standard selections, ST22 lets you list dumps from yesterday and today, but also lets you select dumps by user, date and other parameters.

Adding Information to the List of Selected Runtime Errors

It is natural to want to hurry right to the display of a dump that you need to investigate. But hold on - have you ever noticed those three useful little options at the bottom of the ST22 start screen?  You might want to take a look at them before you rush off into a list of short dumps.

By default, the options are not set.  But:

• With information on Exception/Short Text of Runtime Error extracts the data provided by the exception object, if a class-based exception triggered the dump. 

The display of the exception object may show you useful information, such as the exception's error message. If the initial exception was caught by another exception, then you can see the chain of exceptions. 

 

• The program affected and Program and associated application components (long runtime) options add information to the List of Selected Runtime Errors. The name of the program in which the dump occurred is shown.  Just as importantly, the list displays the component (BC-CCM-MON, or FI-XXX-YYY or whatever) in which the dump occurred, if it can be found.

Sometimes the program and component may be misleading, if an application problem triggers a dump somewhere in infrastructure coding. But often, you can search for notes with the program and component. (The How to correct the error section in the dump long text shows a more extensive list of possible search terms.)

If you need to write an OSS message to SAP, you know the component in which to file the message.

If the component is not shown or you think that the component shown is misleading (the dump was finally triggered in infrastructure code), then you can find the component for an OSS message by following the path from the suspect program (for example, from the Active Calls/Events section) to the package of the program to the component.  In SE80, go from the attributes of the program to the package. In the package, the component is displayed.

Surveying the Scene of the Disaster

You've set those useful dump list options. Now you want to get on with looking at that dump. 

But once again - wait!  Especially if you are working on an ill-defined problem - you don't have a really good idea of what caused the dump - then it is wise to take a good look around the scene of the disaster before plunging into the details.  Otherwise, you may miss vital clues to external factors that contributed to or even caused your dump.

Start your survey with the dump lists that ST22 offers, which offer useful information to the keen-eyed investigator.

The List of Selected Runtime Errors

The main dump display is the List of Selected Runtime Errors. Just click on Today on the ST22 start screen to take a look at current short dumps.

The list of may look something like the screen shot below. (This is from a system that is dumping quite busily - a headache for the QMs.)

As you look at the list of dumps, ask yourself these questions:

• Is your dump a mass phenomenon? 
• When did the trouble with the dumps start?
• Does the dump occur on only one server?  Or for one user? Or for one program?
• What other dumps occurred around the same time as your dump?  Are there signs of system or database problems or problems in components which your program uses?

If your dump is a mass phenomenon, then you want to know this as quickly as possible  If there are patterns in the list of short dumps, then you want to find these, because they could signal that your dump is part of some larger problem with the system or one of its components.

The Dump Overview

As you look at the List of Runtime Errors above, you may have the feeling that you can't see the forest for the trees.  There are so many dumps. They are clustered by type, but none of the sets of dumps seem likely to share causal explanations or to fit the journalistic questions posed above.  What's going on?

In cases like this, the more orderly view of dump traffic offered by the Overview function may help.

Choose Goto -> Overview from the ST22 start screen. Skip over the following selection screen with Execute.  The system shows you what has been dumping in the system, sorted by dump category.   

The foci of dump activity make it clearer what is going on in the system. First,  the LOAD_PROGRAM_LOST short dumps tell us that we are in a development system, in which infrastructure source code (in this case) is being changed on the fly.

The UNCAUGHT_EXCEPTIONs and OBJECTS_OBJREF_NOT_ASSIGNED_NO may indicate that the developers have not cleanly implemented some programs as yet. Or perhaps some particular program or component is not working quite right.  The scattering of dump activity among unrelated programs is in this case also explained by the fact that the system is apparently a development system.  For a closer look, a double-click on one of the entries in the list selects the relevant short dumps for display.

The ABAP AS defines more than 1600 short dumps, all documented in loving detail by the kernel developers who are responsible for them.  Some of these - the ‘usual suspects' in the parlance of the film ‘Casablanca' - already indicate to the savvy investigator that something other than an ABAP error is at play in the system.   A list of the usual suspects might include these short dump IDs:

One More Detour

You've looked at the dump lists. Perhaps you have taken a look at your dump as well. And you still aren't sure what has gone wrong.  One more detour - to the System Log - often provides additional useful clues before you finally get to the dump. 

You need to know the application server on which the dump occurred, which you can get from the dump lists.  Start the SysLog (transaction SM21) on the application server on which the dump occurred. 

Find your dump in the system log. As a search term with CTRL-F, ‘short dump' is useful.  (Be aware that the system log writes on a circular file, so the report of your dump can be overwritten.  Save the file if it is useful to you by downloading it.)  Then look for events before - even well before - your dump and for significant events thereafter.  

The Developer Traces

If even the System Log has not helped you to understand the dump, then you may need to look even further afield for more clues as to what went wrong.  In this situation, the ABAP developer traces may help you to find the missing clues.

The developer trace is the log that each kernel component (work processes, message server, gateway, and so on) writes. Even in the standard setting, it offers a detailed trace of the activity of each kernel component, whereby in the case of an ABAP dump in most cases only the work process traces are useful.  A work process dev-trace is written by each individual work process in an ABAP instance. To access the dev-trace, you therefore need both the name of the instance and also the number of the work process in which the dump occurred.  Fortunately, the Selected List of Runtime Errors shows both items of information, in the Application Server and WP Index fields, respectively.

Armed with the instance name and work process number, you can start transation ST11 on the right server to see the dev-trace files.  The work process files have the names dev_w<n>, where <n> is the work process number that you found in field WP Index. There is a current dev-trace file, which was started when the instance was started, as well as a dev_w<n>.old file, which records the activity from the previous start of the application server.  If you do not find your dump in the current dev-trace, then you still have a chance to find it in the .old file.

Search for your dump under its dump ID (TSV_TNEW_PAGE_ALLOC_FAILED, for example). You can then scan for error messages in the trace before the appearance of your dump. The dump itself is surrounded by entries starting with the keyword RABAX, which belong to the dump processor itself, and so usually don't provide the hot clues for which you are searching.

Finding and Keeping the Older Dump

The dump you want is older than today?  The ABAP AS regularly reorganizes dumps. By default, all dumps are deleted at the latest after seven days. But don't give up.  Enter the start and end dates in which you are interested in Own selection on the ST22 start screen. Often, especially if the system has not been dumping much, dumps up to a week old are still accessible.

If you need to hold on to a dump, be sure to lock it in the list of short dumps. It won't be deleted during reorganization.

Post-Mortem Analysis in the  ABAP Debugger

If you can reproduce a dump without endangering the system (most importantly, you are not in a production system), then you don't need ST22.  The living, or at least still-warm short dump offers you some special advantages.

Most importantly, you can jump from the dump into the ABAP debugger. The program is of course no longer executable in the debugger. But the short dump has preserved the state of the program context at the moment the program aborted.

You can examine all of data objects that had been initialized. You can use debugger tools like the Memory Analyzer, the Call Stack, the Table and Object displays, and so on, to poke around in the ruins of the program context for clues to the source of the disaster.

- This weblog is based in part on Boris Gebhardt's Advanced ABAP Workshop: ABAP Analysis Tools. You can find more information on ABAP Test and Analysis Tools at help.sap.com and also in ABAP: Advanced Tools and Techniques, Volume 2, SAP Press 2009, ISBN 978-3-8362-1151-2.