This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Some UI deadlock | ||
|---|---|---|---|
| Product: | apisupport | Reporter: | Jan Jancura <jjancura> |
| Component: | Project | Assignee: | Tomas Zezula <tzezula> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | CC: | rmatous |
| Priority: | P1 | ||
| Version: | 4.x | ||
| Hardware: | PC | ||
| OS: | Windows ME/2000 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | Deadlock | ||
|
Description
Jan Jancura
2004-08-19 08:35:15 UTC
Created attachment 16934 [details]
Deadlock
Honzi, thanks for your exhaustive and comprehensive report :). But I
don't see any deadlock.
I only see, that all thread dumps shows the same thing: Scanning Queue
is blocked by same native method:
"Scanning Queue" daemon prio=2 tid=0x0eed1db0 nid=0xd54 runnable
[f63f000..f63fd8c]
at java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
at java.io.File.exists(File.java:680)
at
org.netbeans.modules.masterfs.SpecialDelegates.checkValidWindowsDrive(SpecialDelegates.java:146)
Radku, can you evaluate it? Thanks
I think I know where the problem is. I am working on it. Radku, please ignore this. So, I debugged this on Jan's computer and found out the problem is that the URL of a classpath root provided from classpath is: "jar:file:/c:/j2sdk1.4.2_03/lib/tools.jar!/" while URL provided from the filesystem on a given root fileobject is: "jar:file:/C:/j2sdk1.4.2_03/lib/tools.jar!/" So, these URLs are not equal, thus scanning gets into an endless loop trying to resolve the root provided by the classpath. I talked to Tomas Zezula and he knows how to fixe it. Since this needs to be fixed in classpath implementation, I am reassigning it to him. To Trung: this is not a threading issue - it is not a deadlock but rather an endless loop caused by different URLs returned for the same file on Windows. On Jan's computer it happens deterministically. It is because how his JDK_HOME variable is set (since classpath seems to create URL pointing to JDK from this environment variable). I don't know what the THREAD keyword means, but are you sure it is appropriate for this issue? Checking in project/src/org/netbeans/modules/apisupport/project/ClassPathProviderImpl.java; /cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/ClassPathProviderImpl.java,v <-- ClassPathProviderImpl.java new revision: 1.35; previous revision: 1.34 done *** Issue 49256 has been marked as a duplicate of this issue. *** presumably fixed, no way how to verify, closing. |