loadImage("something.png") can sometimes cause problems. the issue seems to be
something about the image decoder, but it's not clear what's going on. one such error shows
up like this:

java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at java.awt.image.PixelGrabber.setPixels(PixelGrabber.java:583)
at sun.awt.image.ImageDecoder.setPixels(ImageDecoder.java:120)
at sun.awt.image.PNGImageDecoder.sendPixels(PNGImageDecoder.java:547)
at sun.awt.image.PNGImageDecoder.produceImage(PNGImageDecoder.java:450)
at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:254)
at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172)
at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)

it seems to be more of a problem if images are loaded inside draw() instead of setup(). we
recommend loading images in setup anyway.

it's not clear whether the image is marked as an "error" from the MediaTracker. if this is the
case, then the MediaTracker could re-attempt the download. but i haven't been able to get
the bug to reproduce consistently enough to test.

other suspects could be threading issues (draw and setup running on the awt thread, and
Thread.interrupt() getting called and killing the MediaTracker).

this may be related to bug #279.

switched to using Toolkit.getDefaultToolkit().getImage( filename )
successfully loads images (png & gif)
while createImage( byte[] ) has some issues

probably related to threading issues

final summary for this bug:

Toolkit.createImage() using a byte array has problems that wind up with the image not
being properly decoded. it seems to be some kind of thread interaction between how p5
handles threads and how net io works on loadBytes. this is exacerbated by moving the
loadImage() out of setup, suggesting that it's a threading issue.

loadBytes() is being used because it forces a non-cached version of the image. for the next
release, i need to decide whether to 1) make cached images the default, meaning that the
default will be to use getImage, or 2) simply add a "cached" version that's loadImage() with
that alternate "cache" parameter, which would use getImage.

pros/cons of each: 1) pro: current model, usually want non-cached images con: when the
bug shows up, it's just one more of a zillion little "hacks" necessary to get p5 code running
properly. 2) pro: more compatible and likely to work con: need to explicitly shut off cache,
causing some confusion (see old threads on the board about everyone's webcam being
broken).

*** Bug 279 has been marked as a duplicate of this bug. ***

added to the javadoc, closing this bug for now:

* For releases 0116 and later, if you have problems such as those seen
* in Bugs 279 and 305, use Applet.getImage() instead. You'll be stuck
* with the limitations of getImage() (the headache of dealing with
* online/offline use). Set up your own MediaTracker, and pass the resulting
* java.awt.Image to the PImage constructor that takes an AWT image.
* You can also use the loadImageSync() function (added in 0116) that
* takes an AWT image and loads it synchronously inside PApplet.
* This isn't much fun, but this will have to do unless we find the
* actual culprit, which may still be a threading issue.
* <PRE>
* public PImage loadImageAlt(String filename) {
* java.awt.Image img = getImage(getCodeBase(), filename);
* return loadImageSync(img);
* }
* </PRE>

edit]
The error report, suspected source and class using the gifs

IOException thrown when clicking button to load widgets into a panel. Cant
catch exception in my code. Source of error is reported as:

// JBuilder API Decompiler stub source generated from class file
// Oct 17, 2006
// -- implementation of methods is not available

package sun.awt.image;

// Imports
import java.lang.Object;
import sun.awt.image.ImageFetcher$1;
import sun.awt.image.ImageFetchable;
import java.lang.ThreadGroup;
import sun.awt.image.FetcherInfo;
import java.security.PrivilegedAction;
import java.lang.Thread;

class ImageFetcher extends Thread {........

......
// Constructors
private ImageFetcher(ThreadGroup p0, int p1) { }
ImageFetcher(ThreadGroup p0, int p1, 1 p2) { } //HERE

There are no problems with the icons displayed (gifs) on the button.
The program executes perfectly while the exception is thrown but if the window
is minimised, covered by another application the view has to be switched and
returned to in order for it to display correctly.
Only when the button is clicked again and the panels removed does the Exception
stop. The time is also displayed on the button and is not when other icons that
do not cause problems are displayed on the button.
There is a lot of code behind this application and I have tried to make the
problem as simple to understand as possible.
Would the problem be caused by a corrupt Java file or is it an error in my
code?
I am getting nowhere chasing the exception and an IOException cant be caught in
my code. This application is part of my project for my degree in computing and
I really would like to get it resolved so I can concentrate on the coding which
is now behind schedule.

this bug is closed because it's been fixed as best as possible. if you're
having another issue, please file a new bug. but your description sounds
more like you're having a general programming or java issue, not something
to do with processing.