Hi Heikki,

I believe that integrating the threads would not be so hard... There has been a similar issue when dealing with threads in CORBA. The solution for that is published in the Pydev Faq, under "I have a CORBA program and I cannot debug its methods, what can I do?"

While I haven't tried making those changes myself, it should be simple just to say that it should start to debug some thread, as long as you know where is the 'creation point' of the thread (so, seeing the solution for komodo, I must say that the solution to pydev should be pretty similar).

As for the hang... that's the first report I had about some program hanging when running inside of the debugger (I'll take a look at it)...

Also, if you use Pydev Extensions (http://www.fabioz.com/pydev), you could use the remote debugger, so, you'd probably bypass this problem at the time you get to the point where you start debugging (without any loss of speed until you get at the call to stop the debugger). The manual for the remote debugger is at: http://www.fabioz.com/pydev/manual_adv_remote_debugger.html



On 2/8/06, Heikki Toivonen <hjtoi@comcast.net> wrote:
My benchmark for a speedy debugger is Chandler. Until now, only WingIDE
and ActiveState Komodo have been usable GUI tools to debug Chandler
(well, that I have tried anyway).

The latest pydev seems speedy enough now to debug even Chandler.

The hardest problem in debugging Chandler is dealing with threads,
because threads are created by gcj and not by Python. WingIDE cannot be
used to debug Chandler threads (it only sees the main thread). We have
hacked a patch that lets us debug background threads in Komodo (see
http://wiki.osafoundation.org/bin/view/Projects/DebuggingChandler#Multi_threaded_debugging_in_Komo ).
(Presumably something similar could be done for WingIDE but AFAIK nobody
has tried.) I wonder if the unusual threads in Chandler are the cause of
a showstopper bug when trying to debug Chandler with pydev...

When starting Chandler under the pydev debugger all is well until
Chandler just hangs, and pydev won't step any further. It gets to a
point where the Chandler splash screen is up, reporting 55% done, and
then stops here:

        getVersion [DBContainer.py:1533]
        getVersion [DBRepository.py:773]
        __init__ [RepositoryView.py:939]
        createView [DBRepository.py:518]
        fork_item [ startup.py:122]
        invokeTarget [startup.py:160]
        onStart [startup.py:184]
        _start [startup.py:89]
        run_startup [startup.py:24]
        initWakeup [Utility.py:492]
        OnInit [ Application.py:357]
        _BootstrapApp [_core.py:7338]
        __init__ [_core.py:7686]
        realMain [Chandler.py:55]
        main [Chandler.py:68]
        ? [Chandler.py:108]
        run [pydevd.py :551]
        ? [pydevd.py:666]

So, I guess I am asking if anyone would know if a hack similar to Komodo
could be employed (see the link above), and/or if the hang is something
else. I'd be happy to provide anyone with instructions on how to deal
with Chandler, although these would be a good start:


  Heikki Toivonen

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
Pydev-code mailing list