From 5d5a5841c820a26bbaa7ceb393d0e8ce1ca09ad4 Mon Sep 17 00:00:00 2001 From: David Fokkema Date: Tue, 15 Apr 2014 20:50:30 +0200 Subject: [PATCH 1/4] Do not wait for debugger to start running sketch By default, the java VM is started with options for attaching a remote debugger. The sketch is suspended until the remote debugger connects. This always succeeds the first time a sketch is run. At least on OS X 10.9, this seems to be very fragile, and successive runs of the sketch often fail to start. This commit tells the VM to *not* wait for the debugger before starting the sketch. Fixes processing#2402 --- app/src/processing/mode/java/runner/Runner.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/src/processing/mode/java/runner/Runner.java b/app/src/processing/mode/java/runner/Runner.java index 9bea617b5..887266d6e 100644 --- a/app/src/processing/mode/java/runner/Runner.java +++ b/app/src/processing/mode/java/runner/Runner.java @@ -133,7 +133,7 @@ public class Runner implements MessageConsumer { // String jdwpArg = "-Xrunjdwp:transport=dt_socket,address=" + portStr + ",server=y,suspend=y"; // String debugArg = "-Xdebug"; // Newer (Java 1.5+) version that uses JVMTI - String jdwpArg = "-agentlib:jdwp=transport=dt_socket,address=" + portStr + ",server=y,suspend=y"; + String jdwpArg = "-agentlib:jdwp=transport=dt_socket,address=" + portStr + ",server=y,suspend=n"; // Everyone works the same under Java 7 (also on OS X) String[] commandArgs = new String[] { Base.getJavaPath(), jdwpArg }; From fd40dbfb314be31ccc6205ceb1ccf412554609c0 Mon Sep 17 00:00:00 2001 From: David Fokkema Date: Fri, 18 Apr 2014 21:11:05 +0200 Subject: [PATCH 2/4] Revert "Do not wait for debugger to start running sketch" This reverts commit 5d5a5841c820a26bbaa7ceb393d0e8ce1ca09ad4. --- app/src/processing/mode/java/runner/Runner.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/src/processing/mode/java/runner/Runner.java b/app/src/processing/mode/java/runner/Runner.java index 887266d6e..9bea617b5 100644 --- a/app/src/processing/mode/java/runner/Runner.java +++ b/app/src/processing/mode/java/runner/Runner.java @@ -133,7 +133,7 @@ public class Runner implements MessageConsumer { // String jdwpArg = "-Xrunjdwp:transport=dt_socket,address=" + portStr + ",server=y,suspend=y"; // String debugArg = "-Xdebug"; // Newer (Java 1.5+) version that uses JVMTI - String jdwpArg = "-agentlib:jdwp=transport=dt_socket,address=" + portStr + ",server=y,suspend=n"; + String jdwpArg = "-agentlib:jdwp=transport=dt_socket,address=" + portStr + ",server=y,suspend=y"; // Everyone works the same under Java 7 (also on OS X) String[] commandArgs = new String[] { Base.getJavaPath(), jdwpArg }; From c46c34c033955b022c7aa57590d7bda41e54c6be Mon Sep 17 00:00:00 2001 From: David Fokkema Date: Sat, 19 Apr 2014 10:09:10 +0200 Subject: [PATCH 3/4] Another 'fix': added a timeout before vm.resume() I think we have a race condition: vm.resume() is called *before* the VM is actually ready to resume. That is strange, since the debugger is attached, eventQueues are set up and ready... Still, waiting for a bit ensures that the VM actually resumes. This behavior was not present when Java 1.6 was still used. Is this a bug in Java 1.7? Or is it simply that the VM in 1.6 started up quickly enough to hide the race condition? I'll continue looking... --- app/src/processing/mode/java/runner/Runner.java | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/app/src/processing/mode/java/runner/Runner.java b/app/src/processing/mode/java/runner/Runner.java index 9bea617b5..dbee59be1 100644 --- a/app/src/processing/mode/java/runner/Runner.java +++ b/app/src/processing/mode/java/runner/Runner.java @@ -710,6 +710,12 @@ public class Runner implements MessageConsumer { errThread.start(); outThread.start(); + try { + Thread.sleep(1000); + } catch(InterruptedException ex) { + Thread.currentThread().interrupt(); + } + vm.resume(); // Shutdown begins when event thread terminates From e3090697e4e92586bb85b3bf32541b066773bea7 Mon Sep 17 00:00:00 2001 From: David Fokkema Date: Sat, 19 Apr 2014 10:36:00 +0200 Subject: [PATCH 4/4] Wait for VMStartEvent before resuming VM Fixes processing#2402 (Oh, yes!) --- app/src/processing/mode/java/runner/Runner.java | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/app/src/processing/mode/java/runner/Runner.java b/app/src/processing/mode/java/runner/Runner.java index dbee59be1..314e37f0d 100644 --- a/app/src/processing/mode/java/runner/Runner.java +++ b/app/src/processing/mode/java/runner/Runner.java @@ -678,7 +678,9 @@ public class Runner implements MessageConsumer { for (Event event : eventSet) { // System.out.println("EventThread.handleEvent -> " + event); - if (event instanceof ExceptionEvent) { + if (event instanceof VMStartEvent) { + vm.resume(); + } else if (event instanceof ExceptionEvent) { // for (ThreadReference thread : vm.allThreads()) { // System.out.println("thread : " + thread); //// thread.suspend(); @@ -710,14 +712,6 @@ public class Runner implements MessageConsumer { errThread.start(); outThread.start(); - try { - Thread.sleep(1000); - } catch(InterruptedException ex) { - Thread.currentThread().interrupt(); - } - - vm.resume(); - // Shutdown begins when event thread terminates try { if (eventThread != null) eventThread.join(); // is this the problem?