I've found a bug!
Processing won't start! Nothing happens when I click “Run”!
Export and Browser Troubles
Out Of Memory Errors
Why don't these Strings equal?
Why does 2 / 5 = 0 instead of 0.4?
Common Issues (not bugs)
Problems with Video (Quicktime for Java)
Using the Serial Port
When Drawing in 2D
Problems with OpenGL
Things that we probably can't fix
Known Bugs

1. the revision number (i.e. 0085)
2. what operating system you're using, and on what kind of hardware
3. a copy of the smallest possible piece of code that will produce the error you're having trouble with
4. details of the error, either the red spew that you see in the console, or the last few lines from the files stdout.txt or stderr.txt from the 'lib' folder.

• Windows: Documents and Settings → (your user name) → Application Data → Processing → build
• Mac OS X: Users → (your user name) → Library → Processing → build
• Linux and others: ~/.processing → build

• We want the minimum amount of code that will still replicate the bug. The worst that can happen is we get a report with a subject saying "problem!" along with a three page program. Sure, everyone likes a puzzle, but simpler code will receive a faster response.
• Occasionally we may need you to pack up a copy of your sketch folder or something similar so that we can try and replicate the weirdness on our own machine. Rest assured, we have no interest in messing with your fancy creations or stealing your ideas. The Processing team is a pair of straight-laced boys who hail from the midwestern U.S. who were brought up better than that. and as we often lack enough time to build our own projects, we have even less time to spend figuring out other peoples' projects to rip them off.

• Processing seems to have trouble starting when run from a user account that contains non-ascii characters. For instance, if your name contains Japanese characters or umlauts, it's likely to have trouble. Sometimes using run.bat instead will fix this. Another fix is to create a user account that uses only ascii characters. In the meantime, we're looking for a fix. (Bug 49)
• If you have lots of garbage in your CLASSPATH environment variable, that might cause trouble starting up a sketch. You might get "Couldn't find package xxx.xxx" errors. Clean things up by avoiding spaces and quotes. This is because of Windows' awesome hokiness and its not-as-distant-as-it-should-be ancestor DOS. In the future, we'd like to detect errors like this before they cause trouble. That issue is being tracked at Bug 112.
• You might also try using run.bat to start processing. Lots of people seem to have a better time with this method.
• If you're using the "without Java" download, try downloading the version that includes Java. Chances are, your machine has Java 1.5 installed, which is not supported and causes lots of headaches. For instance, it won't play nice with some graphics cards and causes the Processing window to come up mostly blank.
• If you're still having trouble, try disabling any overly protective virus scanning software. It might be holding things up, especially when libraries have been imported.

