I've had it happen many times but I just ignored it or sometimes just uploaded again to make sure, either way it doesn't seem to be a error message that causes any problems, nor does it seem to be based on any error in the sketch code.
"It hurts when I look at the output and see an error".
So don't look...
Well, I've been seeing this message for ages as well. But it really isn't great in terms of building confidence in the Arduino IDE. Not only does it keep distracting me and wondering whether I need to upload again just to rule out a problem while chasing my own bugs, I think it also sends out the wrong message when this bug pops up since at least version 0011 and no-one seems to be doing anything about it.
Agreed, jcw, it's a flaw that should be investigated. Should have been investigated for some time now.
The error reporting mechanism often drops errors (only showing "In function foo():" but no error text), and often fails to collect any output at all (only showing "Couldn't determine program size").
It seems like the IDE is not properly getting the stdin/stdout handles of the spawned build process, and since it's more flaky on a platform that has a lot of dual-core machines, I'm putting money on a race condition of some kind: the routine returns but the returned handles aren't really ready yet.
Thanks for following up - I don't know enough about the IDE to help with tracking this down, unfortunately. Maybe the race condition could be worked around with a short sleep/delay of some sort... somewhere...
Best of luck on this one - race conditions can be very hard to track down.
(Edited: or even to repeat the call if it failed the first time?)
How you patch an installed Arduino IDE is platform dependent. I can't figure out how to tweak the classpath on OS X, but I suspect it involves hacking the Info.plist in the .app. If someone figures this out, please reply back with instructions.
Windows users can probably unzip this into the directory (you may have to create it) referred to in the run.bat (this same directory is also known to the Arduino.exe.)
I don't know where you put it for Linux.
In a nutshell: unzip this file into a location that is before any of the Arduinbo jarfiles on the CLASSPATH, making sure to preserve the path. Restart Arduino.
I'll post the code back to the right place once I convince myself my approach is sane. I'm essentially using Thread.join() to force the IDE to wait for the stdout/stderr threads to be setup until trying to start the avr-size process. Under the right circumstances the MessageSiphon threads would not even be near complete by the time the avr-exit command has exited.
We really ought to switch to Java 5 and ProcessBuilder for this
Ok, done. I can confirm that without the patch, I get occasional errors when doing dozens of compiles with cmd-R (the most common one is right after starting up), whereas with your patch the problem NEVER showed up. Done many many dozens of tests and at least a dozen re-launches.
It's not conclusive, but yeay - IMO you've nailed it.
Next step: dear Mr. Mellis, please consider including this patch for 0016...
Thanks for squashing the bug (as far as I can tell - Mac OS X 10.5.6, Core 2 duo).
Hmm. An initial naive pass at the messaging stuff in Compiler does not indicate that the same fix will address this. The output is just not there. This is not the same race condition. More debugging will have to be done. I'll try again later this week.
I have this problem 100% of the time--it sucks. i can't get anything onto the board. Someone mentioned a patch, i tried it, but i couldn't get it working--how do you get the patch to work? does it work? i'm at a loss here--help would be much appreciated.