How to attach a studio debugger to a Zen class running on Ensemble server (via IIS)

Hi all - I'm running a Zen page that inherits from %Zen.Component.page, and I'd like to step through code and debug it.  Is this possible, and how?

 

I've tried to attach to a process that I think is mine (it has my internal IP address) but is using "Unknown User".  Any ideas on where to start debugging the page  -- this page calls lots of other pages.  I'd thought I'd start at the home page.  

 

Perhaps I need to navigate to my page that I want to debug, and attach at that point.

 

Any info on the debugger in this atypical use is appreciated.

Thank  you,

Laura

  • 0
  • 0
  • 418
  • 9
  • 1

Answers

In Studio, choose Debug > Debug Target... and enter the URL you want to debug, including CSP application - e,g,, /csp/samples/ZENDemo.MethodTest.cls. Put a breakpoint in the method you want to debug. Click Debug > Go. That should do it.

See: http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSTD_Debugger#GSTD_C180276

Hi Timothy,

I've tried many debug targets.  Using csp/NameHere/package.home.cls I get this error when I run it:

 

Caché Server Pages Version 2014.1.3.775.0

Error Condition


Error Condition

CSP application closed the connection before sending a complete response

 

and error #6710 "Could not attach to target" in studio.

 

For some reason, in the pages, we change the "homepage" to /NameHere/package.home.cls.  I wonder if that affects how I can/can't open it in debug mode using /csp/package.home.cls.

 

Thanks,

Laura

 

Oh -- the page displays if I take off the ?CSPDEBUG=1431597865 at the end of its URL...

 

 

A few questions:

  • If you open the same URL without the CSPDEBUG URL parameter, what happens?
  • Does /namehere/package.home.cls work as a debug target?
  • Is the webserver port correct for IIS, or are you using a private webserver that isn't enabled? (The webserver port Studio uses can be changed in the Cube under Preferred Server > Add/Edit...)
  • Does the audit database show anything odd?

For troubleshooting CSP issues (although more often on InterSystems' side than in application code), ISCLOG can be helpful. For example, run the following line in terminal:

kill ^%ISCLOG set ^%ISCLOG = 3 read x set ^%ISCLOG = 0

Then make whatever HTTP request is causing an error, then hit enter in terminal (to stop logging), then:

zwrite ^%ISCLOG

There might be a lot of noise in there, but also possibly a smoking gun - a stack trace from a low-level CSP error, an error %Status from something security-related, etc.

I'll try some things... Yes, the page displays when I remove the ?CSPDEBUG part.

Ah, /namehere/package.home.cls does nto work as a debug target.  I see that /namehere/ (or Samples) is the namespace.  But, this particular combo does not work: URL not found.

I'm not sure how the port would be wrong, since I can open the page as a URL, or with View/Web Page (F5)... as far as I know, the port is c orrect, since I'm using studio in DEV, etc. Is the port a part of the debug target? how does it know ?  Yes, we are running it on IIS on the DEV server.

I'll try the logging thing.

Thanks,

Laura

 

The port isn't part of the debug target - that's configured as part of the remote/local server definition in the cube (in the system tray).

Since the page works with ?CSPDEBUG removed, it'd be interesting to see ^%ISCLOG or if there are any interesting events (e.g., <PROTECT>) recorded in the audit database.

Ah, ok.  Thanks for all this info.  I did look at ^%ISCLOG, but it was a ton of stuff.  I 'll seeif I can find something relevant, or record only the moment when I'm trying to connect.  The global STARTED at 3K-something and the rest was lost on my terminal. It looked like it was recording everthing from the entire server? Production, everythiing?

Thanks,

Laura

 

Ah - yes, a number of things log to ^%ISCLOG. It's very important to set ^%ISCLOG = 0 at the end to keep it from continuing to record. The command I mentioned previously is an easy way to make sure that you're only logging for a brief period of time - paste the command into Terminal and hit enter to start logging, then load the page, then hit enter in Terminal to stop logging. Still, there could be lots of other stuff in there even from having it enabled briefly depending on how busy the server is.

It might make sense for you to contact InterSystems' outstanding Support department - someone could work through this with you directly and help you find a solution more quickly.

Excellent, I will do that.  I'm sure I'll want to be able to run through the debugger at some point.  I was able to fix my bug, actually (it was an easy fix), but I do love a good debugger.

 

Thanks for all the help.

Laura

Hi Timothy,

I thought you'd be interested to know that Kevin at InterSystems helped with this issue, and he found that some breakpoints inside javascript code were causing the error.  Just having the breakpoints there caused it -- the code didn't get anywhere near the breakpoints -- so he removed all of the breakpoints, and that worked.  We had to change the debug target ... the Zen application is mapped to another folder, rather than the default of /csp/namespace.

Thanks for your help!

IS was timely and helpful.  Thanks Kevin!

Laura

I worked with Laura to investigate the issue.  We found that the ultimate source of the error was logged in Studio as

Unable to set breakpoint as line not mapped 'myJSMethod+1^MyPackage.MyClass.CLS'
CSP: BREAKPOINTS failed

The debugger was unable to attach to the target so the CSP page wasn't returned to the client.

The reason that the line isn't mapped is that "myJSMethod" is a client method.  Zen pages can define COS methods that run on the server and Javascript methods which run on the client.  The Cache Studio debugger runs on the server and debugs code run by the Cache instance.  Javascript methods can be debugged client-side using browser tools such as Firebug.