Bug 154875 - NB hangs after stopping debug session
NB hangs after stopping debug session
Status: RESOLVED FIXED
Product: python
Classification: Unclassified
Component: Debugger
6.x
All All
: P1 (vote)
: 6.x
Assigned To: jymen
nbpythonqa
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-07 21:27 UTC by giorgio42
Modified: 2009-02-19 22:57 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
zip file containing 4 thread dumps taken with jstack -l (17.05 KB, application/x-compressed)
2008-12-07 21:30 UTC, giorgio42
Details
jstack -l output after NB locked up (20.67 KB, text/plain)
2008-12-09 09:06 UTC, giorgio42
Details
NB after final F8 (175.74 KB, image/png)
2008-12-09 09:20 UTC, giorgio42
Details

Note You need to log in before you can comment on or make changes to this bug.
Description giorgio42 2008-12-07 21:27:53 UTC
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.


Georg
Comment 1 giorgio42 2008-12-07 21:30:22 UTC
Created attachment 74664 [details]
zip file containing 4 thread dumps taken with jstack -l
Comment 2 jymen 2008-12-08 08:06:35 UTC
in order to be able to reproduce , attach a sample + describe the scenario leading to the problem.
Thanks
Jean-Yves
Comment 3 giorgio42 2008-12-08 22:19:35 UTC
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?)

Like this:

def foo(bar):
  for i in range(bar):
    print i

foo(10)

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).







Comment 4 Peter Lam 2008-12-09 01:17:00 UTC
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)? 
Comment 5 giorgio42 2008-12-09 09:02:21 UTC
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(?)).

Georg

Comment 6 giorgio42 2008-12-09 09:06:39 UTC
Created attachment 74734 [details]
jstack -l output after NB locked up
Comment 7 giorgio42 2008-12-09 09:18:01 UTC
FWIW: foo(1) should have read foo(10)...
Comment 8 giorgio42 2008-12-09 09:20:03 UTC
Created attachment 74735 [details]
NB after final F8
Comment 9 jymen 2008-12-09 13:25:31 UTC
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

Comment 10 Peter Lam 2008-12-13 09:13:07 UTC
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,
next week.
I'm reopening this issue for now as a reminder till next week.
Comment 11 giorgio42 2008-12-13 19:21:40 UTC
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).

Georg
Comment 12 tonybeckham 2008-12-17 00:29:02 UTC
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:

def foo(bar):
  for i in range(bar):
    print i

foo(10)

No problems.  Then I installed JavaFX sdk for mac and JavaFX plugin repeated the debugging/stop debugger and NB hangs.
Comment 13 Peter Lam 2008-12-17 00:58:57 UTC
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.
Comment 14 giorgio42 2008-12-17 09:24:48 UTC
The more general aspect here is one plugin breaking others, indicating that NB is susceptible to the plugin hell phenomenon.
Comment 15 jymen 2008-12-17 10:46:35 UTC
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.

Jean-Yves
Comment 16 giorgio42 2008-12-17 15:52:19 UTC
Jean-Yves,

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).

Comment 17 Peter Lam 2008-12-17 16:23:10 UTC
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.
Comment 18 jymen 2008-12-17 17:16:16 UTC
Peter ,

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.
Comment 19 Peter Lam 2008-12-17 17:42:58 UTC
Jean-Yves, 
I understand. In this case, let's let the javafx take the first evaluation then. Thanks.
Comment 20 Adam Sotona 2009-01-05 13:26:40 UTC
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
perform).
- 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.
Comment 21 jymen 2009-01-08 09:56:54 UTC
Fixed in 7.0 trunk build #545 and above 
(critical section improvement in python debugger stop action)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo