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.
All I did was the following in the netbeans.conf file: # Default location of JDK, can be overridden by using --jdkhome <dir>: #netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_10" netbeans_jdkhome="C:\Program Files\Java\jdk1.5.0_16" It would hang at the splash screen after loading all modules ("Done loading modules"). I switched it back: # Default location of JDK, can be overridden by using --jdkhome <dir>: netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_10" #netbeans_jdkhome="C:\Program Files\Java\jdk1.5.0_16" Same problem.
Created attachment 72639 [details] Attaching messages.log
Created attachment 72641 [details] Attaching thread dump
reassign to window system for evaluation
from thread-dump it looks like the IDE is still parsing some jsp ....
frankioski, the problem is probably caused by some web project which is opened at the IDE startup. Would it be possible to attach this project for evaluation of this issue?
Can you please try it with fresh userdir? You can specify the new location for the userdir via the --userdir <path> option when starting NetBeans.
Marku, can you please take a look at this P1? (Tomas M is on vacation.) I know you were looking at the threading issues in JSP parser before. Thanks.
I am not sure whether "Init TldLocationCache" thread shown in RUNNABLE state really does something or is blocked on IO operation at java.io.WinNTFileSystem.getBooleanAttributes(Native Method). If it isn't this could mean that there is a lots of jar files on the project classpath so it takes some time to parse them. If it is blocked on the IO there might be some problem with locking files on windows. I remember Petr Hejl did some fixes in this are during 6.5 cycle, he can comment on that. This issue isn't related to jsp editor is very different from those I was solving/workarounding recently. Petr Hejl, can you please take a look at it and if you recognize the situation as a symptom of the problem you fixed in the files locking, close this as already fixed? If not feel free to reassign back to me. Thanks, Marek
BTW, frankioski, what is exactly going on when the ide 'hangs'? Is the CPU loaded by the java process or not? If so can you try to take a few threaddumps in a row and attach them here? Thank you in advance.
It doesn't seem to be related to locking so far. What I tried to address in locking issue was just files locked by parser which can't be deleted until the IDE was finished (anyway windows allows to read and even to overwrite to such files - problem was just the deletion). While looking into thread dump it could be caused by some issue in filesystem. All threads seems to be doing what they are supposed to do... Reporter can you provide multiple thread dumps for the "hanged" state. Can you provide your project for testing? If not can you provide at least your configuration? Any other not-so-typical things in project configuration (such as project in root folder, many libraries in WEB-INF, anything similar)?
Also, can you please try whether this is also a problem in NetBeans 6.5 RC2 ? It is possible that this was fixed between 6.1 and now. Thanks.
I tried attaching the projects and the userdir, but they are > 1 MB. One of them is 376 MB. How are we going to do this?
Reporter, can you provide multiple thread dumps for the "hanged" state? These could show us what's happening. I suppose the big one is the userdir... Can you send your project (without userdir) to Marek.Fukala at sun.com or Petr.Hejl at sun.com?
Created attachment 73146 [details] Screen cap of splash screen where NB freezes
frankioski, please make more threaddumps during the ide 'hang' like you did for the first time and attach them here. Thanks.
Created attachment 73246 [details] thread dump 2
Created attachment 73249 [details] thread dump 3. This dump and thread dump 2 are from the same attempt at starting up NB; I did not restart NB in between these two dumps, which took place 6 minutes apart. NB actually unfroze and opened up to the editor while I was getting this thread du
Created attachment 73250 [details] thread dump 4. This is from a fresh restart of NB.
Created attachment 73252 [details] thread dump 5. This was taken from the same start-up of thread dump 4, 4 minutes apart. 5 minutes after getting this thread dump, NB unfroze and opened up to the editor. Again, total time to start up was about 10 minutes or so.
The adaptj stack trace tool had license problems yesterday, but it is working today, so I got the thread dumps. The 376 MB zip is actually one of the projects. The userdir zip is about 22 MB. I noticed that NB would not freeze if I start with a fresh userdir.
Please be advised that I've sent Marek and Peter the code and the userdir in 3 ZIP files (in 3 separate emails).
It turns out that the ZIP files was not sent out by the mail client. I'm guessing the reason was due to the large file size. I don't know how to go about this.
There code waits on some IO operations in the threaddumps from various places. I belive there isn't any deadlock in terms of thread waiting on each other. It looks like the project size causes the sloweness. frankioski, did you try to wait for some time if the ide 'resumes'?
Looks like too big project for NetBeans to handle.
mfukala, like I stated in the attachment descriptions, I had to wait 10 minutes for NB to unfreeze (or resume).
phejl, I've always had those projects opened in the IDE. Both at the same time. I've done it this way since NB 6.0 at the start of this year. Why no problem then? Why is the problem suddenly appearing now?
I have asked the reporter to share the project somehow so we are able to download and reproduce. Waiting for reporters action for now...
Marek and Petr, Please be advised that I've sent you an email with instructions on where and how to download the three ZIP files. Thanks.
I cannot reproduce the problem with the sent project on latest 7.0 build. What I did: 1) run nb with new userdir 2) opened the project 3) resolved all the libraries 4) did some edits 5) restarted netbeans 6) opened some files Everything worked smoothly without any significant delays. May be windows specific. jsedek, can you please test on windows xp? Anyway this issue belongs to jsp parser or project owner, reassigning. Whoever needs the reporter's project or userdir ask me. The project is confidental, so we are not allowed to publish it anywhere!!!
To Jindra: please, try to reproduce the problem on WinXP as Marek wrote in one of his latest comments. Thanks a lot. To Marek: I need the project please. Thanks. To frankioski: Is this issue reproducible for you on NetBeans 6.5? If I understand correctly, everything worked as expected but after the change of JDK, this problem appeared - right? It would be useful to know what exactly could cause this issue to happen. Do you use subversion for your project? Where's your project located - local or a remote drive? Could you please try to start NetBeans (with the original userdir) with "-J-Dorg.netbeans.modules.web.jspparser_ext.WebAppParseSupport.level=500" and then attach messages.log (located in <nb_userdir>/var/log/messages.log)? Thanks.
To frankioski: One more note - we have these files: 19M Test.zip 23M userdir.zip If we miss some other files, please, let us know. Thanks.
Created attachment 74785 [details] I've open the project with the users userdir, added some libraries and tried to open _???.jsp file in 6.1. The deadlock happened.
Created attachment 74786 [details] the same scenario with latest daily trunk build
Created attachment 74790 [details] I've switched from jdk1.5 to jdk1.6 few times based on user suggestion at the beginning of this issue and there is some suspicious logging from jsp parser classloaders, but no deadlock has happened
after discusion with Marek and Tomas we agreed that both deadlocks are unrelated to the reporter's problem - the thread dumps are different, I've created new issues for it see issue 155114 and issue 155116
To "some suspicious logging from jsp parser classloaders" - this comes directly from JDK 6, it's a reported bug (discovered by Petr Hejl during fixing classloader locking). Jindro, thanks for investigation.
Frankioski, I played with your project for a while and I noticed that its setup is probably not correct (you have several Java sources - one folder underneath Web pages directory as well as the whole project) - of course, it should not have any impact on this issue, but - any reason for using Web Freeform project instead of standard IDE project? Standard IDE project would help you a lot with setting Web pages and WEB-INF folders, Java and Test sources, actions like Run project, Debug project etc. Anyway, like Marek, I'm not able to reproduce your issue in development version of NetBeans, it works as expected. I tried to switch JDKs several times but no problem appeared. Could you please try to reproduce this issue in the NB 6.5 FCS? Thanks a lot. BTW you wrote that one of the archive file has 376 MB - typo? Product Version: NetBeans IDE Dev (Build 081209) Java: 1.5.0_17; Java HotSpot(TM) Client VM 1.5.0_17-b04 Java: 1.6.0_11; Java HotSpot(TM) Client VM 11.0-b16 System: Linux version 2.6.27-gentoo-r5 running on i386; UTF-8; cs_CZ (nb)
> I'm not able to reproduce your issue in development version of NetBeans Adding the NO70 keyword.
Marking as INCOMPLETE because reporter did not respond for a long time. Lowering to P2 because we are not able to reproduce this issue (as well as reporter with a clean userdir) and it seems that this issue has no duplicates.
*** Issue 157512 has been marked as a duplicate of this issue. ***
update no67 keyword
No response from user for a long time and we are not able to reproduce with user's data or clean userdir so closing as WORKSFORME. Feel free to reopen if the problem still exists and please, follow description #38. Thanks for reporting. BTW I think that this issue is related to issue #156459 - the same reporter and very similar thread dumps, method calls end: at java.io.WinNTFileSystem.getBooleanAttributes(Native Method)