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.
All I can say is: get the patch from post #7, unzip it, follow the instructions in #10, and make sure you end up with what is mentioned in #11. That's what I did, and that's what worked for me.
I'm a bit worried by @The Clever Monkey not responding for a request to provide the corresponding source code changes - I hope a solution like this does make it into the next release...
To be sure, this annoyance will never keep a sketch from being compiled and uploaded to any device. It is merely coincidence that one is seeing the "Couldn't determine program size" message at the same time. But it is unrelated.
I haven't posted the patch because I have not had time to really look at my changes and then cook up a proper patch. I'm hoping to have some time this week to do that.
It may be that my patch is completely bogus, and I've just moved the race condition around, or made the hole smaller.
o: In function main': C:\DOCUME~1\Family\LOCALS~1\Temp\build25321.tmp/Temporary_8204_6203.cpp:39: undefined reference to setup'
Couldn't determine program size: C:\Documents and Settings\Family\My Documents\Arduino\arduino-0015-win\arduino-0015\hardware/tools/avr/bin/avr-size: 'C:\DOCUME~1\Family\LOCALS~1\Temp\build25321.tmp\Knight_Rider.hex': No such file
and i have no "info.plist" so... uhhh... yeah. any help with this?
You simply have a bug in your sketch. The IDE couldn't determine the program size because the compilation failed and no "program" was generated. This is not the same issue.
You're apparently missing the setup() function definition.