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.
Product Version = NetBeans IDE 8.1 RC2 (Build 201510122201) Operating System = Linux version 3.13.0-66-generic running on amd64 Java; VM; Vendor = 1.8.0_51 Runtime = Java HotSpot(TM) 64-Bit Server VM 25.51-b03 Reproducibility: Happens sometimes, but not always Netbeans completely hung up while editing a javascript file. Stack trace, log file and screen shot of where I was editing coming shortly. Referring to the screen shot: I had just pasted in the highlighted text, replacing what was there and then double clicked on the "true" that is still selected. The symptoms of this feel a lot like 252781, but I'm creating a new bug for the 8.1 RC and the stack trace looks a bit different (to me)
Created attachment 156856 [details] Log file
Created attachment 156857 [details] Stack trace
Created attachment 156858 [details] Screen shot
This happened twice in a row at the exact same place and actions in the editor, so it may be repeatable. I'll save a copy of the file as is, then try some different tactics to get my work done.
Wow - this is really broken! It locked up again just deleting some characters in the same spot. I'm attaching another stack track, log and screen shot and changing to P1. Ref the screen shot. I had just backspace deleted a few characters where you can see the cursor.
Created attachment 156859 [details] log file 2
Created attachment 156860 [details] stack trace 2
Created attachment 156861 [details] screen shot 2
Reassigned for further evaluation.
If you are able to reproduce, could you please provide test case? It would be helpful. Thanks
One more question. What exactly means that NetBeans hang up? Is the processor of your machine consumed or does nothing? Could you try to create profiling snapshot?
I cannot reproduce the problem this morning, but last night it was so bad that I had to switch back to 8.0.2 to get my work done.
"hung up" meaning that the IDE was completely unresponsive to any mouse or keyboard activity, in any part of the NB window, as if the EDT was deadlocked. There was not high resource usage.
There is not any useful information in the stacktraces. We need more data. I'm marking this issue as incomplete. Please reopen, if you are still able to reproduce and it would be great, if you could provide more information, how to reproduce. Could you attach the file, where it happens?
This continues to happen to me, so I'm reopening this issue at P2. I realize how difficult it is to troubleshoot a problem when you can't reliably reproduce it (I AM a developer myself), but there is something broken here somewhere. I'm attaching stack trace and message log from another occurrence.
Created attachment 156951 [details] IDE log from today's occurrence
Created attachment 156952 [details] Stack trace from today's occurrence
All the stacktraces looks similar. The AWT is trying to render the document. Reassigning to Mila, we talked about this. Milo, please try to evaluate, what is happening.
(In reply to mclaborn from comment #17) > Created attachment 156952 [details] > Stack trace from today's occurrence There's let's say a suspicious thread being in notify() - was the CPU usage of the java process close to 0% (e.g. in 'top' program)? Anyway I've made a JDK patch to diagnose pending document lock threads. It's described at http://wiki.netbeans.org/EditorShowDocumentLockingThreads could you please run the IDE with and once the problem happens again could you please attach its output to the issue? Thanks.
I don't remember seeing any high CPU usage, but can't say if it was really low. I've put in the patch jar for my 8.1 RC2 installation and verified that the starting logging message is present. Will post here next time I hit the problem.
Created attachment 157279 [details] message log for today's failure, with the document patch turned on I finally captured another occurrence of this. Message log is attached with document patch output in it. Will attach stack trace shortly.
Created attachment 157280 [details] stack trace to match message log just attached
(In reply to mclaborn from comment #22) > Created attachment 157280 [details] > stack trace to match message log just attached Thanks for the attachments it's again strange. I assume that there was no CPU activity at the time the snapshot was taken?? May I ask you to take two snapshots (after few seconds) when the problem happens? That way there would be a higher probability that if the the threads stepped into a different state we would notice it. 7333f56f0 document - it's write locked and reported by the patch. It's important whether there was any CPU activity or not because if there would be many o.o.text.Line instances (breakpoints,bookmarks etc.) for the document this could be a normal state assuming the CPU was processing them. 7313d3748 document - there seems to be no locker - the patch does not report it. I have to improve the patch to cover this case as well. Hopefully after one more iteration we should be able to tell precisely what's wrong. Thanks.
There was not high CPU, but can't say for certain there was "no cpu". I'll examine CPU usage more closely next time. "May I ask you to take two snapshots (after few seconds) when the problem happens?" Do you mean stack traces or the built-in NB self-profiler? The self-profiler won't work, as the entire UI portion of NB is locked when this happens, so I have no way to turn it on. Stack traces is no problem.
> "May I ask you to take two snapshots (after few seconds) when the problem > happens?" > > Do you mean stack traces or the built-in NB self-profiler? The self-profiler > won't work, as the entire UI portion of NB is locked when this happens, so I > have no way to turn it on. Stack traces is no problem. I've meant full thread dumps i.e. please either press Ctrl+\ in console or use kill -QUIT <NB-IDE-process-number> You may want to run "jps" to only show java processes. Thanks.
I've been using jps and jstack. Is that sufficient, or should I use kill -QUIT <NB-IDE-process-number> instead?
(In reply to mclaborn from comment #26) > I've been using jps and jstack. Is that sufficient, or should I use > > kill -QUIT <NB-IDE-process-number> > > instead? No, jstack is fine.
I've improved the patch to better monitor threads that did not acquire the lock yet. The patch is now version 1.1 - it should now output "AbstractDocument-read/write logging v1.1 started". The download URLs are the same - links are in http://wiki.netbeans.org/EditorShowDocumentLockingThreads Could you please run with the new version of the patch and if the problem happens please check the CPU activity and attach the output to the issue? Thanks in advance.
I've installed the updated patch and verified the startup message in the log. This seems to happen most when I'm editing in Javascript. It may be a couple of weeks before I do much in Javascript again.
Here is stack trace and message.log from another occurrence. There IS high CPU usage from the NetBeans task.
Created attachment 157582 [details] Stack trace from today's occurrence
Created attachment 157583 [details] Message log from today's occurrence This occurrence - pasted a block of Java code into a normal Java class.
Not sure if it matters: In the file I was working in, I noticed bookmark problems very similar to 256154. Going to a bookmark landed several lines before the actual bookmark icon.
(In reply to mclaborn from comment #32) > Created attachment 157583 [details] > Message log from today's occurrence > > This occurrence - pasted a block of Java code into a normal Java class. Unfortunately the attached messages.log seems to be truncated - it's missing the begining of the output of the patch. Could you please attach the full output of the patch? Thanks.
Sorry - I no longer have that log file. I was out of the office last week so didn't have any backups of that directory. I'm in the office this week and will be coding quite a bit, so I may see this again.
Created attachment 157993 [details] messages log from today I think this is an occurrence of this problem. I was editing in a JSP file and NB got very, very slow, but not completely locked up. CPU usage was very high. Attached is the messages log and a stack trace.
Created attachment 157994 [details] stack trace from today
The records in the log file do not indicate a threading problem but they show a heavy processing of annotations so it's likely there's a high number of annotations (such as breakpoints or bookmarks) and o.o.text.Line objects for some reason. I've added some more debugs into LineVector in http://hg.netbeans.org/jet-main/rev/5dcee0855eb5
Integrated into 'main-silver', will be available in build *201601270002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/5dcee0855eb5 User: Miloslav Metelka <mmetelka@netbeans.org> Log: #256062 - NetBeans completely hung up - improved logging in LineVector.
Is this problem still happening? If so are there any steps to reproduce?
I have not seen this one in some time. I think it is safe to close it.
Hi there. I updated a few weeks ago my Windows 7 to Windows 10 and I am having the same issue as described here and in the issue #216280 (Typing lag and delays while writing code). To reproduce the error: 1) Create a new Java Project 2) Create a new Class 3) Insert the code below public String whats_Your_Name() { String p = return "I have many names and types"; } 4) Select / Mark the text "I have many names and types" 5) Press quickly CTRL+X , UP Arrow, End, asd 6) Finish. You should notice that Netbeans needs 1000 ms or more to write asd in line above where the cursor was before. The result is: public String whats_Your_Name() { String p = asd return ; }
(In reply to jocafi from comment #42) > Hi there. I updated a few weeks ago my Windows 7 to Windows 10 and I am > having the same issue as described here and in the issue #216280 (Typing lag > and delays while writing code). Does it mean that the problem started after the Win7 -> Win10 upgrade on the same NB installation (same build)? Btw I was not able reproduce the problem according to the given steps but I'm on Ubuntu 15.04. The issue #216280 is already fixed so I would suggest to file a new issue for this particular problem. Please describe if (besides OS upgrade) there weren't e.g. any other HW changes that might influence the problem. Thanks. Considering reply from mclaborn I mark this issue as fixed.