Informações do post conforme link abaixo
https://blogs.sap.com/2020/04/21/adt-abap-debugger-what-to-do-if-your-program-does-not-stop-at-breakpoints/#UnusualBreakpoint
Details Section
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…”.
