winpdb deadlock on vxWorks

[Dustin Spicuzza]

Hey,

I'm trying to use winpdb on a FIRST Robotics cRio embedded controller
running vxWorks 6.3, using the RobotPy port of the python interpreter
to the vxWorks platform. I've had to strip out the hmac/digest/md5
functionality out of it and use a static password [RobotPy doesn't
support md5/hmac correctly at the moment, and I'm not in the mood to
fix it], but now it seems to work great when I can actually attach to
the remote process.

The problem is that in the 5 minute waiting period, I cannot attach to
winpdb remotely. After the waiting period is done, I can attach while
the code is running. It appears to be some kind of deadlock. Of
course, I could disable the waiting period, but I'm interested in
fixing the deadlock. Where I think it's at while it's waiting:

Main thread:
Appears to be in CDebuggerCore::settrace(), at
sys.settrace(self.trace_dispatch_init). trace_dispatch_init appears to
be called twice, though one of the calls might be from the
threading.settrace().

Thread 1:
Appears to be in __StartXMLRPCServer(), at the creation of
CXMLRPCServer().

Thread 2:
My guess is this is the timeout thread waiting for the timeout to
expire, but I can't be certain.

I realize that this isn't exactly a supported platform, but any help
you can give me would be appreciated. Any thoughts on what might be
the problem, or how I might better diagnose it? Thanks! :)

Dustin

[Nir Aides]

Can you move the start_embedded_debugger() call to a location guaranteed not to be called in parallel by two threads at the same time?

e.g. during one of the initial module imports

--
You received this message because you are subscribed to the Google Groups "Winpdb" group.
To post to this group, send email to win...@googlegroups.com.
To unsubscribe from this group, send email to winpdb+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/winpdb?hl=en.

[Random Person]

My main program only has one thread, so it will definitely not be called in parallel by two threads at once.

Dustin

[Random Person]

So I figured out what it was... I feel slightly silly, it was apparently a deadlock caused by the import module (which I gather you must have ran into before, since there's a function called workaround_import_deadlock )... and since I called start_embedded_debugger() at the top of my module, creating the XMLRPC server imported a bunch of encoding stuff in a different thread and it deadlocked until the import of my original module completed. Yay.

Other than that, Winpdb seems to work pretty well in vxWorks so far. I'll post patches as I come across bugs that aren't platform specific. :)

Dustin