next topic »

[Reply #15 on:]

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.

[Reply #16 on:]

Can you post the source to the patch?

[Reply #17 on:]

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

--Phil.

[Reply #18 on:]

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

[Reply #19 on:]

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.

[Reply #20 on:]

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

-jcw

[Reply #21 on:]

I have this problem 100% of the time--it sucks. i can't get anything onto the board.

Are you sure you have the same problem? AFAIK when this message is occasional it shouldn't stop code being uploaded (I think).

If it's happening all the time then and no code is being uploaded there might be another issue.

--Phil.

[Reply #22 on:]

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.

[Reply #23 on:]

@TCM - Great, didn't want to twist your arm.

FWIW, your patch definitely succeeded in getting the race condition out of my system - I've never encountered it since then. Thanks again.

[Reply #24 on:]

err... running windows,

this is my error message:

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?

[Reply #25 on:]

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.

[Reply #26 on:]

*facepalm*

(sorry for being so... inept with code. i hope this'll teach me a lesson =P )

[Reply #27 on:]

Here it is:

Code:

Index: Sizer.java
===================================================================
--- Sizer.java      (revision 567)
+++ Sizer.java      (working copy)
@@ -57,17 +57,26 @@
    
     commandSize[1] = buildPath + File.separator + sketchName + ".hex";
 
+        int rc = 0;
     try {
       exception = null;
       size = -1;
       firstLine = null;
       Process process = Runtime.getRuntime().exec(commandSize);
-      new MessageSiphon(process.getInputStream(), this);
-      new MessageSiphon(process.getErrorStream(), this);
+      MessageSiphon in = new MessageSiphon(process.getInputStream(), this);
+      MessageSiphon err = new MessageSiphon(process.getErrorStream(), this);
+
       boolean running = true;
+
       while(running) {
         try {
-          process.waitFor();
+              // Wait for the MessageSiphon threads
+              if (in.thread != null)
+                    in.thread.join();
+              if (err.thread != null)
+                    err.thread.join();
+                  
+          rc = process.waitFor();
           running = false;
         } catch (InterruptedException intExc) { }
       }
@@ -76,7 +85,7 @@
       // some sub-class has overridden it to do so, thus we need to check for
       // it.  See: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1166589459
       exception = new RunnerException(
-        (e.toString() == null) ? e.getClass().getName() : e.toString());
+        (e.toString() == null) ? e.getClass().getName() + rc : e.toString() + rc);
     }
    
     if (exception != null)

Thread.join() to help co-ordinate threads, though I think I still have not convinced myself that I haven't just moved the race condition to this class.

Some exception and info tweaks.

[Later]

Wait, I changed my mind.  This is exactly how we can solve this problem in a highly parallelized environment.  We should still mark this as a place where we can improve things with Java 5 ProcessBuilder which sidesteps all this thread output cruft.

[Reply #28 on:]

This is just to link in these other threads, which are about the same thing:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1242122448
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235432803
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1233044085
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1225145000

[Reply #29 on:]

I have to mention that the error, which I previously reported as fixed by this patch, actually still does occur once in a while (but only right after startup). So it does look like a race condition, which happens much less frequently - but hasn't been completely eradicated.

(still grateful, this situation is absolutely workable for me...)

-jcw