Java trace is not always successful

[rbeezer]

A significant percentage of the time (25% - 50%?) I get a "bad" trace for a small-ish Java program, the other times the trace is fine. (I've manually added unthoughtful line breaks to make the original final line readable here.)

 allTraceData["sieve-codelens-java"] = com.sun.jdi.VMDisconnectedException
       at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:304)
       at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1036)
       at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:69)
       at com.sun.tools.jdi.JDWP$VirtualMachine$Suspend.waitForReply(JDWP.java:570)
       at com.sun.tools.jdi.JDWP$VirtualMachine$Suspend.process(JDWP.java:556)
       at com.sun.tools.jdi.VirtualMachineImpl.suspend(VirtualMachineImpl.java:408)
       at traceprinter.VMCommander.run(VMCommander.java:44)
{"code":"public class SievePrimeFactors  {\n   public static void main(String args[]) 
{\n      int num = 20;\n      boolean[] bool = new boolean[num];\n\n      
for (int i = 0; i< bool.length; i++) {\n         bool[i] = true;\n      }
\n      for (int i = 2; i < Math.sqrt(num); i++) {\n         if(bool[i] == true) 
{\n            for(int j = (i*i); j < num; j = j+i) {\n               bool[j] = false;\n            }\n         }\n      }\n      
System.out.println(\"List of prime numbers: \");\n      
for (int i = 2; i< bool.length; i++) {\n         if(bool[i]==true) 
{\n            System.out.println(i);\n         }\n      }\n   }\n}\n\n","stdin":"",
"trace":[{"line":"0","event":"uncaught_exception","offset":"0","exception_msg":"Success is null?"}],"userlog":"Debugger VM maxMemory: 444M\n"}

Input program is just lifted from some programming site, I forget if I made edits.

def SieveOfEratosthenes(n):
   # array of type boolean with True values in it
   prime = [True for i in range(n + 1)]
   p = 2
   while (p * p <= n):
      # If it remain unchanged it is prime
      if (prime[p] == True):
         # updating all the multiples
         for i in range(p * 2, n + 1, p):
            prime[i] = False
      p += 1
   prime[0]= False
   prime[1]= False
   # Print
   for p in range(n + 1):
      if prime[p]:
         print (p,end=" ")
# main
if __name__=='__main__':
   n = 20
   print ("The prime numbers smaller than or equal to", n,"is")
   SieveOfEratosthenes(n)

Hitting

http://tracer.runestone.academy:5000/tracejava

Is the program crappy? Server needs a fix? Any certain string I can reliably test for to handle failure for returned trace?

[bnmnetp]

Thats a Python program so I don' tthink that is it. 😄

I have seen these, and I have an exception to catch the timeouts in my code. With a message to try the build again. I think it would be better to catch the exception and just try the trace call again. I'm not sure what is causing this. The thing that generates the trace for Java is a docker run tracejava..... thing that I have treated as a black box.

It does not seem to happen for the C/C++ code (a different black box) or the Python code - which I more or less understand.

[bnmnetp]

Alternatively, I could catch that error in the server and retry if necessary.

[rbeezer]

Thats a Python program so I don't think that is it.

Ooops! I was wondering why I could read it. (I did use Java for years.)

I'm catching all Python exceptions from the server interaction (requests package). I don't think this is a timeout in the communication with the server? (It doesn't seem to take 30 seconds.) But this comes through as some non-empty text and the Java exception/errors aren't reported to the Python per se. So if the text has a predictable error message in it, I could trap it in the Python. But it seems, as you say, that requires some work on server-side plumbing?

[bnmnetp]

I think it is easiest to catch this error on my end and retry once or twice.

It may be that tracer is a little under powered at times (not on a Saturday) and oddly enough I can see that for C/C++ I have a loop that retries up to 5 times!! This is all very weird and involves code from several different groups. Such is the life of open source.

I added some debug and it looks like most Java traces take less than 3 seconds on the server. So retrying 5 times is not crazy.

It would be better to get to the root of the problem, but if a couple of retries makes this work that is far better than trying to study up on Java to figure out what the heck is going on with someone else's code...

And this is how the whole world of software engineering works.... Just keep piling up technical debt until you can't take it anymore.

[github-actions[bot]]

Stale issue message