This is on WinXP, SP2, JDK 1.6.0_u11, Jython 2.5.0+ (the default).
I debugged a simple python script stepping over a few statements using F8 and then stopped the debug session.
This behaviour 100% reproducible.
Thread dumps are attached.
Created attachment 74664 [details]
zip file containing 4 thread dumps taken with jstack -l
in order to be able to reproduce , attach a sample + describe the scenario leading to the problem.
The scenario is obviously already described in the bug report: single step through a python script and
then stop the debugging session - it is really that simple (what do you expect me to do? Firing up Camtasia to create a
movie to show you how I am debugging a simple 5 line python script?)
for i in range(bar):
After 5 times through the loop stop the debugging session. NB hangs.
The jstack output should tell you what is going on.
The problem I am having now: I tried to test with native Python 2.6 and now NB ends up in a tight endless loop while
indexing python 2.6 after startup. I need to find out first, how to get NB in workable state again, before I can
continue (ok, I removed python 2.6 to get off the hook).
Thanks for reporting the problem using the python script you provided or other python scripts.
I can't reproduce the hang at all on Windows using either the bundled Jython or Python 2.6. I tried on both Python EA
(both Jython and Python 2.6) and the latest development build 257 (only Jython since there's regression so no new pyhton
platform can be added). Which Python build are you using (EA or dev build)?
Now I tried the same on a different box, a Dell Studio 17 with Vista Home Premium, JDK1.6.0_11, NB 6.5, Python EA 0.100.
Other scripting language support is installed (PHP, JavaFX 1.0).
I used the same script and stepped through it using F8. After pressing F8 on the line that says "foo(1)" the number 1 to
10 are printed in the output window and now NB hangs.
I am attaching the usual thread dump (I thought thread dumps are usually sufficient to find the cause of a lock-up(?)).
Created attachment 74734 [details]
jstack -l output after NB locked up
FWIW: foo(1) should have read foo(10)...
Created attachment 74735 [details]
NB after final F8
Although my dvp box is linux , I tried your sample + scenario on dev #265 in both jython or python contexts withou being
able to reproduce it on a linux box either.
When you press the stop button the action behind is just sending a STOP command to the Python debugger backend script
over the debugging ip session on 127.0.0.1 ; since previous debugging stepping have been working I do not see any
reason of hanging there in the code.
So I changed the status to worksforme
verified in the python EA build on Windows Vista using jdk 1.6.0_11 or jdk 1.6.0_07 and I could reproduce the problem. I
have not been able to reproduce this before though until now. I could not reproduce it before because I did not have
JavaFX installed but I have the full 6.5 installed. I just installed JavaFX 1.0 yesterday to take a look at JavaFX.
While having JavaFX installed, I tried to verify this issue and I could reproduce it every time. Not even stepping into
the debugging session. Starting debugging already froze ide. After I uninstalled JavaFX, this problem is no longer
reproducible. So, it looks like there's some incompatibility with JavaFX. Not sure if it's only python that has this
problem or other modules also have this. I'll install JavaFX again and try debugging other modules like Java, Ruby, etc,
I'm reopening this issue for now as a reminder till next week.
Thanks for not being content with a WORKSFORME, but instead going the extra mile and continuing the investigation into
this! As a first result there is a work-around now, although a heavy-handed one (uninstalling JavaFX support).
I am able to reproduce the hang on Mac. My scenario was NB6.5 installed with Python EA and python project created.
Debugging and stopping after a few iterations of:
for i in range(bar):
No problems. Then I installed JavaFX sdk for mac and JavaFX plugin repeated the debugging/stop debugger and NB hangs.
Thanks for Tony for confirming this on Mac. And thanks Georg for confirming again. Looks like it's really the JavaFX
that causes the hang. I'll see where this issue should be categorized.
The more general aspect here is one plugin breaking others, indicating that NB is susceptible to the plugin hell phenomenon.
Since it has been clearly identified that this problem occurs only with javafx, I switched this problem to WONTFIX on
my side for following reasons :
- javafx is neither part of 6.5 python trunk nor part of the 7.0 mercurial main trunk => I can't get the javafx plugin
sources which looks part of experimental stuff in nb cluster.properties.
- javafx is not officially available on linux / solaris => No way for me to get it working on my dvp platform.
- I would have been happy to start a netbeans debug session with javafx activated to reproduce the problem ... But i do
not have the necessary stuff to do it.
- More generally I think that this problem should be relative to javafx instabilities around GUI stuff and that the
python debugger is just a debug case of GUI freezing to be submitted to the javafx guys.
If they raise any problem in python code just reassign this ticket to me then.
I strongly protest against closing this issue with WONTFIX before a corresponding bug report has been entered on the
JavaFX side! Please keep it open until then. Moreover you need to prove that this bug is not related to Python before
you can close it in this way and I don't think we have enough information yet.
If you do not have the means, you should talk to your supervisor to provide them (if Sun publishes stuff that runs only
on Windows and Mac, it has to give its engineers the means to investigate bugs on these platforms. Everything else would
be pointless). That you currently are limited to Linux or Solaris is in no way a justification to close a bug report.
(If you need a Windows installation, maybe you can deploy XP or Vista in a virtualized environment).
Sorry for taking so long on this issue. I agree with Georg to keep this open. I emailed to the person on the javafx side
but haven't heard anything. I'd just recategorize this issue to javafx. If they decide this is in python after
evaluation of the problem, they can change it back to python.
Keep it open is fine by me , And I am also more than happy to look at any python reason to break javafx ....( and that
was preciselly what I was going to do before switching to WONTFIX) ... assuming that I got informations about javafx
netbeans plugin source location which is not on the main 7.0 trunk right now which makes it impossible to me to start a
remote debug session on this case.
So to sumarize my WONTFIX was a WONTFIX because I do not have involved last javafx sources available somewhere on
mercurial + specific building rules if any to be able to debug the situation WITH JAVAFX PLUGIN SOURCES.
I understand. In this case, let's let the javafx take the first evaluation then. Thanks.
In the stack trace I see a deadlock in org.netbeans.modules.python.debugger.actions.JpyDbgView:
- org.netbeans.modules.python.debugger.PythonDebugger locks org.netbeans.modules.python.debugger.actions.JpyDbgView
(probably wrong usage of synchronized method) and then terminates the debugger session with firing all the changes
through DebuggerManager, where one of the listeners invokes some code through SwingUtilities (requiring AWT thread to
- at the same time is org.netbeans.modules.python.debugger.actions.JpyDbgView called from AWT thread but locked
I think that JpyDbgView should solve internal synchronization more safely. It is dangerous to use critical sections when
called from AWT and when notifying listeners of DebuggerManager from the critical section at the same time.
We may also remove SwingUtilities request from our DebuggerManager listener
(org.netbeans.modules.debugger.javafx.projects.EditorContextImpl), but the deadlock may manifest on some other
DebuggerManager listener in the future.
Fixed in 7.0 trunk build #545 and above
(critical section improvement in python debugger stop action)