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.
During running tests AssertionError appeares often very much.
Created attachment 58182 [details] Stack trace
All cnd code completion tests fail because of this bug
Any hints on where to go and what to run in order to reproduce this, please? Thanks
Also, could you please try to run your tests with the 'org.openide.explorer.view.LazyListModel.skipExpensiveAsserts' property set to true?
Thanks for the hint with property key. I've set it to true and no such Asserts any more. What about how to reproduce. It's really difficult to explain. I'll try to do it in a separate email.
I assume the priority of this is now considerably lower, right?
OK. Let it stay P4, but I still have asserts. Not so often as without the key, but it's enough for braking tests. So, my ask is to fix. PS. Assert appeares after calling CodeCompletion list using Jelly oeprator CompletionJListOperator.showCompletion();
Unfortunately, I'm not able to reproduce the issue. Could you please provide me with the exact steps to reproduce it? Thanks.
moving opened issues from TM <= 6.1 to TM=Dev
Product Version: NetBeans IDE Dev (Build 200809180201) Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b15 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) Unable to reproduce either. No additional info for more than o month -> closing INCOMPLETE issue aioffe, please reopen if you are still experiencing this problem and provide some details how to reproduce. Thanks!
*** Issue 149229 has been marked as a duplicate of this issue. ***
*** Issue 149368 has been marked as a duplicate of this issue. ***
My issue marked as duplicate so writing here. I was able to reproduce test fail with specified property set to true as well as without. Fail rate looks just the same in both cases. Please take a look to this issue because it affects commit validation tests. Not very often, about 10% of executions, but very annoying.
Could you please attach an example stack traces of asserts thrown with the property set to true? Thanks.
I can't post trace right now, because fail rate is very low and I need to do many executions for. As I remember trace was just the same as already posted. Well, it looks slightly strange, possibly I set property using wrong way so it did not have effect really. Should I use -D or -D-J? BTW I can't understand why existing trace is not enough for start fixing. It shows point of fail and will property help or no this problem will not became different. Correct me if I wrong.
> Should I use -D or -D-J? Definitely not -D-J, it should be -J-D. I'm not sure which one from -D or -J-D you should use. It depends on where you are setting this property from. If the property goes through netbeans launchers (<nbinst>/bin/*) then -J-D should be used. > BTW I can't understand why existing trace is not enough for start fixing. Because of code changes an old stacktrace may become (partially or completely) useless at the time when a developer tries to investigate a problem. In this particular case even you are not sure if the stacttraces with and without the property set were the same. After inspecting the original stacktrace we concluded that setting the property should avoid the problem. But you say that you still occasionally get the assertion and so chances are that the assertion is reached from somewhere else, which would be shown on the new stactrace. Please post here the new stactrace when you get the assertion next time. Thanks
I use simpletest started from command line and -J-D doesn't work. Anyway I changed test sequence on our side and avoid this assertion somehow -- unfortunately this way easier.
> I use simpletest started from command line and -J-D doesn't work. Ok, no idea. > Anyway I changed test sequence on our side and avoid this assertion somehow So, the problem is no longer reproducible by running the tests, right?
Yes, that's correct. I can't say this is "right" because this is not right way to fix assertion fails.
Appeared again from another part of testing code. http://deadlock.netbeans.org/hudson/job/trunk/4193/testReport/org.netbeans.test.php/Commit/ManipulateIndexPHP/ It's very good idea to fix it finally. java.lang.AssertionError: external and checked must be consistent: 601 at org.netbeans.modules.editor.completion.LazyListModel.externalContraints(LazyListModel.java:226) at org.netbeans.modules.editor.completion.LazyListModel.initialize(LazyListModel.java:307) at org.netbeans.modules.editor.completion.LazyListModel.getSize(LazyListModel.java:408) at javax.swing.plaf.basic.BasicListUI.convertModelToColumn(BasicListUI.java:1078) at javax.swing.plaf.basic.BasicListUI.getCellBounds(BasicListUI.java:793) at javax.swing.plaf.basic.BasicListUI.getCellBounds(BasicListUI.java:755) at javax.swing.plaf.basic.BasicListUI.paint(BasicListUI.java:277) at javax.swing.plaf.ComponentUI.update(ComponentUI.java:142) at javax.swing.JComponent.paintComponent(JComponent.java:743) at javax.swing.JComponent.paint(JComponent.java:1006) at org.netbeans.modules.editor.completion.CompletionJList.paint(CompletionJList.java:142) at javax.swing.JComponent.paintChildren(JComponent.java:843) at javax.swing.JComponent.paint(JComponent.java:1015) at javax.swing.JViewport.paint(JViewport.java:728) at javax.swing.JComponent.paintChildren(JComponent.java:843) at javax.swing.JComponent.paint(JComponent.java:1015) at javax.swing.JComponent.paintChildren(JComponent.java:843) at javax.swing.JComponent.paint(JComponent.java:1015) at javax.swing.JComponent.paintChildren(JComponent.java:843) at javax.swing.JComponent.paint(JComponent.java:1015) at javax.swing.JLayeredPane.paint(JLayeredPane.java:559) at javax.swing.JComponent.paintChildren(JComponent.java:843) at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4979) at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4925) at javax.swing.JComponent.paint(JComponent.java:996) at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:21) at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60) at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:97) at java.awt.Container.paint(Container.java:1709) at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248) at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:56) at sun.awt.RepaintArea.paint(RepaintArea.java:224) at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:645) at java.awt.Component.dispatchEventImpl(Component.java:4060) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3819) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at org.netbeans.jemmy.QueueTool$JemmyQueue.dispatchEvent(QueueTool.java:610) [catch] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
It seems like a race condition that causes this problem. I've just added an assert to make sure, that ListModel methods are called from AWT event thread only. changeset 61ad9681ecc6 in main details: http://hg.netbeans.org/main?cmd=changeset;node=61ad9681ecc6 Could you please update the sources and run your tests again? Thanks
After your changes our tests became unusable and fail each time. Would you please specify how to "call ListModel methods from AWT event thread" for Jemmy based tests. Thanks.
PHP iTeam is really interested in fix of this issue because it affects each build. We also disabled PHP tests which affected by issues till fix and now commit validation for PHP contains almost nothing. Property, specified as workaround, did not help BTW.
The problem is that LazyListModel is not thread safe, because it is supposed to be called from AWT event thread only. However the affected tests access it also from other threads (proved when I tried to add an assert last week) that causes race conditions. *** This issue has been marked as a duplicate of 153526 ***
Actually I wounder why other issue (153526) did not fixed yet. I'll try to force fix today.
Dusan, as I understand you removed your latest assertion with AWT thread check. Would you please commit it back for a while, because we have fix and your code is good for verify it is successful or no. Without your check code tests fail occasionally and I really want to skip a lot of executions.
Removed assert added back. changeset df95cc7bad36 in main details: http://hg.netbeans.org/main?cmd=changeset;node=df95cc7bad36