Skip to Content
Technical Articles

ADT ABAP Debugger – What to do if your program does not stop at breakpoints

If your program does not stop at breakpoints then follow the below list step by step.

Scope: This blog is about the ABAP Development Tools in Eclipse (ADT), not about the SAP GUI Debugger. Nevertheless, many of the following hints are also useful for the SAP GUI Debugger as well.

Check List

1) Check whether your breakpoint looks normal like this one . If yes, that’s good and you can directly continue with the next step of this check list.

If your breakpoint looks unusual like these  then follow the link to the corresponding detail section of this blog.

2) Check whether a notification appears on the lower right corner of your screen when you try to debug.

If yes, see the corresponding detail section.

3) Right click on the breakpoint and select “Refresh Breakpoint Activation”. Close the program / transaction / app that you want to debug and completely restart it.

4) Verify that the program flow actually reaches the code line where you placed the breakpoint. Don’t skip this step. It’s a bit of effort, but it’s also the root cause for more than 50% of all debugger-not-stopping situations. Being convinced that the program reaches a certain code line while it actually doesn’t can also happen to very experienced developers. In case you are not sure how to verify, see the detail section.

5) Trying to debug the request of a foreign user? Are you sure the breakpoint is created for the user that is used to run the program/request? More on this in the detail section.

6) Trying to debug a background job? If yes, see the detail section.

7) Trying to debug an update module? Is your code containing ‘call function … in update task’? If yes, see the detail section.

8) Trying to debug the request of a Fiori app? Start the app, press Ctrl-Alt-Shift-P and check whether your used UI5 version is at least

1.38.24
1.44.16
1.46.10
1.48.3

If your patch version (the 3rd number) is lower than the ones listed above, go to the detail section. If your version is equal or higher, that’s good and you can continue.

9) Skip this step if you use SAP Cloud Platform – ABAP Environment. Otherwise open transaction RZ11 and lookup the value of parameter rfc/ext_debugging, it should be 3. If the value is not 3, contact your administrator and ask him to change the value. More details on the possible values and their impacts can be found in note 668256.

10) Trying to debug across different clients (mandt)? Debugging cross-client is not possible and never was. You need to create the breakpoint in the same client where you execute the debuggee (= the program to be debugged).

11) System debugging? Trying to debug low level functionality of SAP basis? If yes, see the detail section.

12) Are you in one of the below listed scenarios?

– Parallel use of multiple ADT projects with the same combination of system, client and user
– Parallel use of ADT Debugger and SAP GUI Debugger with the same combination of system, client and user. Only external breakpoints of the SAP GUI are relevant, non-external breakpoints do not matter.
– Using same user & password together with other people (e.g. technical users or group users, like user ‘DDIC’)

If yes, see this blog.

13) Skip this step if you use SAP Cloud Platform – ABAP Environment. If you are not sure whether sufficient debug authorizations have been provided to your user then double check. E.g. via transaction SU53 or ask the administrator to check.

14) Do you use tools that deal with ABAP breakpoints, besides ADT & standard ABAP workbench? E.g. ABAP in Visual Studio Code, transaction ANST, transaction SRDEBUG. If yes, please try to not create breakpoints / perform debug activities via those tools for a while and see whether it solves the issue.

15) Debugging across different ABAP servers within the same system is possible since many years and there are no known problems. There is no need to use transaction SRDEBUG at all, if your system is based on SAP_BASIS 7.02 or higher. I’ve put this on the list only for completeness, since many people still think cross-server debugging is a potential error source. Actually it is not. However, if you really want to, you can try to set the breakpoint on the same application server where the program to be debugged runs.

16) Did you verify that the code line with the breakpoint is actually reached as explained in 4)? If no, please go back to 4) and repeat that step.

Update ADT, SAP_BASIS & ABAP Kernel

From time to time there are bugs in the ABAP debugger, just like in any other software. Updating to the newest available versions is always recommended and can potentially fix the debugger-not-stopping situations.

Create a Ticket

A) If you checked the above and the ABAP debugger still does not work as expected: Feel free to create a customer incident for BC-DWB-AIE-TST (ADT Debugger & AMDP Debugger) or BC-DWB-TOO-DBG (SAP GUI Debugger).

A few hints that potentially speed up ticket processing of ADT incidents can be found in the detail section.

Work Arounds

B) If code changes are possible you can try to use the ABAP statement ‘break-point’ instead of a normal line breakpoint (e.g. if sy-uname = ‘my_user’. break-point. endif.).

C) If code changes are possible you might want to try the work around via endless loop & SM50 attach. More details on this in the detail section.

