[Bug classpath/22967] swing: BasicListUI.damageLayout does not handle list==null

[gcc-bugzilla at gcc dot gnu dot org]

Creating a testcase does not seem to be quite trivial for this bug so here's
just a verbal explanation of the problem.

At present BasicListUI.damageLayout does

list.revalidate();

which obviously crashes if list==null. I am not sure what the actual bug is.
Should we

1) make sure that damageLayout handles the list==null case

or

2) make sure that damageLayout is never called if list==null?


How BasicListUI.list can be null?

Supposed there is a JList X with BasicListUI Y as the ui. If somebody calls
X.setUI(some_other_UI) then Y.list will be null. Now if somebody resizes Y then
BasicListUI$ComponentHandler.componentResized is called and that calls
damageLayout which will crash because list==null.


------- Comment #1 from from-classpath at savannah dot gnu dot org  2005-06-01 
20:21 -------
> 1) make sure that damageLayout handles the list==null case
> 
> or
> 
> 2) make sure that damageLayout is never called if list==null?

1.

How BasicListUI.list can be null?

Don't know. How have you found this bug then? ;-)

/Roman


------- Comment #2 from from-classpath at savannah dot gnu dot org  2005-06-01 
20:31 -------
It is triggered by the matrix framework that can be downloaded from

http://www.cs.hut.fi/Research/Matrix/release/build-10/matrix10.tar.gz

and compiled with

cd  code; javac `find -name "*.java"`

and run with

java prototype.ui.StartFrame

I haven't managed to produce smaller testcase yet.


------- Comment #3 from from-classpath at savannah dot gnu dot org  2005-06-02 
11:09 -------
Whoops, the list==null crash actually happens with the omniscient debugger from

http://www.lambdacs.com/debugger/debugger.html

with
Exception during event dispatch:
java.lang.NullPointerException
   at javax.swing.plaf.basic.BasicListUI.damageLayout (BasicListUI.java:501)
   at javax.swing.plaf.basic.BasicListUI$ComponentHandler.componentResized
(BasicListUI.java:91)
   at java.awt.AWTEventMulticaster.componentResized
(AWTEventMulticaster.java:188)
   at java.awt.AWTEventMulticaster.componentResized
(AWTEventMulticaster.java:188)
   at java.awt.AWTEventMulticaster.componentResized
(AWTEventMulticaster.java:188)
   at java.awt.Component.processComponentEvent (Component.java:2957)
   at java.awt.Component.processEvent (Component.java:2922)
   at java.awt.Container.processEvent (Container.java:841)
   at java.awt.Component.dispatchEventImpl (Component.java:4775)
   at java.awt.Container.dispatchEventImpl (Container.java:1539)
   at java.awt.Component.dispatchEvent (Component.java:2280)
   at java.awt.EventQueue.dispatchEvent (EventQueue.java:526)
   at java.awt.EventDispatchThread.run (EventDispatchThread.java:75)


------- Comment #4 from from-classpath at savannah dot gnu dot org  2005-06-03 
14:39 -------
Ok, I have checked in a fix for this one too. Please test and report.


------- Comment #5 from from-classpath at savannah dot gnu dot org  2005-06-05 
00:01 -------
Ok, seems to work. Now fewer changes need to be done to the omniscient debugger
in order to run it with classpath.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22967