Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 125090 - Debugger doesn't stop at breakpoint on Windows
Debugger doesn't stop at breakpoint on Windows
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
6.x
PC Windows XP
: P1 (vote)
: 6.x
Assigned To: rmatous
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-11 08:30 UTC by Jiri Skrivanek
Modified: 2008-12-22 10:24 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Stack trace. (6.63 KB, text/plain)
2008-01-11 08:31 UTC, Jiri Skrivanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2008-01-11 08:30:35 UTC
Java debugger doesn't stop at breakpoint in java file on Windows. Maybe it is caused by changed in filesystems. It
happens since build 200801090000. To reproduce:

- create a java project
- add breakpoint to Main.java
- start debugger and it doesn't stop at breakpoint and exception is thrown

WARNING: externally created folder: D:DevelopmentbuildsnbUserdir-20080111092113JavaApplication1build
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.findFileObject(FileBasedFileSystem.java:159)

Product Version: NetBeans IDE Dev (Build 20080111054747)
Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Userdir: D:\Development\builds\nbUserdir-20080111092113
Comment 1 Jiri Skrivanek 2008-01-11 08:31:03 UTC
Created attachment 54934 [details]
Stack trace.
Comment 2 Marian Mirilovic 2008-01-11 10:19:57 UTC
adding Radek on cc (realted to changes in FS ?)
Comment 3 Martin Entlicher 2008-01-11 14:53:01 UTC
The exception is thrown from masterfs.
Comment 4 rmatous 2008-01-14 16:03:18 UTC
D:DevelopmentbuildsnbUserdir-20080111092113JavaApplication1build is just wrongly printed warning.

SourceForBinaryQuery.findSourceRoots returns null because of external change. Definitely caused by #123542, but the
source problem is that FS doesnt know about external changes. Please, evaluate.
Comment 5 Tomas Zezula 2008-01-14 21:18:27 UTC
Evaluation: #123542 caused this as you pointed out, seems non compatible semantic change => reassigning back to openide.
Anyway the java/j2seproject is not good candidate, the refresh is done after the ant script finished, which is not this
case (the JPDA ant task is started before the finish). So the JPDA ant task should call refresh, right?
Or do you want me to do so in the SFBQ and possibly other queries? Probably not, the code for refresh will need to be
copied to every usage of FileUtil.toFileObject() which makes the usability of such an API much worse.
Comment 6 Tomas Zezula 2008-01-14 21:27:34 UTC
Btw: here comes a part of the javadoc FileUtil.toFileObject()
<cite>
If you are running with the MasterFS module enabled, that will guarantee
that this method never returns null for a file which exists on disk.
</cite>
And I believe that the IDE still runs with MasterFS enabled.
Comment 7 rmatous 2008-01-15 10:58:22 UTC
/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/filebasedfs/fileobjects/FileObjectFactory.java,v  <-- 
FileObjectFactory.java
new revision: 1.21; previous revision: 1.20

/cvs/openide/masterfs/test/unit/src/org/netbeans/modules/masterfs/filebasedfs/BaseFileObjectTestHid.java,v  <-- 
BaseFileObjectTestHid.java
new revision: 1.5; previous revision: 1.4

Guarantee is a guarantee, promise is a promise. We were ready to resign to it during discussion about it in the past
just for this method call FileUtil.toFileObject and now should have been done. No implication for other methods issuing
FileObject (without explicit promise) from FS API. 

Definitely for usage of FS API is still true (and since ever was):
1/ use FS API whenever possible for creating, deleting file, modifying content of file
2/ if you can't for any reason you must explicitly say it to FS API by calling refresh to sync it (on FS or FO) before
the other code that might rely on your changes will be called. Here I'm going to add helper method
FileUtil.refresh(File... files), that will refresh all files and its children recursively.

In this case seems to me obvious that 1/ and 2/ were not satisfied fully. Definitely my commit fixes this problem.

FYI additional checks, that FS must do to reveal all external changes isn't cheap and approximately the ratio is 100
checks for 1 capture external change (start with 1 opened J2SE project touches uselessly disk approximately > 300 times)

For perf.team - this my commit shouldn't bring any regression in achieved perf. improvement (there was a little
potential but probably not as big to justify broken documented contract)
Comment 8 Jiri Skrivanek 2008-01-16 11:00:54 UTC
Verified.


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