wrote:
> I'm working on a GUI and keep getting the following error. I have no
> idea where to start looking since all the debugging infor is stripped
> out. Since I compile with debugging flags turned on, I can only assume
> this error is in one of the precompiled classes, but which one? If it
The exception originates in the getComponent() method of
java.awt.Container, which you can tell from the first "at" line in the
stack trace. The rest of the trace shows the nested invocation contexts
of that method. The exception happens in the AWT / Swing event dispatch
thread, which no doubt relates to the accompanying weirdness you see
(and probably also to weirdness you don't see). HOWEVER, although the
exception originates from Container, that doesn't necessarily mean the
bug is there. Indeed, it is far more likely that the bug is in your own
code. (More below.)
> helps, I'm using a 1.3.1_07 SDK/JRE from Sun. I'm compiling with the
> -O and -g flags. This error is rare, but when it happens it sometimes
> causes other weirdness, so I'd like to get rid of it if possible. Any
> suggestions?
> -Will
>
> ArrayIndexOutOfBoundsException: no such child: 39
> at java.awt.Container.getComponent(Unknown Source)
Read the first part of the stack trace, especially the exception
message, in the context of the immediate source (Container): "no such
child". It sounds like some Component that is a Container is attempting
to access a child component that it thinks it has but does not find.
Assuming that the Swing and AWT classes are not buggy, what are the
possibilities? Chief among them, from my point of view, are
1) a child component has been removed (or partly removed) without the
Container recognizing it
and
2) a child component has been added (or partly added) without the
Container recognizing it
If you are not mucking about unreasonably in the internals of Swing and
AWT classes (so as to break them), then the "partly added" and "partly
removed" alternatives make the most sense. This is possible, and not so
unreasonable, because your program is multithreaded (as all AWT and
Swing programs are). Let's continue a bit:
> at javax.swing.JComponent.rectangleIsObscured(Unknown Source)
> at javax.swing.JComponent.paint(Unknown Source)
> at javax.swing.JComponent.paintWithBuffer(Unknown Source)
> at javax.swing.JComponent._paintImmediately(Unknown Source)
> at javax.swing.JComponent.paintImmediately(Unknown Source)
See all those methods on JComponent? It looks like the problematic
Container is in fact some kind of JComponent. The exception happens in
the context of the JComponent painting itself, and one can surmise (from
the rectangleIsObscured() part of the trace) that the JComponent is
trying to examine its children to see what parts need to be repainted.
Onward:
> at javax.swing.RepaintManager.paintDirtyRegions(Unkno wn Source)
> at
> javax.swing.SystemEventQueueUtilities$ComponentWor kRequest.run(Unknown
> Source)
> at java.awt.event.InvocationEvent.dispatch(Unknown Source)
And here we see that all of that happens in the context of the dispatch
of an InvocationEvent. The API docs will clue you in here that these
are used in the AWT event subsystem to handle calls to
EventQueue.invokeLater() and .invokeAndWait(). It is conceivable that
other, internal facilities might also use them. The most likely
external means of getting these invoked is SwingUtilities.invokeLater()
and SwingUtilities.invokeAndWait().
The rest of the stack trace just shows that the event was dispatched
during the normal course of the event dispatch thread's operation.
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at java.awt.EventDispatchThread.pumpOneEventForHierar chy(Unknown
> Source)
> at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source)
So what's happening here? You say the error is rare, and it looks to me
like a data corruption problem. That has thread synchronization error
written all over it. The first thing to do is to ensure that you don't
muck with your GUI objects outside the event dispatch thread; doing so
is likely the cause of your problem. If you want to modify GUI elements
that are visible (whether or not they are obscured) then you _must_ do
it in the event dispatch thread. You can cause a non-EDT thread to
request such action of the EDT with use of the aforementioned
SwingUtilities.invokeLater() and SwingUtilities.invokeAndWait().
If you need more help then very likely you will have to show some code.
In that case construct a minimal self-contained, compilable example
that exhibits the problem, and post that.
John Bollinger
Similar Threads
