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.
Some attempts to delete folders and files from the Favorites node earlier in the IDE session had failed - selection was cleared but the nodes remained (and the files seemed to still be there on disk). I forgot about it and went to do other stuff. Much later I tried to rename a file in Projects and immediately got a deadlock. Mustang, dev build.
Created attachment 28624 [details] Thread dump
Where is the deadlock? I see none. Can you either: 1. advice where the deadlock is 2. simulate once again with logging enabled ala: -J-Dorg.openide.loaders.DataObjectPool.level=100
Obviously it's a deadlock - EQ is blocked, the IDE was frozen. DataObjectPool.enterRecognition is waiting for something and never notified. I don't know what causes it but clearly under some conditions the DOP synchronization system can fail to unblock. Perhaps some process in another thread (not shown in the thread dump) terminated unexpectedly and failed to notify waiting threads. I guess it should be possible to analyze all code which synchronizes on this monitor and either see the potential problem, or introduce logging which would produce information on what happened, if it happens again. I doubt I can reproduce, sorry. As the first sentence of my original description indicates, probably something went wrong long before the deadlock occurred, leaving the pool blocked, but I have no idea what that might have been.
I agree it is a starvation, but it is not a deadlock. You are right, some thread probably forget to notify, but how am I supposed to know which one? There is a lot of logging around this piece of code, but unless I know more, I doubt I can do anything. PS: The code was carefully reviewed few times already, even by pnejedly, etc.
OK, starvation not deadlock.
So now, when we have agreed that this is starvation and not deadlock, then it should be clear that just a thread dump is not sufficient to describe what went wrong. I agree that something went wrong, but unless I get more info, there is nothing to do about this bug. It is either needed to generate a lot file with failure, or find a reproducible scenario. I understand that none of this is easy, and as such this is a candidate for the never be closed bug. Which is wrong, it is just incomplete report and it does work for me. That is why I am closing it. Feel free to reopen when you have some new info.
OK. Hasn't happened to me again since then so may not be a high priority. Still, if it is possible to trigger proper log messages when this kind of starvation happens, that would be ideal; this doesn't look like the sort of thing that is going to be easily reproduced, but it may be affecting people in the field. Currently there is some logging but it is always off by default, which makes it not very useful - I would want it to notice the starvation and log something about it. In this case it seems that DOP.enterRecognition is called, and calls wait(), but there is no matching notifyAll(). Or Validator.exit() is called and does notify() but there are multiple threads waiting.