Troubleshooting "unverified breakpoint"

[jamiejackson]

I did a workshop with my team yesterday, so they could get their IDEs working with our new Lucee docker image with the luceedebug java agent baked in.

One colleague couldn't get his breakpoints working. When VS Code connected, the breakpoint hollowed out, and mousing-over gave "unverified breakpoint."

We double-checked the IDE paths, and the container paths were the same as the rest of ours, but no luck.

Do you have any tips for troubleshooting this?

[Leftbower]

I am having this same issue. The CALL STACK frame gets populated with everything "RUNNING" but otherwise nothing. I am running on Commandbox and using the following JVM args:

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=test.dev.local:9999,
-javaagent:c:/dev/luceedebug/luceedebug.jar=jdwpHost=test.dev.local,jdwpPort=9999,cfHost=test.dev.local,cfPort=10000,jarPath=c:/dev/luceedebug/luceedebug.jar

where test.dev.local is the hostname bound to 127.127.0.3 in my Windows hosts file (via Commandbox's host updater module). Not sure what I'm doing wrong?

[softwareCobbler]

This should be improved with 9e52507aef214809698418badc2772ef8cedd3f8. We wait for lucee.runtime.Page to get loaded before we start listening for its subtypes (as in, the files we want breakpoints in) to be loaded, but there was a race between time-of-load-of-lucee.runtime.Page and time-of-load-of-subtypes. It seems we often lost this race, missing out on some of the earliest user classes (generally those loaded from the precompiled class disk cache immediately after server startup).

Some of this could also be the reuse of cached classfiles from previous Lucee runs, where those classfiles were not compiled with source path information. Lucee by default doesn't bake absolute source file paths into class files, so it's possible there are old classfiles lying around that don't have the info we need. Maybe there is a Lucee-centric way to blow away the entire classfile cache? That might also clear up additional instances of this problem.

A 3rd culprit could be there's nothing to bind a breakpoint to, which is maybe surprising in the tag portion of the following:

<cfscript>
    // this line won't ever bind a breakpoint, it has no executable code
    if (foo == 42) { // this line can bind a breakpoint
      ...
</cfscript>
<cfoutput>
   <div><!--- this line won't bind a breakpoint, it has no executable code, just text ---> </div>
    <cfif foo EQ 42> <!--- this should accept a breakpoint --->
      ...
</cfoutput>

[jamiejackson]

I haven't tried the new commit yet, but here's some extra info.

When my colleague was experiencing the issue:

• It was in the context of a fresh docker container, so there would have been no old class files.
• I had him set breakpoints on some known-good lines for breakpoints (ones I had used before while I was testing luceedebug).

I also started having the same problem this evening. Soon after, I had to quit for the day so I wasn't able to dig into it.

[jamiejackson]

I tried again with the latest and it's working so far. More info about "Unverified Breakpoints" in #13.

I'll ask my colleague to try again.

[jamiejackson]

@Leftbower, your issue may be the agent configuration.

Try starting with this, verbatim. (Notice that only the jar locations have been changed from the stock example):

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=localhost:9999
-javaagent:c:/dev/luceedebug/luceedebug.jar=jdwpHost=localhost,jdwpPort=9999,cfHost=0.0.0.0,cfPort=10000,jarPath=c:/dev/luceedebug/luceedebug.jar

If that works, lock down cfHost more and optionally configure cfPort, but those are the only things you need to touch. You can leave all of the jdwp stuff alone--most people probably will, unless they already have something running on 9999.

For future reference, the cf* param names might get deprecated soon (#6), but don't worry about that right now.

Update: Removed an errant space character. Also, try some other windows path syntaxes if that doesn't work.

[jamiejackson]

Just had my colleague update to the latest and he's good now!

@Leftbower , since your issue is different (unable to connect the VS Code debugger to the agent), I'm going to close this ticket, but please create a new ticket and/or reach out on Slack (the cfml team's #lucee channel) if you still have trouble after trying the previous suggestion.