Error while trying to attach debugger

Jul 18 at 6:52 AM
I am trying to attach file to bottle py website, receiving error Image
Coordinator
Jul 18 at 6:51 PM
I've noticed your StackOverflow post before I noticed this thread. Let's follow up here, and then we can link here from SO when we figure it out.

First of all, can you clarify which PTVS version and Python version you're using?

Did you enable web sockets for your website in the Azure management portal? (you should get an error message telling you to do that if they're not enabled, but I wonder if we have missed some of the ways the server can report that)

Also, if you have just published to the site, make sure that the site itself is up and running. The debugger components on the server are hosted by the same IIS process that hosts your app, so if e.g. something is misconfigured in your web.config, both the site and the debugger endpoint will be unavailable. On StackOverflow, you've mentioned that your site gives you an internal server error - can you show what that looks like in the browser?
Jul 19 at 1:32 AM
I am using PTVS 2.1, python version 3.4

Yes, websockets is enabled. I do not have control of IIS, it is published to azure websites.
Image)

Internal Server error.
Image
Coordinator
Jul 19 at 2:04 AM
What do you get if you navigate to https://skvportfolio.azurewebsites.net/ptvsd ?
Jul 19 at 4:00 AM
Yes I tried manually attaching as well, received the same error.
Coordinator
Jul 19 at 4:34 AM
I mean, does the ptvsd page even load up for you?

(if it does, this indicates that web.config at least is okay and has no errors, and the proxy should be there)

Nevermind though, I poked the endpoint and it's there and reporting that everything is a-ok.

I think it's one scenario that we haven't really thought of. The problem is that to attach to Python code, you actually need to be running Python code. But if your request handler immediately terminates (e.g. because some code somewhere throws an exception), you simply don't get any opportunity to attach...

The proxy could handle this better by faking the debugger protocol for the initial handshake if the actual debugged process is not there yet, and wait for it to appear, then transparently hand it over - then you could attach without anything running on the server, and run all Python code on the request handling path from start to finish. But this would require making the proxy much smarter than it currently is, so that's a significant change.

In the meantime, here's something that I think might help. You need to find the file on your system at the following path (adjusting as needed):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Python Tools\ptvs_virtualenv_proxy.py
Inside it, there is a line of code that reads:
            ptvsd.enable_attach(ptvsd_secret)
Immediately after it, insert:
            ptvsd.wait_for_attach()
Then re-publish your project. The effect should be that (when deployed in Debug configuration - i.e. when WSGI_SECRET is set in Web.Debug.config), request handling simply won't proceed until you attach the debugger.

The annoying part will be that whenever you want to not have it wait anymore, you'll have to re-publish in Release.
Marked as answer by skvsree on 7/19/2014 at 8:03 AM
Jul 19 at 4:03 PM
That helped me debug the issue. So I would mark this as answer. Appreciate your effort.
But the error seems to be arising from classic 64 bit-32 bit conflicts. I am was using 64 bit version of Python and it was conflicting with 32 bit only version of python inside site. I get warning that azure websites support only 32 bit, is it so ?. This was resulting in lot of library problems. Also use the http://www.lfd.uci.edu/~gohlke/pythonlibs/#sqlalchemy for installing into virtual env, this helps solving c-extensions issue which do not happen in local.
Long story short, I switched the version to 32 bit and its now working.


Coordinator
Jul 19 at 8:06 PM
Yes, the Python version that's installed on Azure is 32-bit only.

In theory, you can tweak things so that you deploy your own Python with your web site, and use it to run it (it's what you had to do before Azure web sites preinstalled a global interpreter). This is very non-trivial now, since it would require using applicationHost.config XDT transforms to change the binary associated with .py files for IIS FastCGI.