This project has moved and is read-only. For the latest updates, please go here.

Debugging Mari2.6v1 with PTVS

Jul 22, 2014 at 9:31 PM
I'd very much like to debug my python tools in Mari with PTVS like I do in Maya and Houdini. Currently I run into an issue where I can attach Mari to VS and set break points but the break points do not hit when I run my code from within the Mari script editor. This workflow tends to work just fine with Maya, Motionbuilder and Houdini.

I can hit break points when I run my code using Mari in terminal mode. In Mari, terminal mode effectively runs the tool without actually drawing the UI so you interface with it through a python shell.

This leads me to suspect that the Mari UI may be obstructing PTVS from connecting to my script when running from within Mari. Is there a way that I can get better feedback from PTVS once it attaches to a process so that I can see where things begin to break down before testing a break point?

Thanks for any help in advance!
Jul 22, 2014 at 10:12 PM
We don't have any special logging for debugger attach, but there are some tricks to try to diagnose different issues.

First of all, when you attach, do you see any .py or .pyc files listed in the Modules window (if you don't have it visible, it's under Debug -> Windows when you're debugging)? If you do not have anything like that there, then attach didn't complete successfully.

If it did attach properly, then another trick is to make a script that loops infinitely (or for "long enough") and attach while it's running. Then use Debug -> Break All to pause execution. It should stop somewhere in your loop - what does the Call Stack window show at that point? In particular, does it give proper filenames in frame descriptions?
Jul 23, 2014 at 7:38 PM
Thank you for the quick response!

When I attach to Mari once it's launched, I do not see any files listed in the Modules window. However, when I attach to Mari in terminal mode, I see plenty of py files in the list. It seems like it does not attach properly when connecting to Mari in it's GUI form rather than its terminal form. Mari's GUI should be PyQT. Are there any known issues with connecting ptvs to a PyQT application?

Jul 23, 2014 at 7:51 PM
I'm not aware of any issues specifically with attaching. One problem that I know of with PyQt is that if its classes (rather than Python's standard thread/threading modules) are used to spawn threads, then debugger won't see those threads. But it should still see the main thread on which interpreter is initialized.

Beyond that, it would probably need investigating specifically with that product. Feel free to file a bug in the tracker, and I'll try to get a local repro and look at it once I get to it.

In the meantime, there are some workarounds that might help. First of all, try using remote debugging. When the Python side can explicitly set up ptvsd, attaching to it is much more reliable than the normal Debug -> Attach to Process path, especially with a custom host.

If that still doesn't help, then I would suggest that you try attaching with mixed mode debugging. Basically, when attaching, instead of letting VS detect the code type, select it manually, and mark C++ along with Python. The mixed-mode engine is very different from the regular one, and one thing in particular that it generally does more reliably is attaching to a running process. This comes at a price - the Python part of the mixed debugger is much more limited in what it can do compared to the regular Python debugger (there is a list of limitations in the doc page). But it's better than nothing, and generally just "good enough" for many common cases.
Jul 23, 2014 at 11:38 PM
Thanks for the tips!

I tried remote debugging. In terminal mode, it's fine but with Mari, VS freezes and crashes. I tried mixed mode debugging using Python and native language. Modules did finally load in but the break point still did not hit.

I went ahead and set up a bug for this issue with repro steps.

I didn't know about these tricks before and I can definitely see them as useful down the line when I run into similar issues with other packages.
Jul 24, 2014 at 1:05 AM
If you can see the modules load with mixed mode, can you try the break-in-infinite-loop as described above to see where you end up breaking, and specifically what the call stack looks like?

Also, one thing that I should have probably clarified at start: which version of PTVS are you using? If it's PTVS 2.0, then I'd strongly recommend retrying the things that didn't work for you with 2.1 beta, because there is a number of debugger fixes there that might set this right.