You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by frederic <fr...@ancestris.org> on 2018/05/01 11:24:43 UTC
Bug in Netbeans for MacOS
Dear all,
I have found a bug in Netbeans on MacOS which makes the applications
crash on MacOS. I would like to know if it is possible to fix it in
Netbeans 8.0.1 or at least to make sure it is not in Netbeans 8.2.
The bug :
======
I'm using Netbeans 8.0.1 for Ancestris. There seems to be a conflicting
thread in MainWindow.java that compromises the removal of lookup
listeners.
Therefore, if an updateLookup runs in the application, the following
thread is activated which itself runs an updateLookup.
The application ends up multiplying the number of listeners up to
several tens of thousands and crashes on Mac.
Here is the code with the bug: (in MainWindow.java in package
org.netbeans.core.windows.view.ui)
if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
//Show a "save dot" in the close button if a modified file
is
//being edited
//Show the icon of the edited file in the window titlebar
like
//other mac apps
saveResult = Utilities.actionsGlobalContext().lookupResult
(SaveCookie.class);
dobResult = Utilities.actionsGlobalContext().lookupResult
(DataObject.class);
if( null != saveResult && null != dobResult ) {
saveListener = new LookupListener() {
@Override
public void resultChanged(final LookupEvent ev) {
RP.post( new Runnable() {
@Override
public void run() {
updateMacDocumentProperties(ev);
}
});
}
};
saveResult.addLookupListener(saveListener);
dobResult.addLookupListener(saveListener);
}
dobResult.allItems();
}
The " updateMacDocumentProperties(ev)" includes :
- saveResult.allItems()
- dobResult.allItems()
which trigger an updateLookup as well, creating two threads updating
the same lookups (removeListener, addListener).
The fix:
=====
I would be ok to just replace :
"Utilities.getOperatingSystem() == Utilities.OS_MAC"
with
"Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
because I do not think we need this on Mac in the Ancestris application
at least.
Can someone recompile the package with this fix and send it back to me
? Or else can someone help me fix it myself localy (I do not have the
code to recompile this package) ?
Many thanks in advance if it can be done.
Best regards,
Frederic
Re: Bug in Netbeans for MacOS
Posted by Emilian Bold <em...@protonmail.ch>.
Thanks for investigating this.
Please move the discussion over to dev@ as it seems a problem with NetBeans Platform itself and more NetBeans developers will be on dev@ than users@.
It's unclear to me why the application crashes. Clearly we would have learned about it so far, NetBeans does have some users on macOS and I've been using NetBeans on Mac exclusively for ages.
So... there must be something about how your code behaves too.
Could you report the issue on JIRA (on https://issues.apache.org/jira/projects/NETBEANS/issues ) and also make a small module/class reproducing the bug and attach it to the issue?
PS: Not sure what you mean about recompiling the package. If the fix will get added it will be part of the next Apache release. If you need commercial help, it is available from a few people https://netbeans.apache.org/help/commercial-support.html , including me.
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 1 May 2018 2:24 PM, frederic <fr...@ancestris.org> wrote:
> Dear all,
>
> I have found a bug in Netbeans on MacOS which makes the applications crash on MacOS. I would like to know if it is possible to fix it in Netbeans 8.0.1 or at least to make sure it is not in Netbeans 8.2.
>
> The bug :
>
> ======
>
> I'm using Netbeans 8.0.1 for Ancestris. There seems to be a conflicting thread in MainWindow.java that compromises the removal of lookup listeners.
>
> Therefore, if an updateLookup runs in the application, the following thread is activated which itself runs an updateLookup.
>
> The application ends up multiplying the number of listeners up to several tens of thousands and crashes on Mac.
>
> Here is the code with the bug: (in MainWindow.java in package org.netbeans.core.windows.view.ui)
>
> if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
>
> //Show a "save dot" in the close button if a modified file is
>
> //being edited
>
> //Show the icon of the edited file in the window titlebar like
>
> //other mac apps
>
> saveResult = Utilities.actionsGlobalContext().lookupResult (SaveCookie.class);
>
> dobResult = Utilities.actionsGlobalContext().lookupResult (DataObject.class);
>
> if( null != saveResult && null != dobResult ) {
>
> saveListener = new LookupListener() {
>
> @Override
>
> public void resultChanged(final LookupEvent ev) {
>
> RP.post( new Runnable() {
>
> @Override
>
> public void run() {
>
> updateMacDocumentProperties(ev);
>
> }
>
> });
>
> }
>
> };
>
> saveResult.addLookupListener(saveListener);
>
> dobResult.addLookupListener(saveListener);
>
> }
>
> dobResult.allItems();
>
> }
>
> The " updateMacDocumentProperties(ev)" includes :
>
> - saveResult.allItems()
>
> - dobResult.allItems()
>
> which trigger an updateLookup as well, creating two threads updating the same lookups (removeListener, addListener).
>
> The fix:
>
> =====
>
> I would be ok to just replace :
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC"
>
> with
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
>
> because I do not think we need this on Mac in the Ancestris application at least.
>
> Can someone recompile the package with this fix and send it back to me ? Or else can someone help me fix it myself localy (I do not have the code to recompile this package) ?
>
> Many thanks in advance if it can be done.
>
> Best regards,
>
> Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Bug in Netbeans for MacOS
Posted by Geertjan Wielenga <ge...@googlemail.com>.
It sounds like you should be using a LookupListener to listen for the
selected Node, see leanpub.com/nbp4beginners.
I don't think I've ever used setSelectedNodes and not needed it either.
I'd be very very careful about adding code into MainWindow.java, i.e., you
could end up changing behavior for all the applications that run on top of
the NetBeans Platform.
Gj
On Tue, May 1, 2018 at 5:54 PM, frederic <fr...@ancestris.org> wrote:
> Geertjan,
>
> Thanks for your message.
>
> (I have moved this discussion to dev@).
>
> To respond to your question, I want to let all the TopComponents of the
> application know that the selection in one module has changed. The use of
> an ExplorerManager in all top components and setSelectedNodes sounded like
> an easy and legitimate way. If there is another way, happy to be pointed to
> the right direction.
>
> In any case, the specific added code for MacOS in MainWindow.java prevents
> numerous calls of setSelectedNodes. Whether I find another solution for my
> application, it might still be necessary to fix it, doesn't it ?
>
> Best regards,
> Frederic
>
>
> Le mardi 01 mai 2018 à 17:40 +0200, Geertjan Wielenga a écrit :
>
>
>
> On Tue, May 1, 2018 at 5:33 PM, frederic <fr...@ancestris.org> wrote:
>
> Hi Efrem, Thomas,
>
> Thanks for you replies.
>
> The application is Ancestris, but it does not matter much which
> application is running netbeans. I have spent quite ssome time finding the
> bug. The crash is generated after several calls to
> "ExplorerManager.setRootContext()" or "ExplorerManager.setSelectedNodes()".
> After about 20 to 100 calls, it creates the bug.
>
> What I am trying to do:
> - I have a TopComponent with a simple ExplorerManager in it, which holds
> the context. (associateLookup(ExplorerUtils.createLookup(manager, map));)
> - Each time the user changes the selected element, I run an
> ExplorerManager.setRootContext() and ExplorerManager.setSelectedNodes().
>
>
>
> But why do you need to do that? That seems to be causing some kind of race
> condition or blocker of some kind and you probably need to solve whatever
> the situation is in a different way.
>
> Gj
>
>
>
>
>
> - On Linux, no problem for any number of changes
> - On MacOS, computer slows down after about 20 to 100 selections, Then it
> crashes.
>
> I have checked the source code of MainWindow.java in
> package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and 8.2 :
> they all have the same code, therefore the same bug.
>
> If you want to check on 9.0, just check the MainWindow code. Can you show
> it to us please, see if it has the same call under resultChanged() ?
>
> (Otherwise, not sure we can test with my application on 9.0, it has not
> been converted yet to NB9.0.)
>
> Tom, if I cannot have support on 8.0.1, maybe I can get support on 8.2 ?
> Or else, can I get someone to tell me how to recompile the following jar :
> "org.netbeans.core.windows.jar" ?
>
> Hope this adds more explanations.
>
> Many thanks again.
> Frederic
>
>
>
> Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
>
> Hi my name is Efrem. I am willing to test this with the new beta
> release of NB 9.0 on MacOS.
>
> I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen because
> of its age...
>
> If you can provide me the steps or source to test I am willing to test
> it today.
>
> What is the application and what are you trying to do?
>
> Please advise.
>
> Efrem McCrimon
> GUI Builder Tribe tester
> DB Tribe tester
>
>
>
> On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org> wrote:
>
>
> Dear all,
>
> I have found a bug in Netbeans on MacOS which makes the applications crash
> on MacOS. I would like to know if it is possible to fix it in Netbeans 8.0.1
> or at least to make sure it is not in Netbeans 8.2.
>
> The bug :
> ======
>
> I'm using Netbeans 8.0.1 for Ancestris. There seems to be a conflicting
> thread in MainWindow.java that compromises the removal of lookup listeners.
>
> Therefore, if an updateLookup runs in the application, the following thread
> is activated which itself runs an updateLookup.
>
> The application ends up multiplying the number of listeners up to several
> tens of thousands and crashes on Mac.
>
> Here is the code with the bug: (in MainWindow.java in package
> org.netbeans.core.windows.view.ui)
>
> if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
> //Show a "save dot" in the close button if a modified file is
> //being edited
> //Show the icon of the edited file in the window titlebar like
> //other mac apps
> saveResult = Utilities.actionsGlobalContext().lookupResult
> (SaveCookie.class);
> dobResult = Utilities.actionsGlobalContext().lookupResult
> (DataObject.class);
> if( null != saveResult && null != dobResult ) {
> saveListener = new LookupListener() {
> @Override
> public void resultChanged(final LookupEvent ev) {
> RP.post( new Runnable() {
>
> @Override
> public void run() {
> updateMacDocumentProperties(ev);
> }
> });
> }
>
> };
> saveResult.addLookupListener(saveListener);
> dobResult.addLookupListener(saveListener);
> }
> dobResult.allItems();
> }
>
> The " updateMacDocumentProperties(ev)" includes :
> - saveResult.allItems()
> - dobResult.allItems()
> which trigger an updateLookup as well, creating two threads updating the
> same lookups (removeListener, addListener).
>
>
> The fix:
> =====
>
> I would be ok to just replace :
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC"
>
> with
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
>
> because I do not think we need this on Mac in the Ancestris application at
> least.
>
> Can someone recompile the package with this fix and send it back to me ? Or
> else can someone help me fix it myself localy (I do not have the code to
> recompile this package) ?
>
>
> Many thanks in advance if it can be done.
>
> Best regards,
> Frederic
>
>
>
>
Re: Bug in Netbeans for MacOS
Posted by frederic <fr...@ancestris.org>.
Geertjan,
Thanks for your message.
(I have moved this discussion to dev@).
To respond to your question, I want to let all the TopComponents of the
application know that the selection in one module has changed. The use
of an ExplorerManager in all top components and setSelectedNodes
sounded like an easy and legitimate way. If there is another way, happy
to be pointed to the right direction.
In any case, the specific added code for MacOS in MainWindow.java
prevents numerous calls of setSelectedNodes. Whether I find another
solution for my application, it might still be necessary to fix it,
doesn't it ?
Best regards,Frederic
Le mardi 01 mai 2018 à 17:40 +0200, Geertjan Wielenga a écrit :
> On Tue, May 1, 2018 at 5:33 PM, frederic <fr...@ancestris.org>
> wrote:
> > Hi Efrem, Thomas,
> >
> > Thanks for you replies.
> >
> > The application is Ancestris, but it does not matter much which
> > application is running netbeans. I have spent quite ssome time
> > finding the bug. The crash is generated after several calls to
> > "ExplorerManager.setRootContext()" or
> > "ExplorerManager.setSelectedNodes()". After about 20 to 100 calls,
> > it creates the bug.
> >
> > What I am trying to do:
> > - I have a TopComponent with a simple ExplorerManager in it, which
> > holds the context.
> > (associateLookup(ExplorerUtils.createLookup(manager, map));)
> > - Each time the user changes the selected element, I run an
> > ExplorerManager.setRootContext() and
> > ExplorerManager.setSelectedNodes().
>
> But why do you need to do that? That seems to be causing some kind of
> race condition or blocker of some kind and you probably need to solve
> whatever the situation is in a different way.
> Gj
>
>
>
> > - On Linux, no problem for any number of changes- On MacOS,
> > computer slows down after about 20 to 100 selections, Then it
> > crashes.
> > I have checked the source code of MainWindow.java in
> > package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and
> > 8.2 : they all have the same code, therefore the same bug.
> > If you want to check on 9.0, just check the MainWindow code. Can
> > you show it to us please, see if it has the same call under
> > resultChanged() ?
> > (Otherwise, not sure we can test with my application on 9.0, it has
> > not been converted yet to NB9.0.)
> > Tom, if I cannot have support on 8.0.1, maybe I can get support on
> > 8.2 ? Or else, can I get someone to tell me how to recompile the
> > following jar : "org.netbeans.core.windows.jar" ?
> >
> > Hope this adds more explanations.
> > Many thanks again.Frederic
> >
> >
> > Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
> > > Hi my name is Efrem. I am willing to test this with the new beta
> > > release of NB 9.0 on MacOS.
> > >
> > > I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen
> > > because
> > > of its age...
> > >
> > > If you can provide me the steps or source to test I am willing to
> > > test
> > > it today.
> > >
> > > What is the application and what are you trying to do?
> > >
> > > Please advise.
> > >
> > > Efrem McCrimon
> > > GUI Builder Tribe tester
> > > DB Tribe tester
> > >
> > >
> > >
> > > On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org>
> > > wrote:
> > > > Dear all,
> > > >
> > > > I have found a bug in Netbeans on MacOS which makes the
> > > > applications crash
> > > > on MacOS. I would like to know if it is possible to fix it in
> > > > Netbeans 8.0.1
> > > > or at least to make sure it is not in Netbeans 8.2.
> > > >
> > > > The bug :
> > > > ======
> > > >
> > > > I'm using Netbeans 8.0.1 for Ancestris. There seems to be a
> > > > conflicting
> > > > thread in MainWindow.java that compromises the removal of
> > > > lookup listeners.
> > > >
> > > > Therefore, if an updateLookup runs in the application, the
> > > > following thread
> > > > is activated which itself runs an updateLookup.
> > > >
> > > > The application ends up multiplying the number of listeners up
> > > > to several
> > > > tens of thousands and crashes on Mac.
> > > >
> > > > Here is the code with the bug: (in MainWindow.java in package
> > > > org.netbeans.core.windows.view.ui)
> > > >
> > > > if (Utilities.getOperatingSystem() == Utilities.OS_MAC)
> > > > {
> > > > //Show a "save dot" in the close button if a
> > > > modified file is
> > > > //being edited
> > > > //Show the icon of the edited file in the window
> > > > titlebar like
> > > > //other mac apps
> > > > saveResult =
> > > > Utilities.actionsGlobalContext().lookupResult
> > > > (SaveCookie.class);
> > > > dobResult =
> > > > Utilities.actionsGlobalContext().lookupResult
> > > > (DataObject.class);
> > > > if( null != saveResult && null != dobResult ) {
> > > > saveListener = new LookupListener() {
> > > > @Override
> > > > public void resultChanged(final LookupEvent
> > > > ev) {
> > > > RP.post( new Runnable() {
> > > >
> > > > @Override
> > > > public void run() {
> > > > updateMacDocumentProperties(ev);
> > > > }
> > > > });
> > > > }
> > > >
> > > > };
> > > > saveResult.addLookupListener(saveListener);
> > > > dobResult.addLookupListener(saveListener);
> > > > }
> > > > dobResult.allItems();
> > > > }
> > > >
> > > > The " updateMacDocumentProperties(ev)" includes :
> > > > - saveResult.allItems()
> > > > - dobResult.allItems()
> > > > which trigger an updateLookup as well, creating two threads
> > > > updating the
> > > > same lookups (removeListener, addListener).
> > > >
> > > >
> > > > The fix:
> > > > =====
> > > >
> > > > I would be ok to just replace :
> > > >
> > > > "Utilities.getOperatingSystem() == Utilities.OS_MAC"
> > > >
> > > > with
> > > >
> > > > "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
> > > >
> > > > because I do not think we need this on Mac in the Ancestris
> > > > application at
> > > > least.
> > > >
> > > > Can someone recompile the package with this fix and send it
> > > > back to me ? Or
> > > > else can someone help me fix it myself localy (I do not have
> > > > the code to
> > > > recompile this package) ?
> > > >
> > > >
> > > > Many thanks in advance if it can be done.
> > > >
> > > > Best regards,
> > > > Frederic
> > > >
Re: Bug in Netbeans for MacOS
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Tue, May 1, 2018 at 5:33 PM, frederic <fr...@ancestris.org> wrote:
> Hi Efrem, Thomas,
>
> Thanks for you replies.
>
> The application is Ancestris, but it does not matter much which
> application is running netbeans. I have spent quite ssome time finding the
> bug. The crash is generated after several calls to "ExplorerManager.setRootContext()"
> or "ExplorerManager.setSelectedNodes()". After about 20 to 100 calls, it
> creates the bug.
>
> What I am trying to do:
> - I have a TopComponent with a simple ExplorerManager in it, which holds
> the context. (associateLookup(ExplorerUtils.createLookup(manager, map));)
> - Each time the user changes the selected element, I run an
> ExplorerManager.setRootContext() and ExplorerManager.setSelectedNodes().
>
But why do you need to do that? That seems to be causing some kind of race
condition or blocker of some kind and you probably need to solve whatever
the situation is in a different way.
Gj
> - On Linux, no problem for any number of changes
> - On MacOS, computer slows down after about 20 to 100 selections, Then it
> crashes.
>
> I have checked the source code of MainWindow.java in
> package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and 8.2 :
> they all have the same code, therefore the same bug.
>
> If you want to check on 9.0, just check the MainWindow code. Can you show
> it to us please, see if it has the same call under resultChanged() ?
>
> (Otherwise, not sure we can test with my application on 9.0, it has not
> been converted yet to NB9.0.)
>
> Tom, if I cannot have support on 8.0.1, maybe I can get support on 8.2 ?
> Or else, can I get someone to tell me how to recompile the following jar :
> "org.netbeans.core.windows.jar" ?
>
> Hope this adds more explanations.
>
> Many thanks again.
> Frederic
>
>
>
> Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
>
> Hi my name is Efrem. I am willing to test this with the new beta
> release of NB 9.0 on MacOS.
>
> I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen because
> of its age...
>
> If you can provide me the steps or source to test I am willing to test
> it today.
>
> What is the application and what are you trying to do?
>
> Please advise.
>
> Efrem McCrimon
> GUI Builder Tribe tester
> DB Tribe tester
>
>
>
> On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org> wrote:
>
>
> Dear all,
>
> I have found a bug in Netbeans on MacOS which makes the applications crash
> on MacOS. I would like to know if it is possible to fix it in Netbeans 8.0.1
> or at least to make sure it is not in Netbeans 8.2.
>
> The bug :
> ======
>
> I'm using Netbeans 8.0.1 for Ancestris. There seems to be a conflicting
> thread in MainWindow.java that compromises the removal of lookup listeners.
>
> Therefore, if an updateLookup runs in the application, the following thread
> is activated which itself runs an updateLookup.
>
> The application ends up multiplying the number of listeners up to several
> tens of thousands and crashes on Mac.
>
> Here is the code with the bug: (in MainWindow.java in package
> org.netbeans.core.windows.view.ui)
>
> if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
> //Show a "save dot" in the close button if a modified file is
> //being edited
> //Show the icon of the edited file in the window titlebar like
> //other mac apps
> saveResult = Utilities.actionsGlobalContext().lookupResult
> (SaveCookie.class);
> dobResult = Utilities.actionsGlobalContext().lookupResult
> (DataObject.class);
> if( null != saveResult && null != dobResult ) {
> saveListener = new LookupListener() {
> @Override
> public void resultChanged(final LookupEvent ev) {
> RP.post( new Runnable() {
>
> @Override
> public void run() {
> updateMacDocumentProperties(ev);
> }
> });
> }
>
> };
> saveResult.addLookupListener(saveListener);
> dobResult.addLookupListener(saveListener);
> }
> dobResult.allItems();
> }
>
> The " updateMacDocumentProperties(ev)" includes :
> - saveResult.allItems()
> - dobResult.allItems()
> which trigger an updateLookup as well, creating two threads updating the
> same lookups (removeListener, addListener).
>
>
> The fix:
> =====
>
> I would be ok to just replace :
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC"
>
> with
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
>
> because I do not think we need this on Mac in the Ancestris application at
> least.
>
> Can someone recompile the package with this fix and send it back to me ? Or
> else can someone help me fix it myself localy (I do not have the code to
> recompile this package) ?
>
>
> Many thanks in advance if it can be done.
>
> Best regards,
> Frederic
>
>
>
Re: Bug in Netbeans for MacOS
Posted by Emilian Bold <em...@protonmail.ch>.
Please report to JIRA and create a sample module that manages to crash NetBeans on macOS by calling ExplorerManager.setRootContext / ExplorerManager.setSelectedNodes like you mentioned. Then we have something to debug.
> Or else, can I get someone to tell me how to recompile the following jar "org.netbeans.core.windows.jar" ?
Not sure what you mean here. You type `ant` in the (modified) NetBeans source tree folder.
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 1 May 2018 6:33 PM, frederic <fr...@ancestris.org> wrote:
> Hi Efrem, Thomas,
>
> Thanks for you replies.
>
> The application is Ancestris, but it does not matter much which application is running netbeans. I have spent quite ssome time finding the bug. The crash is generated after several calls to "ExplorerManager.setRootContext()" or "ExplorerManager.setSelectedNodes()". After about 20 to 100 calls, it creates the bug.
>
> What I am trying to do:
>
> - I have a TopComponent with a simple ExplorerManager in it, which holds the context. (associateLookup(ExplorerUtils.createLookup(manager, map));)
>
> - Each time the user changes the selected element, I run an ExplorerManager.setRootContext() and ExplorerManager.setSelectedNodes().
>
> - On Linux, no problem for any number of changes
>
> - On MacOS, computer slows down after about 20 to 100 selections, Then it crashes.
>
> I have checked the source code of MainWindow.java in package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and 8.2 : they all have the same code, therefore the same bug.
>
> If you want to check on 9.0, just check the MainWindow code. Can you show it to us please, see if it has the same call under resultChanged() ?
>
> (Otherwise, not sure we can test with my application on 9.0, it has not been converted yet to NB9.0.)
>
> Tom, if I cannot have support on 8.0.1, maybe I can get support on 8.2 ? Or else, can I get someone to tell me how to recompile the following jar : "org.netbeans.core.windows.jar" ?
>
> Hope this adds more explanations.
>
> Many thanks again.
>
> Frederic
>
> Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
>
> > Hi my name is Efrem. I am willing to test this with the new beta
> > release of NB 9.0 on MacOS.
> >
> > I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen because
> > of its age...
> >
> > If you can provide me the steps or source to test I am willing to test
> > it today.
> >
> > What is the application and what are you trying to do?
> >
> > Please advise.
> >
> > Efrem McCrimon
> > GUI Builder Tribe tester
> > DB Tribe tester
> >
> >
> >
> > On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org> wrote:
> >
> > > Dear all,
> > >
> > > I have found a bug in Netbeans on MacOS which makes the applications crash
> > > on MacOS. I would like to know if it is possible to fix it in Netbeans 8.0.1
> > > or at least to make sure it is not in Netbeans 8.2.
> > >
> > > The bug :
> > > ======
> > >
> > > I'm using Netbeans 8.0.1 for Ancestris. There seems to be a conflicting
> > > thread in MainWindow.java that compromises the removal of lookup listeners.
> > >
> > > Therefore, if an updateLookup runs in the application, the following thread
> > > is activated which itself runs an updateLookup.
> > >
> > > The application ends up multiplying the number of listeners up to several
> > > tens of thousands and crashes on Mac.
> > >
> > > Here is the code with the bug: (in MainWindow.java in package
> > > org.netbeans.core.windows.view.ui)
> > >
> > > if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
> > > //Show a "save dot" in the close button if a modified file is
> > > //being edited
> > > //Show the icon of the edited file in the window titlebar like
> > > //other mac apps
> > > saveResult = Utilities.actionsGlobalContext().lookupResult
> > > (SaveCookie.class);
> > > dobResult = Utilities.actionsGlobalContext().lookupResult
> > > (DataObject.class);
> > > if( null != saveResult && null != dobResult ) {
> > > saveListener = new LookupListener() {
> > > @Override
> > > public void resultChanged(final LookupEvent ev) {
> > > RP.post( new Runnable() {
> > >
> > > @Override
> > > public void run() {
> > > updateMacDocumentProperties(ev);
> > > }
> > > });
> > > }
> > >
> > > };
> > > saveResult.addLookupListener(saveListener);
> > > dobResult.addLookupListener(saveListener);
> > > }
> > > dobResult.allItems();
> > > }
> > >
> > > The " updateMacDocumentProperties(ev)" includes :
> > > - saveResult.allItems()
> > > - dobResult.allItems()
> > > which trigger an updateLookup as well, creating two threads updating the
> > > same lookups (removeListener, addListener).
> > >
> > >
> > > The fix:
> > > =====
> > >
> > > I would be ok to just replace :
> > >
> > > "Utilities.getOperatingSystem() == Utilities.OS_MAC"
> > >
> > > with
> > >
> > > "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
> > >
> > > because I do not think we need this on Mac in the Ancestris application at
> > > least.
> > >
> > > Can someone recompile the package with this fix and send it back to me ? Or
> > > else can someone help me fix it myself localy (I do not have the code to
> > > recompile this package) ?
> > >
> > >
> > > Many thanks in advance if it can be done.
> > >
> > > Best regards,
> > > Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Bug in Netbeans for MacOS
Posted by frederic <fr...@ancestris.org>.
Hi Efrem, Thomas,
Thanks for you replies.
The application is Ancestris, but it does not matter much which
application is running netbeans. I have spent quite ssome time finding
the bug. The crash is generated after several calls to
"ExplorerManager.setRootContext()" or
"ExplorerManager.setSelectedNodes()". After about 20 to 100 calls, it
creates the bug.
What I am trying to do:- I have a TopComponent with a simple
ExplorerManager in it, which holds the context.
(associateLookup(ExplorerUtils.createLookup(manager, map));)- Each time
the user changes the selected element, I run an
ExplorerManager.setRootContext() and
ExplorerManager.setSelectedNodes().- On Linux, no problem for any
number of changes- On MacOS, computer slows down after about 20 to 100
selections, Then it crashes.
I have checked the source code of MainWindow.java in
package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and 8.2 :
they all have the same code, therefore the same bug.
If you want to check on 9.0, just check the MainWindow code. Can you
show it to us please, see if it has the same call under resultChanged()
?
(Otherwise, not sure we can test with my application on 9.0, it has not
been converted yet to NB9.0.)
Tom, if I cannot have support on 8.0.1, maybe I can get support on 8.2
? Or else, can I get someone to tell me how to recompile the following
jar : "org.netbeans.core.windows.jar" ?
Hope this adds more explanations.
Many thanks again.Frederic
Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
> Hi my name is Efrem. I am willing to test this with the new beta
> release of NB 9.0 on MacOS.
>
> I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen because
> of its age...
>
> If you can provide me the steps or source to test I am willing to
> test
> it today.
>
> What is the application and what are you trying to do?
>
> Please advise.
>
> Efrem McCrimon
> GUI Builder Tribe tester
> DB Tribe tester
>
>
>
> On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org>
> wrote:
> > Dear all,
> >
> > I have found a bug in Netbeans on MacOS which makes the
> > applications crash
> > on MacOS. I would like to know if it is possible to fix it in
> > Netbeans 8.0.1
> > or at least to make sure it is not in Netbeans 8.2.
> >
> > The bug :
> > ======
> >
> > I'm using Netbeans 8.0.1 for Ancestris. There seems to be a
> > conflicting
> > thread in MainWindow.java that compromises the removal of lookup
> > listeners.
> >
> > Therefore, if an updateLookup runs in the application, the
> > following thread
> > is activated which itself runs an updateLookup.
> >
> > The application ends up multiplying the number of listeners up to
> > several
> > tens of thousands and crashes on Mac.
> >
> > Here is the code with the bug: (in MainWindow.java in package
> > org.netbeans.core.windows.view.ui)
> >
> > if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
> > //Show a "save dot" in the close button if a modified
> > file is
> > //being edited
> > //Show the icon of the edited file in the window
> > titlebar like
> > //other mac apps
> > saveResult =
> > Utilities.actionsGlobalContext().lookupResult
> > (SaveCookie.class);
> > dobResult =
> > Utilities.actionsGlobalContext().lookupResult
> > (DataObject.class);
> > if( null != saveResult && null != dobResult ) {
> > saveListener = new LookupListener() {
> > @Override
> > public void resultChanged(final LookupEvent ev)
> > {
> > RP.post( new Runnable() {
> >
> > @Override
> > public void run() {
> > updateMacDocumentProperties(ev);
> > }
> > });
> > }
> >
> > };
> > saveResult.addLookupListener(saveListener);
> > dobResult.addLookupListener(saveListener);
> > }
> > dobResult.allItems();
> > }
> >
> > The " updateMacDocumentProperties(ev)" includes :
> > - saveResult.allItems()
> > - dobResult.allItems()
> > which trigger an updateLookup as well, creating two threads
> > updating the
> > same lookups (removeListener, addListener).
> >
> >
> > The fix:
> > =====
> >
> > I would be ok to just replace :
> >
> > "Utilities.getOperatingSystem() == Utilities.OS_MAC"
> >
> > with
> >
> > "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
> >
> > because I do not think we need this on Mac in the Ancestris
> > application at
> > least.
> >
> > Can someone recompile the package with this fix and send it back to
> > me ? Or
> > else can someone help me fix it myself localy (I do not have the
> > code to
> > recompile this package) ?
> >
> >
> > Many thanks in advance if it can be done.
> >
> > Best regards,
> > Frederic
> >