Hi Martin,
If you can spare the time, I'd appreciate getting a problem report snapshot
made with default timeout settings after trying to launch an application.
I will look at it again to see if I can spot anything untoward. I'll also
see if I can add some additional debug messages to indicate where exactly
the hang occurs.
I suspect this is a thread deadlock problem. JDEbug has a bunch of threads
running through synchronized methods and fields. A summer intern at Sun
designed and wrote the first implementation of JDEbug and I'm still feeling
my way around his code, trying to figure out how the threads interact and
whether all the synchronized methods are really necessary.
Regards,
Paul
At 08:21 AM 10/25/00 -0400, you wrote:
>Hi Paul,
>
>> I would appreciate if if anyone who has had command
>> timeouts when attempting to launch applications in
>> JDEbug, especially on Windows/NT, would try whether
>> this variable makes a difference.
>
>I'm on Windows 2000 -- I sent you a bug report with info about the hang and
>my environment awhile ago. I tried the new variable, using ranges from the
>default 1 up to 30. I tried with host address of my machine name and host
>address of 127.0.0.1. I tried with classic and hotspot VMs. I tried using
>command timeout ranges from the default 10 up to 60.
>
>No dice. Same command timeout behavior. Emacs sees the JDEbug process
>running; task manager sees a javaw running, but never the twain shall meet.
>Changing the timeouts seems to simply increase my wait before it gives up.
>
>If you'd like me to look at/try anything else, let me know. If I had some
>ideas about where to poke, I'd be happy to investigate.
>
>Martin
>
>ps. On another front, the new update + new semantic stuff still can't parse
>the original file behind that sample I sent you -- I still get the
>max-specpdl-size exceeded error, and when I increase it, I then still get
>max-lisp-eval-depth exceeded. Just FYI (it's the only file out of 100+ to
>have this problem, and it's definitely not a big deal).
>
