Processing version 1.01
Mac OS X 10.5.6, Mac/Intel Powerbook

// bug_saveFrame_noLoop
//
// this program illustrates a Processing bug
// in the following situation:
// (1) using OPENGL
// (2) after calling "noLoop()"
// (3) call "saveFrame()"
// this crashes the program with this error:
// Invalid memory access of location 00000000 eip=96cac314

import processing.opengl.*;

void setup() {
size(400,400,OPENGL);
println("To test this Processing/OPENGL bug, ...");
println("(1) press 'n' to call noLoop()");
println("(2) press 's' to call saveFrame()");
}

void draw() {
fill(random(0,255));
ellipse(random(0,width),random(0,height),8,8);
}

void keyPressed() {
if (key == 'n') {
println("noLoop()");
noLoop();
} else if (key == ' ') {
println("loop()");
loop();
} else if (key == 's') {
println("saveFrame()");
saveFrame("frame.tif");
println("saveFrame success");
}
}

edit]
Processing example illustrating bug: OPENGL / noLoop / saveFrame

The bug occurs with OPENGL / noLoop / saveFrame.
It does not occur when using default Processing rendering option (whatever that
is).

I have not explored whether anything other than OPENGL causes the bug
(e.g., JAVA2D, P2D, P3D, etc.)

edit]
bug also occurs with "loadPixels()"

this program further illustrates the bug occurs with both:
saveFrame() and loadPixels()

This is an extension of what's in the noLoop() reference:

"When noLoop() is used, it's not possible to draw to the screen inside
event handling functions such as mousePressed() or keyPressed()."

I've added a clarification to the reference to say that you simply cannot
do anything that affects or makes use of the screen when noLoop() is in use.