Did the latest ADT 3.2.4 break the Eclipse debugger?

[pokrakam]

Since updating ADT to 3.2.4 my eclipse debugger no longer works. Breakpoints set in Eclipse are ignored, and manual debugging via "/h" or BREAK statements launches a SAPGUI debugger window. Has anyone updated to 3.2.4 (released in the last day or two), and if so could you please confirm if the debugger still works for you or if I broke something by other means?

[ChristianGünter]

Confirmed. Same problem here.

[matt]

Thanks for the heads up - I'll hold off updating...

[Armin_Beil]

Hi Mike, Christian,

thanks for reporting and sorry for the inconvenience.

I just installed ADT 3.2.4 on Eclipse 2019-03 (Java Developers version), according to https://tools.hana.ondemand.com/#abap and the ADT debugger works fine for me, also with old backends.

Therefore I would need your help on this one. Or at least more input. It would be perfect if you could create a customer incident (BC-DWB-AIE-TST, ask in the ticket to forward it directly to me and link this thread).

In case ticket creation is not possible, you can also contact me via mail for this topic (address is the straightforward one, first.second). Maybe we could have a skype session.

Best regards,
Armin

Edit: Could you please additionally try the following: Right click where you usually create breakpoints and choose "Refresh Breakpoint Activation". Please let me know whether this helps or not.

[pokrakam]

Hi Armin,

Sorry, customer system where OSS is restricted and Eclipse is new fangled voodoo that I had to fight for special access to be able to use.

But something interesting: After doing the refresh, trying to set a breakpoint now gives an error "Cannot toggle breakpoint: System <SID> cannot be reached". Am a bit pressed for time, but will try do a trace a bit later and let you know if I find anything else of interest.

I also updated ADT on my MacBook with JavaGUI, and it still works fine.

Edit: One more thing: I'm running on Eclipse 2018-12, different to yours.

Thanks,

Mike

[Armin_Beil]

Thanks Mike, actually this message text is already helpful. I'll do some further tests, maybe I get it reproducible locally.

[pokrakam]

I just remembered I have a CAL instance with a Windows Eclipse. I was going to let you access that, but when I updated it to 2018-12 / 3.2.4 it works as expected.

But I hope my 'clue' is of use. Everything else works as normal.

[Armin_Beil]

According to the descriptions and the error message I currently assume a programming error in ADT, so the eclipse version is probably not relevant. During testing I had the issue with that same error message once, out of something like 20 or 30 attempts/tests, but I was not able to reproduce it. Can you reproduce the issue reliably or is it also occurring only sporadically on your side?

[pokrakam]

Hi Armin,

OK, it seems to be mostly resolved, although something weird did happen in the update process.

It ignored breakpoints 100% of the time since the update from 3.2.3 to 3.2.4. It still let me set and delete breakpoints too.

On your suggestion I refreshed breakpoint activation, but unfortunately my testing was incomplete: I only tried setting a breakpoint and stopped there due to the message above. I didn't try starting the debugger manually.

So I tried this now and it does work: the Eclipse debugger kicks in via "/h" or a BREAK statement.

The interesting thing is I couldn't set a breakpoint on just one system. Everything else functions on that system, other dev systems are fine, the corresponding Test system is also happy (i.e. same version/SP).

Finally I went with the old Windows adage, "when in doubt, reboot"... and now it all works. Odd.

But thanks for your help anyway, it was your suggestion that fixed it.

[Armin_Beil]

I see, thanks for the update! The available information shows that the debugger was in an inconsistent state, but unfortunately I don't know what causes the inconsistency, yet. I'll do further tests, including the 3.2.3 -> 3.2.4 update.

[Armin_Beil]

Hi Mike,

we identified a problematic flow in the ADT code that potentially causes debugger inconsistencies like the one you experienced. I cannot guarantee that this problematic flow was the root cause for your issue, since I have no reproducible case of your issue, but i think it probably was. Correction is planned for the next ADT release 3.4, which is planned to become available beginning of August (via update site probably on 01.08).

Additionally we added a built-in repair for that kind of inconsistency and improved the error message ("System <SID> cannot be reached" was nonsense in that situation).

Sorry for the inconvenience and thanks for reporting the issue.

Best regards,
Armin

[pokrakam]

Hi Armin,

Yes it did seem to me the message was probably inaccurate.

Thanks for the update,
Mike