Call Stack view crashes Cache Studio

Question

Question

Arto Alatalo · Apr 12, 2017

Cache Studio almost always crashes when I click rows in Call Stack view during debugging. Then Cache has to be restarted because last edited file remains locked.

Looks like I'm the only one who uses the debugger. Or is there a magic spell to make stack view working?

Cache 2016.1.1

Discussion (6)0

Log in or sign up to continue

Timothy Leavitt · Apr 12, 2017

Some indirect answers that may be useful:

I don't tend to use the call stack view in the Studio debugger. For many cases where stack information is useful for debugging, I'll typically just add this to my code:

do LOG^%ETN

Then run it, and then look in the application error log (visible in Management Portal at System Operation > System Logs > Application ErrorLog, or via do ^%ER) to see what the stack/variables were when it was called.

Also, you should be able to clear out locks (perhaps cautiously) in the management portal from System Operation > Locks > Manage Locks.

0 0

Joel Solon · Apr 15, 2017

I haven't seen this crash at all. Is it possible to share more details about the crash? Error message, for example. Also, if the last edited routine is locked, that doesn't require a restart of Caché. You can find the entry for the routine in the Lock Table (in System Operations) and delete it.

0 0

score 1 · Answer 1 · 2017-04-12T10:45:17-04:00

John Murray · Apr 12, 2017

Perhaps everyone else is using Serenji instead

1 0

score 0 · Answer 2 · 2017-04-17T13:51:46-04:00

"I don't tend to use the call stack view"

I'm not able to comprehend that In my world stack view is as natural as.. as... as... I don't know, there is nothing more natural as working stack view in any debugger.

The trick with LOG^%ETN is for a case when you need the stack saved to a diagnostic log. But usual case for stack view is you have your debugger stopped on a breakpoint in some library routine and want to know what path brought you here. What you do? I look at stack view and click it to navigate to a call place.

score 0 · Answer 3 · 2017-04-17T13:28:58-04:00

The 'crash' is my post is actually incorrect. Studio never crashes, it always stops responding. So no error codes.

Now it took me about 15 minutes to reproduce the problem. I placed several breakpoints in my code and randomly clicked the stack every time debugger stopped, and at first everything worked OK. But then, without any evident reason, Studio stopped responding. Process info reports this:

Execution Details

Process State:

EVTW

In Transaction:

No

Last Global Reference:

%apiOLE("debug")

Routine:

%Debugger.System.1

Location:

Source Location:

+415^%Debugger.System.1

Source Line:

I refreshed the page several times, the info remains the same

score 0 · Answer 4 · 2017-04-17T13:50:57-04:00

"I don't tend to use the call stack view"

I'm not able to comprehend that In my world stack view is as natural as.. as... as... I don't know, there is nothing more natural as working stack view in any debugger.

The trick with LOG^%ETN is for a case when you need the stack saved to a diagnostic log. But usual case for stack view is you have your debugger stopped on a breakpoint in some library routine and want to know what path brought you here. What you do? I look at stack view and click it to navigate to a call place.