Can't get a debug environment up

I’m trying to debug the collada exporter script in blender but cannot attach winpdg to blender without experiencing lock ups.

If I launch winpdb form within Blender it says it is “attaching” and then says “not attached”.

I’ve tried putting:


import rpdb2; rpdb2.start_embedded_debugger("password")

…at the beginning of the script and it just locks my machine up unresponsively even if I have already been into winpdb and set the password to “password”, I cannot even alt-tab to winpdb to get it to try to attach.

Is this a bug that anyone else gets? I’m not exactly comfortable with debugging with something that hard-locks my pc so easily!

Have just removed winpdb and SPE and checked them out from SVN.

Have now got winpdb 1.3.6 and this is the output I get when attaching:

*** Attaching to debuggee...
*** Failed to attach to '<string>'.
*** Command returned the following error:
*** <class 'socket.timeout'>, timed out.
*** Please check stderr for stack trace and report to support.

I’ve now found that it was timing out after 5 minutes but if I try again or change the order I open winpdb up, it locks up permanently.

Is there some sequence I am missing? Load blender, load script into text editor, add debugger launch code as earlier in the thread, run winpdb and configure the password and open the attach window, run blender script - lockup for 5 mins then disconnected. Any attempt to retry causes a permanent lockup.

You have not written, which OS you are using (Windows? Linux? Mac?)
SPE has nothing special to do with winpdb in debugging Python scripts: this is a communication between Winpdb and Blender.
Winpdb requires not only the password, but also the name of the script to debug, as an argument. There is a tutorial at, which shows how debugging works for Windows.
Even when you are using Linux, look at Appendix B.2 to this tutorial. It is code that runs the winpdb in Windows. It may not work on Linux, because the passing password through named pipe (as you can see in this code) was not tested. Anyway, if you run Winpdb with the arguments that this script is trying provide, and THEN run the script with rpdb2.start_embedded_debugger(“password”), you should suceed.
Notice, that start_embedded_debugger() has two arguments: the second is the timeout!

Sorry, I didn’t say the OS. I am having problems under windows.

I managed to get it working under Ubuntu with Blender 2.45 and the svn versions of winpdb and SPE but I really need it to work under windows.

Are you saying don’t run winpdb from within SPE or use the link it creates in blender?

I don’t really understand this, I thought that “” was already being run from the entry that SPE added into blender?

So I run the file and then put the start_embedded_debugger() code in the script in blender and run it? I’m not sure if you fully understood the issue I had but when I run start_embedded_debugger(), it locks up the machine making it impossible to go into winpdb and select the process to attach to. But if I run winpdb from the attach debugger menu option, it tries to connect but fails. If I then run the script from within blender quickly before it has a chance to fail - locked up machine.

Well, let me make sure, what is going on your machine, step by step:

  1. It looks that you have installed SPE (and the winpdb together with it)
  2. Then you have installed newer version of Winpdb: did you overwrite the old files inside _spe directories, or installed it as the standalone program, in another directory?
  3. You have attached the SPE and WIndpdb commands to Blender’s Scripts window (Scripts–>System menu)?
  4. When you run the Scripts–>System–>Attach Winpdb command, it opens Winpdb, but it fails to conenct to the <string> script?
  5. When you type in the command line (does not matter from which directory) the command “python” does it run? When you type in the same command line “python” - what happens?
    I remember such effect (not being able to attach Windpb for the second time) for the Windpb old versions. It was fixed somewhere onNovember by its author (Nir Aides). Maybe it has appearared again?
    Could you answer me on the thread I am not very good at scanning many threads, so I have selected a few ones, to watch.