Debugging: Lost/Missing debugging functionality

Question

Question

Anna Golitsyna · Jan 19, 2021

I have multiple projects that I utilize when debugging in Cache Studio. One of my projects suddenly lost the ability to step through commands with the yellow box and the cursor moving though code lines. The cursor just sits at the entry line while variables apparently do change. Interestingly enough, if I change the project and the debug target, the "yellow box" ability is still there. Apparently losing this functionality is by project/debug target/whatever. The goal is, of course to return it back but how?
P.S. Maybe it is some odd Cache Studio registry corruption or some Cache system global corruption? Just a guess. I did see this problem before a long time ago.

Product version: Caché 2017.1

Discussion (24)2

Log in or sign up to continue

Anna Golitsyna · Feb 9, 2021

Alright, this particular saga suddenly came to the end revealing the bug, my own one. But it is sort of educational so some details. I am implementing source control like features on and off while inheriting one of the features from a previous programmer. The latter feature which I preserved was about adding a timestamp with the compilation time to the changed routine in the overwritten source control method, OnAfterCompile. OnAfterCompile was adding this timestamp, resaving the routine directly in one of the internal routine globals, and it did NOT recompile the file again. That effectively still had the file internally marked as saved and compiled, no little cross in the Studio's routine tab, BUT that threw the .OBJ file mapping to the routine source code enough so the debug yellow box would refuse to appear and the cursor would not move from the first line. Many self eye-rolling emojis here...

How did I discover it? I need to modify this custom source control class and it was annoying to do so while the source control was on so I turned it off, moved functionality to my test routine, and observed with incredulity the long lost yellow debug box again....

P.S. On the plus side, I learned a lot about inner Cache workings due to this largely self-inflicted wound and I am happy it is over.

0 0

Anna Golitsyna · Feb 9, 2021

Losing debugging capabilities, Scenario #2.
A fellow programmer also lost her debugging capabilities some time ago though for different reasons and with different symptoms. I am not dead sure what happened in her case but it looks like some unfortunate combination of User Roles and Service Settings as defined in Management Portal. We discussed it today and she tried a few things. Changing the studio login user helped as well as changing localhost in Cache Server Manager to an actual IP address. Using Remote System Access from the cube was beneficial as well.

0 0

Anna Golitsyna · Apr 1, 2021

One late addition: I just lost this debugging functionality again, looks like because my code was going into a different namespace via zn "nsp". If I put the first breakpoint AFTER this zn, the cursor does not go to it and the yellow box does not appear. However, if I put my first breakpoint AT zn, the yellow box appears at it and stays with me after the breakpoint as well. Can't say it's a feature but then what??

0 0

score 0 · Answer 1 · 2021-01-19T15:00:00-05:00

First guess, just lost int code, during some compile forgot about k flag. If you debugging classes or mac routines you need int code to be able to debug it. I would also suggest trying VSCode, where the behavior can be a bit different.

score 0 · Answer 2 · 2021-01-19T15:02:06-05:00

Anna Golitsyna · Jan 19, 2021

It was non-generated INT code in the first place. I did try VSCode before but so far prefer Cache Studio.

0 0

score 0 · Answer 3 · 2021-01-19T15:07:37-05:00

So, you tried to debug INT code, and it did not work properly? Is it reproducible, and what will happen if you recompile it? And, still interesting how it will be in VSCode at the same time.

Just curious, did you miss anything in VSCode, or you faced some issues there, so, you decided to stay with Studio? You may answer me in direct messages, to keep this topic clear.

score 0 · Answer 4 · 2021-01-19T15:10:17-05:00

I was debugging INT code successfully when it suddenly stopped working as described in the OP. Since then it is reproducible for this specific project and recompiling does not help.

score 0 · Answer 5 · 2021-01-19T15:14:27-05:00

Dmitry Maslennikov · Jan 19, 2021

So, makes sense to test it with VSCode.

0 0

score 0 · Answer 6 · 2021-01-20T13:54:50-05:00

That means setting up, testing, and learning VScode plugin too which takes considerable time, I tried it before.

score 0 · Answer 7 · 2021-01-19T15:06:09-05:00

Anna Golitsyna · Jan 19, 2021

Compilation started on 01/19/2021 15:05:17 with qualifiers 'cuk /checkuptodate=expandedonly'

0 0

score 0 · Answer 8 · 2021-01-19T15:53:46-05:00

I've seen such behavior during debugging when I fell into some deployed system code (.obj only)
A similar effect happened to me when I touched some customized command, function, variable from ZLANG***
[which I tried to debug !!!]

I could gain control again by some <SHIFT><F11> until returning to some code covered by .int
As Studio stores a lot of info in the Windows registry just killing Studion might cause some confusion.

score 0 · Answer 9 · 2021-01-19T16:16:28-05:00

I am not sure I am falling into the .obj code with this problem but maybe I do. Just to be clear what is happening and what is not, a couple of screenshots.
1) TestAG^TestAG is the debug target, hand-written routine, and I pressed Go once, so presumably the debugger now sits at this breakpoint. However, no yellow box and the cursor is one line up. Shift+F11 does not make the cursor or the yellow box to appear anywhere else (I have other breakpoints too).

2) This is normal behavior. last is the debug target and the cursor correctly stops at the programmatic breakpoint with a suitable yellow box.

So any advice how to fix it?

score 0 · Answer 10 · 2021-01-19T18:20:00-05:00

Ahh!
Studio debugger is based on ZBREAK command.
old style BREAK is only useful for interactive debugging in the terminal and ignored in background
I always tried not to mix it up. Not sure if this is the reason. I think it's suspicious.

score 0 · Answer 11 · 2021-01-20T13:48:56-05:00

VSCode/Atelier debugger for instance stops execution when faces break in the running code as well as any error. And should show the place where it stops.

score 0 · Answer 12 · 2021-01-20T10:46:16-05:00

Robert, a bit more info after I tested a bit more:

1) The first program above, TestAG exhibited the same corrupt debugging behavior when I set it up as debug target for another project however this another project started debugging alright when I switched to a yet another debug target:

2) Test in this comment above leads me to think that the corrupt debug behavior might be associated with a program more than with a project. I don't think it is associated with the old style b break since it behaves correctly, the same as before.

score 0 · Answer 13 · 2021-01-20T16:53:21-05:00

Martin Fukátko · Jan 20, 2021

I'll work around it by switching the studio to INT code tracing.

Keyboard shortcut CTRL + Shift + v

0 0

score 0 · Answer 14 · 2021-01-20T17:01:24-05:00

I did not find anything obvious how to do that. Could you explain it in more details or post a documentation link?

score 0 · Answer 15 · 2021-01-21T04:29:27-05:00

When I have no "yellow box" during debugging MAC or CLS code in Cache studio I switch studio to INT code by CTRL + Shift + V

Or by mouse click View / View Other Code

Then press F11 and "yellow box" is here.

score 0 · Answer 16 · 2021-01-21T09:38:05-05:00

I'll remember your advice for mac or cls but my problem is with int routines. If I press View Other Code for them I see "There is no other code to view" and the yellow box still does not appear.

score 0 · Answer 17 · 2021-01-21T09:50:24-05:00

Robert Cemper · Jan 21, 2021

That's correct if you are already in an .int routine.
OTHER relates to cls, mac, .....

0 0

score 0 · Answer 18 · 2021-01-21T10:04:00-05:00

just tried to reproduce a similar case in Terminal.
#0) clear all stored breakpoints (menu: Debug / View breakpoints / remove all)
#1) set the breakpoint in Studio using F9
#2) attach to process (shell if in Terminal)
#3) do ^yourroutine in terminal
#4) In Studio: <ctrl>+<F5> let it run
if your breakpoint is reached you see the yellow box

Hint: try it with some simple 5 line routine first

If you never see the yellow box then you just don't execute this line

score 0 · Answer 19 · 2021-01-21T11:05:14-05:00

That's exactly the problem: the new breakpoint is reached but no yellow box and the cursor stays at the routine's first line. The code is executed though because the variable set right before this single breakpoint gets defined correctly as per Watch. I did follow your instructions except I still used the corrupt routine.

I doubt I can reproduce this corruption intentionally because that requires understanding why it got corrupted in the first place and that is still a mystery to me.

score 0 · Answer 20 · 2021-01-21T11:10:00-05:00

Right. It stands at the first line and <ctrl>+<F5> in Studio starts it

It is also in Debug menu / Go

I think that the design idea was to have a last chance to set breakpoints.

score 0 · Answer 21 · 2021-01-21T11:13:53-05:00

After it got corrupt it stands at the first line for the duration of debugging. I doubt this was the design idea