Bug 156315 - debugging project always step into UserDict.py source
debugging project always step into UserDict.py source
Status: VERIFIED FIXED
Product: python
Classification: Unclassified
Component: Debugger
6.x
All Windows Vista
: P1 (vote)
: 6.x
Assigned To: jymen
nbpythonqa
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-06 01:30 UTC by Peter Lam
Modified: 2009-02-19 22:57 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Lam 2009-01-06 01:30:23 UTC
build 20090105-b519 on Windows Vista

- create a new python project
- change the debug option not to stop at line #1
- open the default .py file is not already opened
- optional step: set a breakpoint to the print statement line
- debug the project
Result: UserDict.py is opened in the editor and the cursor is moved to line 24 in the file and debug session ended
normally without stopping at the breakpoint.
Comment 1 jymen 2009-01-08 10:13:49 UTC
I followed the scenario but was not able to reproduce in Linux ubuntu :
-> debugger does not enter UserDict.py and the breakpoint is hit correctly ; I made the test both with jython 2.2.1 and
2.5.b0+. 
I have been able to observe this problem before when some jython libs in current 2.5 beta are still buggy they may hit a
debugger stop when they raise exceptions.
So when I allways do a test with a python2.4 , Python 2.5 , jython 2.2.1 platform in that case. If those three platform
PASSED then I wait for a more stable build of jython beta 2.5.

I found any a bug when 'stop on first line' is unchecked and a breakpoint is set on first line that I fixed in #545.
I also prevent jython systemlib UserDict.py to be controlled by debugger ... I think this should fix your problem since
I suspect the UserDict.py to raise exception when under trace control.

starting with 7.0 trunk build #545 and above I prevent UserDict.py to be traced by debugger.
Comment 2 Peter Lam 2009-01-08 23:12:26 UTC
with build #550, it now steps into traceback.py at line 222.
Comment 3 Peter Lam 2009-01-08 23:18:00 UTC
forgot to say that I used the bundled Jython 2.5b. With Python 2.4.4, debugging stepped into traceback.py line 219. With
Python 2.5.2, it steps in traceback.py line 234. With Python 2.6, it also steps in line 234 and popped up the following
exception as well. I'll install jython 2.2.1 to try if I can find one.

Annotation: Was parsing C:\Python26\Lib\lib2to3\tests\data\py3_test_grammar.py
Annotation: Was parsing C:\Python26\Lib\lib2to3\tests\data\py2_test_grammar.py
Was parsing C:\Python26\Lib\lib2to3\tests\data\py3_test_grammar.py
Was parsing C:\Python26\Lib\lib2to3\tests\data\py2_test_grammar.py
Caused by: java.lang.ClassCastException
Was parsing C:\Python26\Lib\lib2to3\tests\data\py3_test_grammar.py
Was parsing C:\Python26\Lib\lib2to3\tests\data\py2_test_grammar.py
Comment 4 tonybeckham 2009-01-08 23:28:35 UTC
Not reproducible for me with build 547 will try 550 next.
Comment 5 tonybeckham 2009-01-08 23:36:35 UTC
Can't reproduce on Mac with build 551 for Jython nor Python platform projects.  Maybe delete your user dir then try
again?  I have had some issues lately that were solved that way.
Comment 6 Peter Lam 2009-01-08 23:42:42 UTC
Thanks for trying!
I always started a new build from fresh userdir and created new projects to start with.
Which version of python platform you use?

I just installed jython 2.2.1 and got stepped in StringIO.py line 51. Perhaps there's a compatibility issue on Windows?
I'll try linux to see if this problem exists.
Comment 7 Peter Lam 2009-01-09 01:50:17 UTC
I verified in linux and this problem is not reproducible. looks like it's only happening on windows. I'm changing the OS
to windows vista. Will try it on Windows XP.
Comment 8 Peter Lam 2009-01-09 02:03:06 UTC
On Windows XP using the bundled jython 2.5b, it steps into traceback.py line 222.
Comment 9 jymen 2009-01-09 10:17:45 UTC
Ok guys , I think it's time for me to setup an XP virtual machine (snip...) and give it a try ;=)
So I'll built that VM and will try to reproduce the issue then
Comment 10 jymen 2009-01-09 15:59:33 UTC
I am now able to reproduce that on an XP box ; I confirm that 's a WINDOWS specific regression on debugger's startup
- The debuggee file name is not found (something truncated when filename contains spaces ??? I need to debug further).
- then the python debugger enters an external exception and stop in the system traceback


 
Comment 11 jymen 2009-01-13 11:03:28 UTC
when creating a Python project the name of project and source is newpythonproject which on windows generate a filename
like \newpythonproject => \n then was badly interpreted as control character when sending the filename over IP session
which resulted in debugge file not found by the debugger session.

fixed on trunk starting with hudson build #595 and above. 
Comment 12 Peter Lam 2009-01-14 02:04:52 UTC
verified in build 20090113-b599


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