About ABAP Debugging

Debugging ABAP with ADT is easy. In more than 99% of cases you just create a breakpoint, start your program and everything works as expected. There is also no differentiation between external or non-external breakpoints in ADT anymore. I would like to highlight this, because when looking at the above list you could potentially assume ABAP debugging with ADT is complicated, while it’s actually not.

Details Section

1) Unusual looking breakpoint

a) Your breakpoint is decorated with a gray diamond. That means the source where you placed the breakpoint is currently inactive. Activate the source to make the breakpoint work.

b) Your breakpoint is crossed out. That means you activated the Eclipse feature ‘Skip All Breakpoints’ that can be used to make ALL breakpoints non-functional. Deactivate the ‘Skip All Breakpoints’ feature via main menu ‘Run’ -> ‘Skip All Breakpoints’. Alternatively use the buttons in the Eclipse main toolbar or in the breakpoints view toolbar.

c) Your breakpoint is white. That means the breakpoint was disabled. To enable it keep shift pressed and double click the breakpoint. Alternatively open the context menu on the breakpoint and choose ‘Enable Breakpoint’.

If you are told this cannot be done because ‘… debugging is disabled …’ click the link on the popup and activate the checkbox ‘Enable debugger’.

d) Your breakpoint is green. That means you currently deal with a special kind of breakpoint which can be a soft breakpoint, a temporary breakpoint or an AMDP breakpoint. To identify what it actually is you can mouse hover over the breakpoint and check the hover text or you can open the breakpoints view and check the text there.

– Soft breakpoints are only effective in a running debug session but they cannot launch a new debug session on their own. This is a special feature for debugging situations with massive amounts of requests, e.g. catch one request with a normal breakpoint, disable that normal breakpoint and continue working with soft breakpoints. To remove the attribute ‘Soft’ from your breakpoint keep ALT pressed and double click it or change it via the breakpoints view.

– Temporary breakpoints occur in temporary editors, e.g. if you stepped into a foreign system via RFC or if you debug classic dynpros/screens with ADT. They are only effective in a running debug session but they cannot launch a new debug session. If you need a standard breakpoint that is able to startup a new debug session try a different/earlier source position.

– AMDP breakpoints are not ABAP breakpoints at all. Learn more about AMDP Debugging in this blog. A similar blog ‘What to do if your DB procedure does not stop at AMDP breakpoints’ is planned. It will be linked here once available.

e) Your breakpoint is decorated with a red cross. That means that there is a conflict with someone else who wants to debug the same requests as you do. Learn more about debugging conflicts in this blog.

f) Your breakpoint is decorated with a gray cross. That means the ABAP system is not reachable at all. Check whether your computer has a working network connection and whether the ABAP system is reachable at all (e.g. via SAP GUI).

g) Your breakpoint is decorated with a small U (User). That means you currently try to debug the requests of a different user. See this detail section.

h) Your breakpoint is decorated with a small T (Terminal-ID). Unless you have a good reason you should not use this option at all. To go back to normal mode, right click a breakpoint, choose “Debug Properties…” and change the radio button to “Logon User”.

i) Your breakpoint is decorated with a small P (Project). That means you can only debug requests that are started from exactly the ADT project you are currently working in. That includes execution of ABAP unit tests, activities in embedded SAP GUI or class runs (Right click -> “Run As” -> “ABAP Application Console”). In this mode, you cannot debug requests from other ADT projects, from a web browser (e.g. Fiori Apps) or RFC requests.

If you are not sure what this project mode is good for or how you even entered it you can read this blog. To go back to normal mode, right click a breakpoint, choose “Debug Properties…” and change the radio button to “Logon User”.

j) Your breakpoint is decorated with a small C (Conditional). That means you added a condition to the breakpoint (e.g. “sy-subrc = 4”). The condition is evaluated during runtime once the breakpoint is reached. If the result is false, the debugger will not stop the program and there will be no debug session. For further details see the ADT documentation.

To make the breakpoint always stop, just remove the condition via the breakpoints view or via right click on the breakpoint and “Breakpoint Properties…”.

2) Notification appears

If the notification contains a link “(Further Information)” then click on that link and check the details directly in ADT.

If the notification mentions the term non-exclusive see also the following ADT documentation.

If none of the above is helpful and the text on the notification is not understandable, then feel free to create a customer incident as described in the above section “Create a Ticket”. Please add a screenshot of the notification or quote the text.

4) Verify the breakpoint is actually reached

To ensure the code line with the breakpoint is actually reached during program execution you can use one of the following approaches:

a) Use a dynamic logpoint: Right click on the breakpoint, choose “Create logpoint…”, press finish, re-execute the program that you want to debug, open the logpoints view and choose “Collect Logs from All Servers” (refresh icon), check the second column “Log Events” for your logpoint: If the counter is 0 then the code was NOT executed. More information about dynamic logpoints can be found in this blog.

b) Create another breakpoint at a very early entry point and check whether that one works. If it does, step down into the code that you want to debug to see whether it is actually reached.

c) Disclaimer: This option is on your own risk. Only do this if you are completely aware of what an ABAP dump is and what consequences it might involve.

To be absolutely sure whether a certain piece of code is reached or not, you can provoke an ABAP dump, e.g. by adding the following code:
if sy-uname = ‘your_name’.
assert 1 = 2.
endif.

Execute your program and trigger the dump. Check ST22 or the ADT dump feed (view “Feed Reader”) for the ultimate proof on whether your code line was reached or not.

d) Use the ABAP Profiler or other tracing functionality to double check what code sections were actually reached

5) User mismatch

The program / request you want to debug is processed under a certain user and this user must be identical to the user in your debug settings.

To check your debug settings right click on a breakpoint and choose “Debug Properties…”. It shows for which user you are currently debugging.

To see under which user the program to be debugged is processed, there are different options:

a) [Requires authorization for using dynamic logpoints] Right click on your breakpoint and choose “Create Logpoint…”. Add “sy-uname” to field “Variable(s)”. Press finish and re-execute your program / request one more time. Check the results of the logpoint in the ADT view “Logpoints”. For more details on dynamic logpoints see this blog.

b) [Requires authorization to change code] Change your code in a way that it writes sy-uname into a custom DB table, into a static logpoint or any other place where you can look it up afterwards.

c) Use tracing / monitoring tools to identify the user name. E.g. the ADT Profiler (ADT view “ABAP Trace Requests”, keep the user field empty), transaction STATS, the ABAP Call Monitor, etc.

Also consider that RFC-calls in your program may include implicit user switches. Consider that processing of OData requests may contain RFC calls. E.g. if you have a system setup with frontend-server & backend-server, meaning UI5 sends HTTPS requests to the frontend-server and the frontend-server forwards them via RFC to the backend-server. If in doubt, check the configuration of your OData service.

6) Background Job

It is planned (Disclaimer: No official statement, do not rely on this) that the upcoming ABAP platform release (SAP_BASIS 7.55) will support debugging of background jobs. I will link the corresponding documentation here, once available.

For releases older than 7.55 there is no support for debugging of background jobs. Work arounds are described in note 573128.

7) Update Debugging

In order to debug update tasks you need a breakpoint and additionally need to activate update debugging. Different to SAP GUI, in ADT you can do that only in a running debug session. That means you need a breakpoint before the relevant commit-statement, in order to start up a regular debug session.

Once you have a running debug session, select “ABAP Debugger Actions” from the eclipse main toolbar.

8) Old UI5 Version

Unfortunately, the UI5 versions below 1.38.24, 1.44.16, 1.46.10 and 1.48.3 contain an issue that makes UI5 requests undebuggable. The only possible work around is described here. The proper solution is to upgrade the UI5 version. Note 2468634 explains that upgrade, when starting from 1.48.1. In case that is not the UI5 version you are starting from, try to find a similar note / instruction on how to update or contact the component named in the above note.

11) System Debugging

Source code which is flagged as system code can only be debugged if you have system-debugging activated.

In order to debug such code, simply create a breakpoint at the position you want to debug. If you do this while having system-debugging currently deactivated, a popup will appear that asks you whether you want to activate system debugging now. Just click yes. You can undo that decision via the Eclipse menu “Window” -> “Preferences” -> “ABAP Development” -> “Debug” -> “Enable debugging of system programs”.

A) ADT Ticket Hints

In order to speed up processing of ADT tickets, consider the following:

– Select from the Eclipse main menu “Help” -> “Collect Support Information…” and attach the resulting zip file to the incident. It contains the error log and support information like version numbers of your Eclipse, ADT and OS. This can speed up support.

– In order to reproduce an ADT issue from SAP side, we mostly need an NI connection. A standard SAP GUI support connection is helpful, but not sufficient to reproduce ADT issues. Note 1718597 describes how to open an NI connection. If you assume that a SAP supporter needs to connect to your backend system with his ADT, you can already open the NI connection together with the incident in order to speed up support.

