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.
Created attachment 132984 [details] messages.log NetBeans just died while editing a JSP file. Attached: messages.log, thread dump.
Created attachment 132985 [details] thread dump
NetBeans DEV201303222300
After freeze, netbeans64.exe process is taking 03% of constant CPU usage. Screenshot shows only black screen.
Created attachment 132993 [details] Process in task manager.
Is there any way to reproduce this? There is no explicit deadlock in threaddump.
Also multiple thread dumps could help.
I don't have steps to reproduce. I just happened twice last week with two different versions (201303222300 and 201303282300). I know random bugs are hard to fix. The bug is there, and I'll try to catch it. Next time, I'll get new thread dumps and provide here.
I still do not see the clear deadlock. It might be doc write lock and awt. JspDefaultKeyTypedAction might be guilty though I'm not sure whether rewrite to typing hooks would help. Marku, have you seen anything similar?
I also think the problem is only in trunk and may have appeared due to this change (seems to be ok on its own): http://hg.netbeans.org/web-main/rev/a5f9f2b8175b
I have randomly reproduced similar deadlock while saving tag file on exit. Attaching thread dumps.
Created attachment 133367 [details] thread dump 1
Created attachment 133368 [details] thread dump 2
I must admit I've not idea either what is the real cuplrit: Here are the involved threads: Editor Parsing Loop: +holds parsing lock, -> runs JspSourceTask-> document.writeLock() -> WAITS EDT: -seems not to hold any of the locks others waits for ->runs JspDefaultKeyTypedAction -> document.writeLock() -> WAITS AnnotationsHighlighting: +hold document readlock (doc.render()) -> runs AnnotationsHighlighting$R.refreshAllLines() -> BaseDocument.render -> editor.lib2.view.DocumentView.lock -> PriorityMutex.lock -> WAITS ViewHierarchy-Region-Rebuilding: +holds doucment readlock (doc.render()) -> runs DocumentViewOp.viewsRebuildOrMarkInvalid -> BaseDocument.render -> DocumentView.lock -> PriorityMutex.lock -> WAITS 1) It is not clear to me who owns the PriorityMutex in DocumentView.lock() - I believe Mila can help with that. 2) I'm not sure whether doing atomic lock under parsing lock is a good idea, I may possibly put the write lock out of the thread, but it doesn't seem to me that this is the cause of the issue. So lets start with Mila looking at the #1 issue and then if nothing is spot to be wrong here I'll proceed with #2 or some other fix.
As for the subsequent locks (comment #11...) - they don't seem to be related to the first problem reported by ecerichter
It's unclear what's holding PriorityMutex. I've inspected code of org.netbeans.editor.BaseKit$DefaultKeyTypedAction.actionPerformed(BaseKit.java:1125) org.netbeans.editor.ext.ExtKit$ExtDefaultKeyTypedAction.actionPerformed(ExtKit.java:1022) org.netbeans.modules.web.core.syntax.JspKit$JspDefaultKeyTypedAction.actionPerformed(JspKit.java:516) but there does not seem to be any culprit. Since the PriorityMutex is shared between view hierarchy and folds adding Svata to cc if he would have any idea. If this would be reproducible I could add a code to PriorityMutex that would dump a thread that holds the lock after certain amount of time so that we could at least find the thread that holds the PM's lock.
(In reply to comment #15) > If this would be reproducible I could add a code to PriorityMutex that would > dump a thread that holds the lock after certain amount of time so that we could > at least find the thread that holds the PM's lock. Milo, can you add that code anyway? Sooner or later we might hit the deadlock.
Thanks - I've found one place in CSL where the lock was not released. The change was 2201d4aea94e, 12th Mar 2013. It should happen when e.g. editor window close happens very soon after a typing change (folding update terminated) - this may include e.g. transient windows like Fold or brace popup, or a cloned window. The web.core.syntax modules uses CSL for folding, so I it could trigger during editing.
Note that Folding API exposes the Mutex to its clients (FoldHierachy.lock/unlock). The logging code suggested by Mila in comment #15 is still a good idea if the mutex can be locked (and not released) by any folding client. I also add logging to the lock/unlock operations.
Fixed in http://hg.netbeans.org/jet-main/rev/070696624fa9
Ok, I've added an extra logging into PriorityMutex (which waits for 5 unsuccessful waits (with 2000ms timeout) in a row without acquiring the lock). Usage: Just determine which thread holds the lock: -J-Dorg.netbeans.lib.editor.util.PriorityMutex.level=FINE Determine stack trace of the locker thread's PriorityMutex.lock() call: -J-Dorg.netbeans.lib.editor.util.PriorityMutex.level=FINER http://hg.netbeans.org/jet-main/rev/19f6f91af364
Integrated into 'main-golden', will be available in build *201304172301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/070696624fa9 User: Svata Dedic <sdedic@netbeans.org> Log: #227859: released fold hierarchy lock, logging changed / added.