On Wed, 11 Aug 2021 at 17:15, Eirik Bakke wrote:
> I experienced some other deadlocks in NetBeans 12.4 before, but only on
> startup. After examining the thread dumps I can't immediately see if they are
> the same bug or not (they could very well be a separate bug). In any case, I
> uploaded th
I experienced some other deadlocks in NetBeans 12.4 before, but only on
startup. After examining the thread dumps I can't immediately see if they are
the same bug or not (they could very well be a separate bug). In any case, I
uploaded those thread dumps here:
https://issues.apache.org/jira/bro
>
> Whenever I see an intermittent bug like this, though, my instinct is to
> avoid changing my configuration, in case the bug stops being reproducible.
> Then I will never know what caused it, or when it will return...
>
Very interesting perspective. Never thought of it like that -- though it
wou
> However, I'm still of the view that trying to reproduce with a non-distro JDK
> build is useful. I've had distro builds that behave differently, crash in
> odd places, and even manage to run more than one EDT at the same time.
Ah, OK. I can see that it would be ideal to see thread dumps with
On Wed, 11 Aug 2021 at 15:09, Eirik Bakke wrote:
>
> But if the problem goes away with a different JDK, that doesn't mean the bug
> is in the JDK--it just means the bug cannot be reproduced.
>
> For example, if two different NetBeans threads acquire nested locks in
> opposite order, that would b
On Wed, 11 Aug 2021 at 14:19, Chris Wareham wrote:
> On this occasion I had just selected New -> Java Class in the Projects
> window. However, on other occasions lockups have occurred when I've just
> hit Ctrl-S to save some changes to a file or I've just left the IDE idle
> for a while.
Thanks.
Sure, true. But surely it would be relevant to know whether JDK choice
makes a difference?
Gj
On Wed, 11 Aug 2021 at 16:09, Eirik Bakke wrote:
> But if the problem goes away with a different JDK, that doesn't mean the
> bug is in the JDK--it just means the bug cannot be reproduced.
>
> For exam
But if the problem goes away with a different JDK, that doesn't mean the bug is
in the JDK--it just means the bug cannot be reproduced.
For example, if two different NetBeans threads acquire nested locks in opposite
order, that would be a deadlock bug--but the actual deadlock would only occur
To exclude it from the equation, especially since the problem can’t be
localized thus far.
Gj
On Wed, 11 Aug 2021 at 15:56, Eirik Bakke wrote:
> Why is it useful to try a different JDK here? See my earlier comment.
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga
> Sent: W
Why is it useful to try a different JDK here? See my earlier comment.
-- Eirik
-Original Message-
From: Geertjan Wielenga
Sent: Wednesday, August 11, 2021 3:29 PM
To: dev@netbeans.apache.org
Subject: Re: How to diagnose lock up with 12.5 Beta 1
Could you, please, see if the problem co
Could you, please, see if the problem continues to occur when you use a few
different JDKs?
Gj
On Wed, 11 Aug 2021 at 15:24, Chris Wareham wrote:
> Hi Geertjan,
>
> None of my projects use Micronaut, they are all Spring Boot based. If I
> do a:
>
> mvn -DincludeScope=runtime dependency:tree
>
>
Hi Geertjan,
None of my projects use Micronaut, they are all Spring Boot based. If I
do a:
mvn -DincludeScope=runtime dependency:tree
Then no Micronaut dependencies are showing up.
Regards,
Chris
On 11/08/2021 12:13, Geertjan Wielenga wrote:
Looks like you’re doing something with Micronau
On 11/08/2021 12:07, Neil C Smith wrote:
On Wed, 11 Aug 2021 at 11:28, Chris Wareham wrote:
OK, I've just had another lock up. I wasn't able to get a thread dump
with jstack, even using the -F flag, but succeeded with VisualVM. I've
created a Jira issue and attached both the thread dump and lo
java -XshowSettings 2>&1 | grep " os."
os.arch = x86_64
os.name = Mac OS X
os.version = 11.5.1
java -version
openjdk version "17" 2021-09-14
OpenJDK Runtime Environment (build 17+35-2724)
OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing)
uname -a
Darwin dev-mac 20.6.
On Wed, 11 Aug 2021 at 12:13, Geertjan Wielenga
wrote:
> Looks like you’re doing something with Micronaut?
I think that will run whenever the module is enabled, so whenever the
enterprise cluster is active? Looking at the dump, the EDT appears to
be waiting on the Editor Parsing Loop, and that i
Looks like you’re doing something with Micronaut?
Gj
On Wed, 11 Aug 2021 at 13:08, Neil C Smith wrote:
> On Wed, 11 Aug 2021 at 11:28, Chris Wareham
> wrote:
> >
> > OK, I've just had another lock up. I wasn't able to get a thread dump
> > with jstack, even using the -F flag, but succeeded wit
On Wed, 11 Aug 2021 at 11:28, Chris Wareham wrote:
>
> OK, I've just had another lock up. I wasn't able to get a thread dump
> with jstack, even using the -F flag, but succeeded with VisualVM. I've
> created a Jira issue and attached both the thread dump and log file to it:
>
> https://issues.apac
Can you try with a different JDK to see if that makes a difference — just
to exclude that possibility?
Gj
On Wed, 11 Aug 2021 at 12:28, Chris Wareham wrote:
> OK, I've just had another lock up. I wasn't able to get a thread dump
> with jstack, even using the -F flag, but succeeded with VisualV
OK, I've just had another lock up. I wasn't able to get a thread dump
with jstack, even using the -F flag, but succeeded with VisualVM. I've
created a Jira issue and attached both the thread dump and log file to it:
https://issues.apache.org/jira/browse/NETBEANS-5913
Chris
On 09/08/2021 12:01
19 matches
Mail list logo