– For HANA Studio users: HANA Studio on the one hand and ABAP Development Tools in Eclipse (ADT) on the other hand, are two different products. Since both are implemented as Eclipse plugins, it’s possible to run them side by side in a single Eclipse installation. However, if you face issues that are clearly related to ABAP (e.g. issues with ABAP debugging), then you should be aware it’s an ADT issue and not a HANA Studio issue, even though the program you execute on your PC may be namend HANA Studio. Keep this in mind when writing the ticket, because it reduces the risk that the ticket is routed towards HANA Studio teams instead of ADT teams. Of course SAP first level support knows the above, but it’s better if the ticket author is also aware.

– Every information that helps us to narrow down the root cause is very welcome and could potentially speed up the processing of your ticket. For example: Is debugging working with SAP GUI but not with ADT or other way around? Is the issue occurring only for your user or also for other users? Is it occurring only in a certain ABAP system or in multiple? Is it limited to a certain scenario? E.g. debugging of unit tests fails while debugging of reports works. Is it reliably reproducible or only rarely occurring?

C) Endless loop work around

Prerequisites of this work around:
– Code changes are possible
– You have authorizations to change variable values in the ABAP debugger
– You can attach the debugger to a running ABAP process via transaction SM50

Procedure:

Add an endless loop to the source position where you want to stop, e.g.

if sy-uname = ‘my_user’.
data(continue_loop) = abap_true.
while continue_loop = abap_true.
endwhile.
endif.

Execute your program/request and find its representation in SM50 (embedded GUI, e.g. via Alt-F8 -> SM50). Select the work process and choose menu ‘Administration’ -> ‘Program’ -> ‘Debugging’. Once the debugger started up, change the variable value of continue_loop to space and leave the endless loop via F6.

Please ensure to not transport any endless loop into your productive system.