• If you're running on Mac OS X 10.2, read the platforms section regarding things that may be broken.
• Sometimes you might see the following error:
  dyld: /Applications/processing/jikes version mismatch for library:
  /sw/lib/libiconv.2.dylib (compatibility version of user:
  5.0.0 greater than library's version: 3.0.0)
  It seems that this happens when an older version of Fink is installed. In this case, you should either update or uninstall Fink. (thanks to ryan govostes for tracking this down)

• If you get an error reading jikes: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory, It's because Processing requires libstdc++-libc6.2-2.so.3 for jikes. You should either install it or, since it's old, install the rpm/package for compat-libstdc++ before Processing will run. Or find/rebuild a different version of jikes that's compatible with your distro. Jikes is available here, and it's an easy ./configure, make, and then copy src/jikes to the processing-XXXX folder and you should be all set. (Bug 47)
  
  
• Or if you encounter a problem like this one: jikes: relocation error: /opt/processing-0087/./jikes: undefined symbol: __dynamic_cast_2, then that also means that jikes is incompatible with your distro. (Also Bug 47)

• Errors inside code that is outside of setup() or draw() may just hang/freeze Processing. For instance, with this code, if "blah.vlw" is not in the "data" folder, it may just hang:

    PFont font = loadFont("blah.vlw");
  
    void setup {
      // your awesome code
    }

  In general, a better practice is to use loadFont() (and loadImage and the rest) inside of a function like setup().

• Applets cannot open or write to files on the local machine. So things like saveFrame() will cause an error when run from an applet. To read files, make sure that you use "Add File..." to add the file to your sketch (or place it in the data folder yourself) so that it will be included when exported. Then, only use functions like loadStrings(), loadImage(), openStream(), etc. to read data from your file.
• Applets may only connect to servers other than the one from which they came. If you need to redirect things from another server, you can write a short script that will do it, understanding the possible security consequences for your own machine.
• They're also not allowed to do things like capture video or audio. You don't want a malicious applet that turns on your webcam and starts sending things back to their server.

• Another common problem is placing images or files into the sketch folder by hand, rather than placing them in the data folder (or using "Add File..." to do so automatically). This will work from the PDE, but on export, the files won't be in included with your sketch because they're not in the data folder.
• Watch out for issues with capitalization! Windows and Mac OS don't care about capitalization, so "blah.JPG" looks just the same as "blah.jpg". However, since most servers run on Unix, capitalization becomes a huge problem, because it must be exact. We've added some checks to try and catch this (at least for images) but they're not perfect. This can especially be a problem when the .JPG extension is not even visible (the default on Windows), so you don't know whether it's upper or lower case.
• Your browser may be using an old version of an applet. Unfortunately it's often difficult to get your browser to flush its cache. You may need to quit all instances of the browser, use alt-reload (or ctrl or shift or option, who knows) to get the new version to show up. On Windows, clicking the Java coffee cup at the right of the task bar can bring up a control panel that will let you flush the Java cache too. This is different across all platforms, but if someone wants to write a good explanation for any platform they're familiar with, please post on the discourse area of the site and we'll add it to the FAQ.

• You cannot use the OpenGL library from the web.
• The video library (both Capture and Movie) cannot be used on the web

-Xms128m -Xmx1024m

• Windows: Documents and Settings → (your user name) → Application Data → Processing → preferences.txt
• Mac OS X: Users → (your user name) → Library → Processing → preferences.txt
• Linux and others: ~/.processing → preferences.txt

• On Windows, try adjusting the parameters in the file 'run.bat' and use that to run instead of Processing.exe. Short instructions can be found inside that file. It appears that the maximum amount of RAM that can be used on Windows is around 1.4 GB.
  
  
• On Mac OS X, right-click on Processing, select Show Package Contents, then edit "Info.plist" inside "Contents". Change these lines:

  <key>VMOptions</key>
  <string>-Xms128M -Xmx256M</string>

  to set to something higher than 128M and 256M (128 and 256 megabytes of ram) as you need to (and at your own risk).
  
  
• On Linux, adjust the Processing shell script as needed.

String[] lines = loadStrings("sometext.txt");
for (int i = 0; i < lines.length; i++) {
  if (lines[i] == "hello") { 
    println("hello found on line: " + i); // you'll never see this
  }
}

String[] lines = loadStrings("sometext.txt");
for (int i = 0; i < lines.length; i++) {
  if (lines[i].equals("hello")) {
    println("hello found on line: " + i); // happiness
  }
}

int a = 2;
int b = 5;
int result = a / b;
// result is zero

float a = 2.0;
float b = 5.0;
float result = a / b;
// result is 0.4

float y = 2 / 5;

float y = 2.0 / 5;

float y = 2.0 / 5.0;

• If your code has methods (it's not just in static mode) or needs to run over time, it must have a draw() method, otherwise nothing will happen.
• Names of sketches cannot start with a number, or have spaces inside. this is mostly because of a restriction on the naming of java classes. I suppose if lots of people find this upsetting, we could add some extra code to unhinge the resulting class name from the sketch name, but it adds complexity, and complexity == bugs. :)
• Mind the capitalization of built-in functions. If a method or variable name is two words, usually the first word is lowercase and the first letter of the second word will be capitalized. For instance: keyPressed, movieEvent, mouseX, etc. If you have a function called mousepressed(), it won't be called when mouse events occur, because it needs the capital P on 'pressed'.
• If you get a "ClassCastException" when trying to run your code in a browser, you're probably trying to run non-Java 1.1 compliant code. This means any classes that didn't exist in java 1.1. Or, if if you're exporting as applet, variables that are 'final int' need to be 'static final int', otherwise they'll have trouble on a maching that only has Java 1.1 installed (i.e. running Microsoft's Java on Windows). You should also avoid using "final" variables inside of methods, since those aren't supported by Microsoft's VM (and that's the one most widely installed).
• On Mac OS X, the error message: ## Component Manager: attempting to find symbols in a component alias of type (regR/carP/x!bt) is not something from processing, it is a bug in Roxio Toast 5.2's Video CD Support extension. To suppress the messages, move "Toast Video CD Support.qtx" out of /Library/QuickTime (at least until you need to do Video CD work).
• On Windows, sometimes your programs will run in a window that has a Java coffee cup icon, instead of the usual Processing icon. This simply means that the application is being run outside of Processing as an external application. This happens when extra libraries, multiple source code files (more than one tab), or extra code files in the 'code' folder are employed.
• mouseX and mouseY always even (or always odd) numbers? By default, Windows 2000 (and XP?) seems to skip every other pixel on the screen, causing weirdness for some drawing applications done with Processing. If you're seeing this, you can fix it by visiting Control Panels → Mouse → Pointer Options → Enhance pointer precision. (This was actually tracked down by someone else in the community, whose name I have misplaced. if it was you, please drop me a line so you can be properly cited. This kind of help is huge for us, since we're such a small group!)

