mbien commented on issue #8079: URL: https://github.com/apache/netbeans/issues/8079#issuecomment-2558499528
I mean the cause for this is likely that the system (e.g wayland) reports a zero sized screen/frame or creates zero sized images/buffers. However I am more interesting in the defensive programming aspect of it. One exception is fine, but it it causes a loop and pins one core to 100% it would be good to check if we can somehow prevent that. There is only one stack frame of NB code on the trace - and it doesn't do a lot. However, it looks like it is possible to turn that queue off by changing a property (`TimableEventQueue.install=false`) in `platform/modules/org-netbeans-core.jar#org/netbeans/core/Bundle.properties`. (btw it indeed is `Tim` not `Time`, which was probably a typo) We should also not run VisualVM and NB at the same time while investigating since both are affected by this issue. https://github.com/async-profiler/async-profiler is a nice tool which can profile on the process level. Default output are flame graphs which show active areas. I would also give the latest update of JDK 23 a try, since not all fixes are backported. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