15 Comments
You must be Logged on to comment or reply to a post.
  • Excellent stuff.

    For debug loop, I don’t change the variable value – I just use the “Go to line” option in the debugger. It still needs change authorisation though.

  • Hey Armin,

    I went through the list and at 12) I thought: yeah, that could be me (lots of projects in AdT, though mostly only one or 2 are open…). So I also read that blog. But it doesn’t fit my situation:

    When I call a transaction (e.g. VA01) from the Eclipse-embedded SapGui, the Eclipse-Debugger will open. OK.

    However, when I call the same transaction from SapGui in Business-Client (BC), the breakpoint is just ignored.
    Is there any way I could make this work? ( “no” is an valid answer!)

    Why do I want this?

    Eclipse/AdT is my coding-environment,

    BC is my execute transactions environment (e.g. test what I coded) with it’s own useful features (e.g. tabs, type-ahead-suggestion for transactions…) that I would not want to miss.

    -> I don’t want to have to mix those two.

    Do you(or others!) see any chance for having Eclipse-debugger open, when a Transaction in BC is called? -> I would like to give the AdT-Debugger a chance by trying it out!

    Best
    Joachim

    • Hi Joachim,

      there is no good solution for your case but you can try the following: Create the breakpoint in ADT, switch to SAP GUI / BC and enter the following ok-code before starting your transaction:

      /hext user = <username_that_created_the_breakpoint>

      You have to enter the username of the breakpoint owner because this ok-code also covers the following use case:
      – User A creates an external breakpoint for user B
      – User B enters the ok code /hext user = A in his GUI window, to confirm that he (B) allows user A to debug his GUI window / transaction

      Best regards,
      Armin

      Edit: By the way, a lot of projects are no problem. The debugging conflict occurs only if you use 2+ ADT projects for the same system, client and user combination at the same time. E.g. having one project with logon language English and one identical project with logon language German and working in both projects at the same time.

  • Hi Armin, I sometimes found as only possible solution for debugging HTTP code to activate the system debug via the transaction code SICF, even though the external breakpoint is not in a system-flagged program. I don’t remember the exact context. Do you have any information about the use case of system debug via SICF?

    Sandra

    NB: thanks a lot, this guide will be very useful to many people and to me !

    • Hi Sandra,

      did you try to debug custom code or SAP code?

      In new releases it may happen that system code makes the runtime decision: “I am system code and everything that is called by me is also system code”. That means under certain conditions some code which is not flagged as system at design time can become system at runtime.

      But this should never happen to any custom code or any custom ICF service. This should only happen to code of SAP_BASIS or other very low level SAP code.

      Regarding the use case question: I have no significant expertise for the SICF debugging feature, but it basically seems to be a shortcut for setting external breakpoints without having to search for the relevant code position manually. There should be no major difference of SICF compared to setting breakpoints manually. I assume the checkbox “system debugging” is simply for those people who actually want to debug system code.

      Best regards,
      Armin

      PS: Sometimes we get the feedback that the ADT debugger stops working after ADT was idle for a longer time, e.g. after lunch or when returning to ADT after 2-3 meetings in a row. I remember that you also gave a similar feedback recently.

      Now in fact the ADT debugger has a kind of “sleep mode” in order to reduce resource consumption on the backend, if ADT completely idles for a long time (1h or 2h). Whenever I tested that sleep mode or checked the relevant ADT code, it proved itself to be extremely solid. That means any tiny activity of the ADT user wakes the debugger immediately.

      On the other hand the symptoms fit so well and the advantage of the sleep mode (reduction of the backend resource consumption) is so little that I finally deleted that whole sleep mode. That means no more debugger sleep mode in future at all.

      This change is planned to be part of the next ADT version 3.10. It works for any backend version. Delivery of ADT 3.10 is planned for the upcoming weeks. If you still experience issues with ADT 3.10+ please feel free to create a ticket or a SCN question.

      • Not sure, but there is chance that it was some standard code. I’m just sure that the breakpoint was not in a system-flagged program, but probably it was in some standard BSP or Fiori.

        So, “I am system code and everything that is called by me is also system code” sounds like a very good explanation.

        It also justifies the role of the checkbox “system debug” in SICF and explains what I had observed.

        Next time it happens, I’ll be able to better analyze what’s going on.

        NB: I confirm that sometimes (rare) the debugger doesn’t stop anymore at the breakpoints, in my case it was just okay a few seconds before and then abruptly stopped working for unknown reasons. Maybe the sleep mode. 7.52 SP0 Kernel 753 SP300 / 7.52 SP1. Kernel 753 SP500. After restarting everything, and after some time (30 minutes/1 hour?), everything returns to normal situation. But maybe latest SPs solved some issues. It makes me crazy when it happens. I will install ADT 3.10 for sure 🙂

        Thanks a lot.

        • Your welcome.

          “…in my case it was just okay a few seconds before and then abruptly stopped working for unknown reasons” –  Ok, unfortunately this does not sound like sleep mode at all. Therefore ADT 3.10 will probably not fix it. Also that it needs so much time after restart to get back to normal sounds very unusual.

          Try number 3 of the above list if it happens again. Feel free to let me know if you have more details. E.g. a reproducible case or if you find out that it occurs more likely under certain conditions.

          • Several times when it happened I had tried “refresh breakpoint activation” but it didn’t do anything. Unfortunately it’s absolutely not reproducible, I can try all my best and it never happens again. “Sometimes shit happens” and impossible to know why… Maybe a neutrino or other superpower space particle hits the CPU memory…

  • For information, suddenly the debugger no more stopped at breakpoints, I could successfully solve the issue with option 3 (refresh breakpoint activation on a given breakpoint) BUT the previous attempts with the global option “refresh breakpoint activation” in the window of breakpoints (to do the refresh for all breakpoints) didn’t work. What is fun is that I couldn’t add a breakpoint anymore (double-click on line without effect /!\), and I had to use the global option “refresh breakpoint activation” in the window of breakpoints and then I could add a breakpoint.

    The issue happened again 5 minutes later (it happens rarely, but twice today, I don’t know why), this time it didn’t work immediately but two minutes later. I also switched off/on the “enable debugger” option of “debug properties”, maybe it had an impact to make it work.

    ABAP 7.52 SP01. ADT 3.2. It happened during tests with ABAP Unit, the breakpoints were both in productive and test code.

    • Thanks a lot for your input! In fact ADT 3.2 contains an issue that can cause situations like the one you describe. The problem is independent from backend versions and it was fixed with ADT 3.4. My recommendation is to update to the most current version 3.8.

      Meanwhile we also provide a latest ADT update site https://tools.hana.ondemand.com/latest, as described on https://tools.hana.ondemand.com/#abap

      Also the Eclipse platform is using it’s latest udpate site as default now, starting from Eclipse 2019-12. Therefore we recommend now to use eclipse latest + ADT latest update sites to always get all latest updates without need to manually change any update site configuration anymore.

      Whenever “Refresh Breakpoint Activation” solves the issue, the root cause is clearly a bug from SAP side. Therefore sorry for the inconvenience. The reason why I put “Refresh Breakpoint Activation” quite high on the list (as step 3) is not because it’s often the solution, but instead because it is so little effort to execute it. Same for step 1 and 2.