14.1.2 EAP Grails debugging issues

Answered

Hi,

The 14.1.2 EAP versions bring some very welcome fixes and changes for Groovy / Grails development but the new forked debugging support seems to have some issues still.

I am upgrading a Grails application to 2.5.0 and it seems that the non-forked execution is a no-go at the moment so forked debugging is coming just at the right time for me - and I have re-enabled the forked startup in my run configuration.

However the debugger doesn't always attach itself.

In the console log I see:

Listening for transport dt_socket at address: 65414


And in the debugger:

  • Connecting to the target VM, address: '127.0.0.1:65414', transport: 'socket'


However, in many cases, no connection is made. I have no idea yet, why sometimes it works and sometimes it doesn't.

Switching JDK versions doesn't make a difference, restarting the IDE doesn't help either.

I'm using MacOS 10.10.3, IntelliJ is running on the provided custom-built 1.8.0-40 JDK runtime version.

An option to switch to shared-memory for the debugger is unfortunately not available, otherwise I would have tried that.

Any ideas, any extra information which I can provide to help figuring out this issue?

Is it something stupid which I'm doing wrong?

Is anyone else seeing this?

Kind regards,

--Tim

8 comments
Comment actions Permalink

Hi,
Do you have any settings within run configuration i.e. "VM options" ?
Do you have any non-default settings in BuildConfig?

0
Comment actions Permalink

In the VM Options there was a line:

-DcontextIDEA=true

To disable non-forked debugging conditionally on a property. I have now changed this to:

-DNOTcontextIDEA=true

So that forked debug is enabled again.

The BuildConfig.groovy file, which I have partially inherited from another developer, reads at the top:

    delete(file: "$stagingDir/WEB-INF/lib/intellij-grails-rt.jar", failOnError: false)
}

// tag::idea-conf[]
if
(System.properties['contextIDEA']) {
    grails.project.fork = false
} else {
// end::idea-conf[]
    
grails.project.fork = [
            // configure settings for compilation JVM, note that if you alter the Groovy version forked compilation is required
            //  compile: [maxMemory: 256, minMemory: 64, debug: false, maxPerm: 256, daemon:true],

            // configure settings for the test-app JVM, uses the daemon by default
            test
: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, daemon: true],
            // configure settings for the run-app JVM
            run
: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, forkReserve: false],
            // configure settings for the run-war JVM
            war
: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, forkReserve: false],
            // configure settings for the Console UI JVM
            console
: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256]
    ]
}

(Amongst many other things that look more standard).

The debugger is able to attach some of the times, but not other times. This is what's puzzling me.


Let me know what other things I might need to provide.

--Tim

0
Comment actions Permalink

Oh, I see

IDEA syncs settings without passing "-DcontextIDEA=true". So in your case the condition "System.properties['contextIDEA']" is always false and IDEA thinks you have forked execution settings enabled.

So just remove that "contextIDEA" stuff from run configuration and from BuildConfig. It should work.

-- Daniil

0
Comment actions Permalink

No, as I said, I have CHANGED that to a different property name, thus the forked execution is triggered.

In fact, I should have answered earlier but didn't realize it then, that I'm getting the same problem on a Grails test project which I created today, which contains no strange stuff in the BuildConfig.groovy (just 2 or 3 extra plugins), contains no VM Options, nothing strange, and consists of only 5 classes.

Thus any accumulated cruft in the other project is of no relevance.

Sorry, I should have thought of that when I answered your earlier post, would have avoided confusion.

Kind Regards,

--Tim

0
Comment actions Permalink

Could you please attach you test project?

0
Comment actions Permalink

Sure.

Please don't pay attention to the actual classes too much, I was trying to reproduce a bug in the larger project within a small and controlled environment, but it's a nice and small project without much cruft that nevertheless has issues with debugger attaching.

I have also attached two console logfiles, one where debugger can, and one where it cannot attach.

The difference here is that I could reproduce the problem when Grails first had to perform compilation, and when the app is already compiled, there seems to be no problem.

However that is not the behaviour I have observed in the main application project - perhaps due to it's bigger size, and it's use of an actual real database, startup of that project takes longer and Grails does more work during startup. This might be a clue - the startup time of the Grails environment before it forks the process which is to be debugged.

In that project, it is unpredictable in any given state if the debugger can or cannot attach. I usually have all code compiled with grails compile before running the app.

Kind regards,

--Tim



Attachment(s):
log-debugger-cannot-attach.txt.zip
log-debugger-can-attach.txt.zip
GrailsConstraintsTest.zip
0
Comment actions Permalink

Thank you for test project and logs! I am able to reproduce the bug now.
As you guessed it was because the forked process startup takes much time.
It will be fixed ASAP

Please follow the ticket https://youtrack.jetbrains.com/issue/IDEA-139524
-- Daniil

0
Comment actions Permalink

Hi Daniil,

Thank you very much, I will be tracking the issue and I hope that a fix can be released really soon!

I've been having some really weird issues with Grails internals over the last couple of weeks and not being able to reliably step through code with a debugger has really been an extra hindrance.

Kind regards,

--Tim

0

Please sign in to leave a comment.