Problem tracking down an error

[Knute Johnson]

I've got some production code and at one site I keep getting an
ArrayIndexOutOfBoundsException. The problem is that there is no line
number in the stack trace so I don't know where this is happening. The
error is posted below. This one user must be doing something different
than the other two but I can't get them to give me any details (which is
very typical). I can give them modified code easily so any ideas on how
to track this?

Thanks,

C:\terminal>java
-Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAnd
Feel -Xms200m -Xmx240m -jar Terminal.jar
Terminal - Version: 04.11 - 08 Oct 09

Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException:
4
at sun.font.FontDesignMetrics.charsWidth(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.PlainView.viewToModel(Unknown Source)
at javax.swing.text.FieldView.viewToModel(Unknown Source)
at
javax.swing.plaf.basic.BasicTextUI$RootView.viewToModel(Unknown Sourc
e)
at javax.swing.plaf.basic.BasicTextUI.viewToModel(Unknown Source)
at javax.swing.text.DefaultCaret.moveCaret(Unknown Source)
at javax.swing.text.DefaultCaret.mouseDragged(Unknown Source)
at java.awt.AWTEventMulticaster.mouseDragged(Unknown Source)
at java.awt.Component.processMouseMotionEvent(Unknown Source)
at javax.swing.JComponent.processMouseMotionEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown
Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException:
38
at sun.font.FontDesignMetrics.charsWidth(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.PlainView.viewToModel(Unknown Source)
at javax.swing.text.FieldView.viewToModel(Unknown Source)
at
javax.swing.plaf.basic.BasicTextUI$RootView.viewToModel(Unknown Sourc
e)
at javax.swing.plaf.basic.BasicTextUI.viewToModel(Unknown Source)
at javax.swing.text.DefaultCaret.positionCaret(Unknown Source)
at javax.swing.text.DefaultCaret.adjustCaret(Unknown Source)
at javax.swing.text.DefaultCaret.adjustCaretAndFocus(Unknown
Source)
at javax.swing.text.DefaultCaret.mousePressed(Unknown Source)
at java.awt.AWTEventMulticaster.mousePressed(Unknown Source)
at java.awt.AWTEventMulticaster.mousePressed(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown
Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

 

[John B. Matthews]

I've got some production code and at one site I keep getting an
ArrayIndexOutOfBoundsException. The problem is that there is no line
number in the stack trace so I don't know where this is happening.
The error is posted below. This one user must be doing something
different than the other two but I can't get them to give me any
details (which is very typical). I can give them modified code
easily so any ideas on how to track this?

Thanks,

C:\terminal>java
-Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAnd
Feel -Xms200m -Xmx240m -jar Terminal.jar
Terminal - Version: 04.11 - 08 Oct 09

Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException:
4
at sun.font.FontDesignMetrics.charsWidth(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
at javax.swing.text.PlainView.viewToModel(Unknown Source)
at javax.swing.text.FieldView.viewToModel(Unknown Source)

....

I stumbled upon a similar stacktrace in this bug report and discussion:

<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6857057>
<http://forums.sun.com/thread.jspa?threadID=5407111>

 

[Martin Gregorie]

I've got some production code and at one site I keep getting an
ArrayIndexOutOfBoundsException. The problem is that there is no line
number in the stack trace so I don't know where this is happening. The
error is posted below. This one user must be doing something different
than the other two but I can't get them to give me any details (which is
very typical). I can give them modified code easily so any ideas on how
to track this?

I don't have any directly relevant comments - sorry - and the following
is probably not directly relevant because retrofitting would be tedious,
but it may give you some ideas:

I have never got on with debuggers, so I tend to load up my programs with
trace statements that output to stderr. So far, so conventional, however
I also add command line options to control debugging detail by setting a
'debug' integer and always leave this stuff in production code because
the speed impact of testing integer values and skipping debug statements
is minimal and the diagnostic value of this trick during live running is
huge.

An even better trick I learned from an ancient OS (ICL George 3) is to
leave tracing permanently active but to send it to a circular buffer.
Dumping the buffer is triggered by fatal errors, so you get the error
plus the program actions leading to it. The overhead of this approach is
a bit higher, but again not really noticeable. The benefit is that you
are guaranteed to get a manageable amount of diagnostics from any crash.


Martin

 

[Arne Vajhøj]

I have never got on with debuggers, so I tend to load up my programs with
trace statements that output to stderr. So far, so conventional, however
I also add command line options to control debugging detail by setting a
'debug' integer and always leave this stuff in production code because
the speed impact of testing integer values and skipping debug statements
is minimal and the diagnostic value of this trick during live running is
huge.

I completely agree that debuggers are great for debugging toy programs,
but log output is often much better for real world programs.

But I would use log4j instead of something home made.

Arne

 

[Knute Johnson]

...

I stumbled upon a similar stacktrace in this bug report and discussion:

<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6857057>
<http://forums.sun.com/thread.jspa?threadID=5407111>

John:

That looks like the problem and it explains why the other sites don't
have it because they're older and don't have the latest JRE.

Thanks,

 

[Knute Johnson]

I don't have any directly relevant comments - sorry - and the following
is probably not directly relevant because retrofitting would be tedious,
but it may give you some ideas:

I have never got on with debuggers, so I tend to load up my programs with
trace statements that output to stderr. So far, so conventional, however
I also add command line options to control debugging detail by setting a
'debug' integer and always leave this stuff in production code because
the speed impact of testing integer values and skipping debug statements
is minimal and the diagnostic value of this trick during live running is
huge.

I started doing that with C programs and still use it for Java.

An even better trick I learned from an ancient OS (ICL George 3) is to
leave tracing permanently active but to send it to a circular buffer.
Dumping the buffer is triggered by fatal errors, so you get the error
plus the program actions leading to it. The overhead of this approach is
a bit higher, but again not really noticeable. The benefit is that you
are guaranteed to get a manageable amount of diagnostics from any crash.

That's a neat trick, I like it!

 

[Roedy Green]

Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException:
4
at sun.font.FontDesignMetrics.charsWidth(Unknown Source)

My guess is the font you are using has malformed Font metrics data.
Are you using some unusual font? Are you playing with ANY font the
user has installed or just a known safe set?

 

[Knute Johnson]

My guess is the font you are using has malformed Font metrics data.
Are you using some unusual font? Are you playing with ANY font the
user has installed or just a known safe set?

I am using one modified font but it has been in use for years. Also, it
only occurs at one installation where the new JRE is installed. I think
John came up with the right cause.

Thanks,

 

[Martin Gregorie]

I completely agree that debuggers are great for debugging toy programs,
but log output is often much better for real world programs.

But I would use log4j instead of something home made.

Like Knute, I started doing this in C programs. Actually I lie - I
started doing this in COBOL, long before I learned C. Anyway, I simply
transferred the technique across to Java, but as its implemented as a
class, partly to shorten tracing statements. IMO re.trace("blah blah");
is more readable and faster to write than System.err.println("blah
blah");.

It would be trivial to change my ReportError class to use log4j rather
than System.err but I'd probably roll in the circular buffer trick at the
same time since that hasn't yet made it into Java.

 

[Mike Schilling]

But I would use log4j instead of something home made.

Why log4j rather than java.util.logger? (just curious; I've always
used the latter, so have no basis for comparison)

 

[Mike Schilling]

An even better trick I learned from an ancient OS (ICL George 3) is
to
leave tracing permanently active but to send it to a circular
buffer.
Dumping the buffer is triggered by fatal errors, so you get the
error
plus the program actions leading to it. The overhead of this
approach
is a bit higher, but again not really noticeable. The benefit is
that
you are guaranteed to get a manageable amount of diagnostics from
any
crash.

Very nice.

 

[Tom Anderson]

I completely agree that debuggers are great for debugging toy programs,
but log output is often much better for real world programs.

I think they're for completely different purposes. Logging is for figuring
out roughly where an problem is - your application is behaving badly, so
you have a look at the logs , and you see warnings suggesting something's
wrong in the furnace or whatever. A debugger is for figuring out why a
component is causing a problem - you attach to the furnace and fire
various inputs at it and follow execution, and see where invariants are
violated, where the wrong branch is being taken, where nulls are creeping
in, etc.

I find i get a lot more use out of the debugger early on in development,
when i'm actually writing something and its internal behaviour is still in
flux. Later on, when things are more about integration and discovering
corner cases, it's often "hmm, i see the turntable is crashing when i load
colours with a lot of blue in them - oh yeah, i only allowed forty bytes
for blue, that's what it is", and you don't even need to look hard at the
code or debug to figure out the solution.

tom

 

[Arne Vajhøj]

Why log4j rather than java.util.logger? (just curious; I've always
used the latter, so have no basis for comparison)

log4j has more features than jul.

And if it is a Java EE context then log4j are most likely already
there, so I want the de luxe solution.

If it is an Java SE context then I would consider jul to simplify
deployment.

Arne

 

[Mike Schilling]

log4j has more features than jul.

Which ones do you find most useful?

 

[Arne Vajhøj]

I think they're for completely different purposes. Logging is for
figuring out roughly where an problem is - your application is behaving
badly, so you have a look at the logs , and you see warnings suggesting
something's wrong in the furnace or whatever. A debugger is for figuring
out why a component is causing a problem - you attach to the furnace and
fire various inputs at it and follow execution, and see where invariants
are violated, where the wrong branch is being taken, where nulls are
creeping in, etc.

I find i get a lot more use out of the debugger early on in development,
when i'm actually writing something and its internal behaviour is still
in flux. Later on, when things are more about integration and
discovering corner cases, it's often "hmm, i see the turntable is
crashing when i load colours with a lot of blue in them - oh yeah, i
only allowed forty bytes for blue, that's what it is", and you don't
even need to look hard at the code or debug to figure out the solution.

In my experience then if a debugger can be used to find the problem
then reading the code can do it.

Arne

 

[Arne Vajhøj]

Which ones do you find most useful?

Argh. That is what happen when one make statements like that.



I like all the appenders that comes with log4j.

I like the more advanced configuration options.

It can do a lot more. Not particular surprising
considering that it has 5-10 times as many classes.

Oh - and it performs better as well.

Arne