Bug 688 : "Fatal exception occurred. Program will exit." when Processing is first started
Last modified: 2007-11-17 11:50



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2007-11-16 11:37
Trying to run the Processing IDE doesn't work. The first time (after a
clean reboot), and on a few other occasions, the program displays an error
when I try to run it:

"Fatal exception occurred. Program will exit."

Later calls fail silently.

The program actually runs - firing up Windows Task Manager displays
javaw.exe has launched and is taking around 20mb of memory - but it's never
actually displayed as it seems to be freezing during part of its
initialization process.

None of the solutions mentioned on the troubleshooting page worked or apply
to the issue. %classpath% and the other environment variables had no
apparent problems (they're now empty). I also have antialias turned off on
my gpu settings. My username only uses simple alphanumeric characters. I
have no virus scanning software running or any other crazy resident program.

I had java 1.5 installed. Tried running Processing without the /java folder
and it didn't work. Tried running the version that comes with java and it
didn't work. Tried updating to java 1.6 and running with it (java-less
version) and it didn't work. I now have java completely uninstalled,
running Processing with the java version that comes with it (1.4), and it
still doesn't work. All tries were done with a new, recently decompressed
version of processing.

No log is generated since the program doesn't even seem to start (the IDE
never shows up).

System: Windows XP, 2gb mem, AMD 3700+, nvidia 8600GT. Drivers are all

Release used is 0133 beta. 0131 and 0132 also give me that problem.

Any clues? I've ran Processing previously without a problem on PC and Macs,
but this problem is baffling me.
Additional Comment #1 From fry 2007-11-17 01:36
unfortunately, i haven't a clue. (but thanks for the very thorough bug
report--it covers everything i need.) we've been getting more reports like
this but haven't been able to track down the problem.

part of the problem is that it's not a processing error--it's something
being created by windows, so it's tough to know where it's happening.

do you have non-ascii characters in your username? do you have several
lines of text in your PATH environment variable? (or your QTJAVA
environment variable?)
Additional Comment #2 From zeh 2007-11-17 05:57
Thanks a lot for the reply, fry. I know you must get a lot of clueless bug
reports, and I'm afraid mine is a bit like so, but I'm also interested in
getting this solved.

It is definitely some windows specific problem: I'm running linux on the
same computer (by way of VirtualBox) and it runs Processing flawlessly.

I'm done a few other tests: version 0124 and 0127 won't work either. Also,
I tried manually installing the java version (1.4.2_16-b05, the one that
comes with Processing is 1.4.2_12-b03) and it still won't start.

%qtjava% is empty now (I removed it manually after the first few attemps to
run Processing didn't work); the same goes for for %classpath%.

My username is pretty straightforward and contains no strange characters
("C:\Documents and Settings\zeh\..."). I also think path won't cause much
trouble; it has around 260 chars, all normal folders.

While the ide won't start, Processing *is* creating some temporary folders
on %temp%: for example,
"untitled14644.tmp/sketch_071117a/sketch_071117a.pde", while the sketch
itself is a file with 0 bytes.

Is there any way to turn on some kind of 'verbose' debugging? To see where
it's freezing. Other java applications seem to be working normally.
Additional Comment #3 From zeh 2007-11-17 06:27

Ok, good news: deleting my per-user preferences file ("C:\Documents and
Settings\(myusername)\Application Data\Processing\preferences.txt") fixed
it. Now Processing runs, either with the java version that comes in with
it, or with the java version I have installed on my system. The IDE shows
up and apparently everything works.

I have a copy of the old preferences.txt file here, so I did a comparison
of them. There's a number of different options, but from some testing, the
one that's causing trouble seems to be this line:

editor.font=Andale Mono,Monospaced,plain,12

I certainly don't remember editing this config option, nor any other
processing option on those preference files before. But on the other hand,
it should have been set by me somehow, someday, because Andale Mono *is*
the font I use for coding.

Anyhow, whoever did this poor job of font selection did it wrong, because
the list is not a list of possible fonts to use, but rather a list in the
"fontname, style, size" format. Having one option added breaks the editor
and make it not work anymore.

The solution was to replace it by a valid list, like the original one:


Or my own preferences:

editor.font=Andale Mono,plain,12

Now it works.

So I guess I'm the one at fault here, although I really don't remember
editing it. And if I did edit it, I should have ran the editor to make sure
it was working.


But I guess deleting the personal preferences file should also work on a
few other cases when pde won't run, in case preferences.txt has been
tampered with.
Additional Comment #4 From fry 2007-11-17 07:02
do you set any sort of system-wide preference that controls what mono font
you're using? or perhaps did you mess with the java font properties to set
the monospaced font to andale mono?

the only two possibilities i see are that 1) you/someone edited the file
and forgot, or 2) that java is returning "Andale Mono, monospaced" as the
font name, which conflicts with the commas being used for the other stuff.

to test #2, it might be worth checking to see if setting the font to andale
mono in your preferences.txt, then open processing, change the font size
(so that the prefs are rewritten) and then quit & check the contents of the
prefs file.
Additional Comment #5 From zeh 2007-11-17 08:43
I tested with #2 and it managed to properly save the new text file. So all
in all #1 is more likely; I may have assumed it was a list of fonts to be
used instead because of my familiarity with HTML (where it allows you to
declare a list of fonts you want it to test in case some isn't found on the
client machine).

So it's not a Processing error; at worst, it's just that it's putting too
much faith on the content of the user's preferences file.

In retrospect I think it was a bit of an stupid thing to check everything
else before checking the preferences file. It's that I didn't even think it
was saving something like it and kept trying new versions thinking they'd
be "fresh". Which makes it even more strange that I don't remember editing it.

I'm probably getting old and going slightly crazy. But really thanks, Fry,
it's working now. Sorry for taking your time.
Additional Comment #6 From fry 2007-11-17 11:50
k, closing bug.