Occasional "Couldn't determine program size" error

Arduino-0012 Mac OSX 10.4.11 PPC

About 1 time in 10 I randomly get the following error while Verifying a sketch:

Couldn't determine program size:    text         data          bss          dec          hex      filename

Verifying again immediately after the error will work without any problems so it doesn't seem to be a critical bug. It's only annoying. :-/

It happens all the time and it doesn’t seem to be causing any problems :slight_smile:

I had the same problem but I solved... I didn't put void setup() and it didn't like it :P

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.

Just my ? .02 ...

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?)

Almost certainly a race condition, when I look at the offending code.

I never saw this on an iMac, but with a multi-core Mac Pro I get it every single time. An annoyance, for sure.

I'll try to look at this one this week-end.


Ok, try this patch (for Arduino-0015):


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 :)

Er, I guess I should have replied, instead of just adding to my last comment.

So: bump!

Great - here’s what I see on Mac OS X:



That’s in the file:
/Applications/arduino-0015/Arduino 15.app/Contents/Info.plist

Should I add a path, or … (I know nothing about Java) - please advise…


Ah foo. I messed up the patch. Grab another copy.

And then change Info.plist like:


Then, unzip the patch into Arduino 15.app/Contents/Resources/Java/lib/patch/

Can do - one more Q: so I end up with .../lib/patch/processing/app/Sizer.class, right?



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).


Thanks for this, it fixes it for me too (8 core mac pro).

Is there any chance that you could fix the problem with errors in .h files the same way?

Details: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235432803/0#0

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.

Can you post the source to the patch?

I think the patch is linked from post #7 in this thread.


I think the patch is linked from post #7 in this thread.

No, there is only a compiled java-class in the zip-file linked from there, there is no source-file for the patch. Eberhard

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.