• You must make sure that "QuickTime for Java" is installed. To install it, you need to download it from apple.com/quicktime/download. If you install the version "with iTunes", there's a second step. After the installation, go to Start Menu → QuickTime → QuickTime Updater. When it runs, use the "Custom" install, scroll down, and click the checkbox next to "QuickTime for Java" and then install. If you install the version of QuickTime without iTunes, you'll also need to use the "Custom" install, as outlined above. You will also need to follow this process if you have already installed QuickTime, and did not use the "Custom" or "Full" install.
• Tt appears that QuickTime 7 breaks Processing video because Apple has decided to move the location of some files (specifically qtjava.zip). Stick with Quicktime 6.5.2.
• In order for camera input to work, you'll need to install a QuickTime-compatible video digitizer (VDIG). Unfortunately, most cameras on Windows don't support QuickTime right off the bat, but we've had reasonable luck with WinVDIG.
• If you're still having trouble, sometimes a full uninstall/reinstall of Quicktime will do the trick.
• If you're having trouble with video examples crashing processing or locking up your system, you should try placing the processing folder into the root level of your C:\ drive, or at least inside a set of folders that have no spaces in the name. We haven't determined if this is a QuickTime for Java or Processing bug yet, but it's been a problem for lots of people.
• Video sometimes likes to crash the application completely on Windows. This seems to be due to problems with QuickTime for Java (since we shouldn't be able to write code that crashes using Java.. heh right), so these situations are probably outside of our control.

• On Mac OS X 10.2 (jaguar, or jagwyre if you like black turtlenecks), QuickTime for Java was missing from the initial release of QuickTime 6.4 on the mac. An upgrade to QuickTime 6.4 that includes qtjava is available from software update. Better yet, ou can also upgrade to Mac OS X 10.3 (panther) which doesn't have this problem.
• If you get the following error: Exception in thread "main" java.lang.NoClassDefFoundError: com/apple/mrj/macos/carbon/CarbonLock then it means you need to update and/or reinstall QuickTime. There was some monkey business about QuickTime for Java updates being out of sync with the Apple's Java updates, and this is one of the leftovers of that scenario. Blame Apple. Blame Canada.

• Video performance is not particularly great. The library is simply not built (and Java is not currently capable) of moving around 640x480 video on most machines, much less doing analysis on the video. The library was intended as a way to get pixels and manipulate them (either small pixel buffers interactively, or large ones for non real-time use). There are better tools for real-time, large screen analysis. It is my estimate that a 2x performance increase can probably be obtained by making better use of the QuickTime for Java library, but this still won't be enough to do analysis of 640x480 pixels at 30 frames per second, so it remains a lower priority. As always contributions are welcome, in case you're a video hacker who wants to help improve the library.
• Projects that use video cannot (currently?) be exported to the web. (Bug 44)

• If you're using a program to check to see if the serial port is working, then it won't be available to Processing. That means that if you're using HyperTerminal or whatever to see if your serial device is working, then you need to quit out of that application before using that port with Processing.
• Serial.list() will only list the ports that are currently available. So if you have a program that's using the serial port that you want to use for your Processing sketch, it's not going to be available, or even listed.
• If you get an error reading something like this:
  
  WARNING: RXTX Version mismatch
  Jar version = RXTX-2.0-4
  native lib Version = RXTX-2.1-7pre17
  
  java.lang.ClassCastException thrown while loading gnu.io.RXTXCommDriver
  
  java.lang.UnsatisfiedLinkError: Native Library /Applications/processing-0090/libraries/serial/library/librxtxSerial.jnilib already loaded in another classloader
  
  then you probably have another copy of RXTX installed somewhere. This is a messy thing to straighten out, because it could be anywhere in your PATH or CLASSPATH. Search your drive for RXTXcomm.jar or simply comm.jar. Files that might cause trouble are libSerial.jnilib (on Mac OS X), libSerial.dll (Windows), jcl.jar, and javax.comm.properties. (contributed by stendahl)

• We use rxtx (version 2.1_6) to handle serial I/O, which is included with the Processing release. If this is the first time you're using rxtx, you'll need to make your way to the "libraries" folder, find "serial", and inside, and run macosx_setup.command (double-click it and follow the instructions). This will make sure that things are properly set up (a few permissions need to be changed).
• If you're getting a "serial port is already in use by another application" it's possible that you haven't run this script. On my machine, I installed the keyspan driver for my usb-serial converter, ran the script, and then rebooted in order for things to work (a reboot does the body good). In the past, i've used a keyspan 28X dual port adapter, and Serial.list() returns things like /dev/cu.USA28X21P1.1. You'll probably have something similar. Don't mind the frightening names.
• Tom Igoe was kind enough to note that you'll be in a world of hurt if you disconnect your serial adapter while a sketch is running—it'll prolly freeze the machine and require a forced reboot. This scenario may seem unlikely,(while this may seem nutty, you might run into it if your adapter is plugged into your usb keyboard, and you have the keyboard plugged into a monitor/keyboard switcher).
• The OS X 10.4 (Tiger) installer wipes out your permissions and groups on /var/spool/uucp, so you'll have to run the setup command again. However, running it returns:
  
  check_group_uucp(): error testing lock file creation Error details: Permission deniedcheck_lock_status: No permission to create lock file.
  
  Tom Igoe's extremely technical solution: “After you have run the macosx_setup.command, Shut down the machine and restart.
  
  “Don't logout then log back in. Don't just restart. Shut down and restart. I don't care that you've got a record uptime you're trying to preserve. SHUT DOWN AND RESTART! Don't be an idiot like I was. This will free up the old lock files, which apparently carry over from the previous systems, and your serial devices will be happy.
  
  “And on that note, Tiger and Processing are playing happily together with a serial port, like kittens with a ball of string.”

• Linux also uses rxtx-2.1_6 (just like Mac OS X). If you're having trouble getting things to run, i.e. the port menu stays grayed out or you get error message spew to the console when starting the application saying "Permission denied" and "No permission to create lock file", this is because you probably need to add yourself to both the uucp or lock groups so that processing can write to /var/lock so it doesn't get in a fight with other applications talking on the serial port.
• Alan Kilian contributes this description:
  1. I did an ls -l /dev/ttyS0 and saw that the group was set to uucp.
  2. Then I edited /etc/groups, I found the uucp group, and I added my login ID to the uucp line.
  3. I logged out, and logged back in again.
  4. The "groups" command now showed I was in group uucp, and when I started processing, the serial port menu item was not greyed-out.
  It's important that you're in both groups, and that you completely log out and log back in again.
• Running processing as root will often get rid of the errors, but that's obviously not a good solution for a million reasons (among them: beta code that runs as root and handles files? yeah great...)

• The default renderer as of beta uses Java 2D. It's more accurate than the renderer used in alpha, but is super slow for handling pixels. At least until we get a chance to get the old 2D renderer working in a similar fashion, you can use size(w, h, P3D) instead of size(w, h) which will be faster for general pixel flipping madness.
• To get access to the Java 2D "Graphics2D" object for the default renderer, use:

  Graphics2D g2 = ((PGraphics2)g).g2;

  This will let you do Java 2D stuff directly, but is not supported in any way shape or form. Which just means "have fun, but don't complain if it breaks."

• We don't recommend running other OpenGL programs while running Processing in OpenGL mode. GL tends takes charge of things so results will be unexpected (windows from the other app showing through to the Processing window, etc.)
• Objects with alpha (lines or shapes with an alpha fill or stroke, images with alpha, all fonts) are displayed in OpenGL based on their drawing order. This creates some annoying effects like making things opaque if they're drawn out of order with objects above or beneath them. This is simply how OpenGL works, but is something that we'd like to develop a workaround for in the future. Currently, you should just try to draw things back-to-front as best as possible.
• OpenGL is really memory hungry because of how tetxures work. In OpenGL mode, your images as the next power of two larger in either direction. This means an image that's 40x190 pixels will be stored as a 64x256 pixel x 4 bytes per pixel array (along with the original image storage being width x height x 4). This is probably something we can optimize in the future, however no attempt will be made until the surrounding code is debugged.
• OpenGL sketches cannot be exported to run in a browser. The export probably won't give an error, but they won't run properly. It's not clear whether this is something that we can fix for the future.
• OpenGL requires Java 1.4 or later.
• If you're getting this error on Windows: "net.java.games.jogl.GLException: Unable to enumerate pixel formats of window using wglGetPixelFormatAttribivARB: 0" and your machine has built in "Intel" graphics (this is the case for many Dell machines, for instance) you may just need an updated version of your driver, which can be found here. Of course, read the page closely and make sure that you in fact have this graphics chipset on your machine before installing. Thanks to Daniel Shiffman for finding this fix.
• On Mac OS X, I don't think there's much we can do about the following error: Error: view not ready, cannot lock focus at "/Users/kbr/JavaNet/jogl/src/native/jogl/ MacOSXWindowSystemInterface.m:createContext:51" that shows up sometimes on Run. Just hit Run again and things oughta work. This may be our bug, but who knows. "Cannot lock focus" bug on OS X is fixed for Processing release 93, thanks to toxi for tracking it down as fixed with a new JOGL release.
• On Windows, if you're getting a lot of OpenGL crashing, blue screens, or other mess, your driver might be bad. For instance, if you're using a Dell, use the driver they provide (support.dell.com) instead of what might be a more recent driver obtained directly from nvidia.com.
• To get access to the GL object, you can use the following:

  GL gl = ((PGraphicsGL)g).gl;

  This will give you the jogl object that talks directly to OpenGL and will let you make OpenGL calls directly. Note, however, that this is not supported, in the sense that if you get weird problems with a GL-based sketch that uses this method, you're on your own. Processing is not intended as a nice wrapper on top of OpenGL. Instead, we're using OpenGL graphics for one implementation of the Processing Core API.
  Because most of the work in drawing is handled by Processing, most OpenGL calls will not work, because the model and perspective matrices won't be set up properly. Therefore, using the GL object will mostly only be useful for tweaking obscure OpenGL parameters.

• A long sketch menu that goes off the edge of the screen? Doesn't scroll properly? There's not much we can do. This is a java issue which happens on most platforms. To get around it, you can organize your sketches into subfolders which will appear as submenus (be sure to quit before reorganizing, and then restart when finished).
• If you're seeing a sun.dc.pr.PRException, it's because you're trying to draw something that's waaaaay off screen (like an x coordinate of -100,000 or something nutty like that). (Bug 104)

• The system clock sometimes goes weird, especially when using framerate() or delay(). This is a long-standing bug with the Windows version of the Java VM. According to someone on the sun site: This bug has been fixed in bug no 4500388 and one requires a PRODUCT FLAG to use the fix. This flag and fix are available in 1.3.1_4, 1.4.0_2, 1.4.1 and 1.4.2. But for Java to actually use the fix:
  Open your Java Plug-in Control Panel in the section 'Java Runtime Parameters' just enter: -XX:+ForceTimeHighResolution
• Create Font sometimes crashes on Windows, bringing down the whole environment. This seems to be a Java bug, because it's not a Java exception, but a full crash. (Bug 99).
• An error starting with "hs_err_pid10XX.txt" sometimes shows up. This is something within the Sun's Java VM that we can't fix. It's not clear what the problem is, but it seems to have shown up with java 1.4.

• An error that reads something like 2005-05-19 14:20:44.209 java[875] _initWithWindowNumber: error creating graphics ctxt object for ctxt:72059, window:26969 is a known bug in Apple's Java implementation. (Bug 53)
• Sometimes something like the following will come up: *** malloc[438]: Deallocation of a pointer not malloced: 0xffffffff; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug it seems to be a bug in Apple's OS X Java. It doesn't appear to hurt anything but there also doesn't appear to be anything we can do to fix it. (Bug 52)

• The following message (or messages like it) on startup: Warning: Cannot convert string "-b&h-lucida-medium-r-normal-sans-*-140-*-*-p-*-iso8859-1" to type FontStruct. This is just a Java issue, but doesn't seem to affect things.

• Java 1.1 support has been (temporarily) removed from this release. We hope to bring it back, but it will take some time and we didn't want to hold up beta any longer. (Bug 125)
• The stop button sometimes doesn't stop things properly (especially when using libraries). Closing the window to shut things down usually works fine, though even that might lock up sometimes. Make sure you save your sketches before you run, in case you have to force-quit. If this happens to you, please post information about it at Bug 126.
• “Export to Application” remains unimplemented, though we're hoping to have it complete soon. (Bug 60)
• The get(), set(), blend(), loadPixels() and updatePixels() functions are fairly broken when using OpenGL. (Bug 91)
• The size of exported applets is larger than we would like, but we'll get things smaller and more optimize again. Having separated the 2D and 3D libraries, eventually we won't have to include the 3D code when using 2D. (Bug 127).
• println() can be super slow and often locks things up println() issues fixed for Processing release 93.
• Dragging the applet window around will often make Processing lock up Fixed in a recent release.
• 2D graphics might be a bit flickery sometimes, try setting the framerate() to get things under control (Bug 122)
• strokeWeight() is disabled in P3D and OPENGL. Not really a bug per se (how do you define a stroke in 3D?), but something we'd like to fix someday. (Bug 123)
• The placement of applets that are 100x100 is sometimes weird. (Bug 128)
• Sometimes things lock up when there are errors in code, for instance, when using libraries like OpenGL, video, or net. (fixed in the early 90s releases, please re-file a bug if you run into it)
• Errors sometimes don't come through, or are InvocationTargetExceptions, particularly on the Mac. (if this hasn't been fixed please re-file a new bug)
• int() and float() don't always work, use ((int) blah) or ((float) blah) instead for the time being. or toInt(blah) and toFloat(blah). (Bug 4)
• pause() and framerate() aren't working with the video library
• The beloved(?) "History" function from previous versions is missing. In the meantime, "Archive Sketch" might be useful. (Bug 71)
• Need to complete the "Tools" menu, which will be a way for people to develop their own editor plug-ins. (Bug 124)
• When you have too many tabs, things get ugly (Bug 54)
• Save changes before quitting needs a "Cancel" button. (Bug 32)
• Error messages after you hit Run are often too long to read or too weird to understand (Bug 57)
• updatePixels() seems to stink on the Mac. It can sometimes cause the screen to not update properly, or for video to contain weird bands of mixed frames. Fixed in release 91.
• Lots of little UI things like proper focus or key shortcuts