Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

starting scope of let bindings seems incorrect from jdi perspective

Description

It appears like the clojure compiler doesn't get the starting scope of let bindings right from the java debug interface perspective.

The compiler sets the starting scope of a local to the let/loop body, rather than to immediately after the local is bound. So when you are stepping through a let statement in a debugger, you can't eval the already defined bindings until you get to the let body.

Because it is a compiler problem, you see the symptoms with any jdi based debugger, (I've confirmed this on both jdb and cdt.)

The fix is pretty straightforward. Just gen.mark() a label after each binding is emitted and use that in the gen.visitLocalVariable() call instead of the loopLabel. I've attached a patch for clojure 1.2 branch. (If there is interest I'll create one for clojure master.)

Environment

None

Attachments

1

Activity

Show:

Stuart Halloway March 5, 2011 at 3:21 AM

Feb 26 patch is good

George Jahad February 26, 2011 at 6:39 PM

fixed to use HashMap of labels

Rich Hickey February 25, 2011 at 3:40 PM

Yes, it is weird to mutate bindinginit with emit-related info. Better to keep a map of bindinginit->label inside doEmit, please.

Stuart Halloway February 22, 2011 at 11:29 PM

Rich: does this need to be rewritten so that BindingInit is a value, or is the mutation of startScope ok?

Patch works against master.

George Jahad January 31, 2011 at 6:41 PM

To test: start clojure with a jdi port, (like 8050 below)
java -agentlib:jdwp=transport=dt_socket,address=8050,server=y,suspend=n -cp /Users/georgejahad/incoming/clojure-1.3.0-alpha4/clojure.jar clojure.main

Then start jdb and attach to that port like so:
jdb -attach 8050

Set a breakpoint on pmap from jdb:
stop in clojure.core$pmap.invoke

Invoke pmap from the clojure repl:

(pmap inc (range 6))

From jdb, step over the first line of pmap, (that binds the local n):
next

From jdb, try to print the just bound local:
print n

Without the patch, you'll see:
com.sun.tools.example.debug.expr.ParseException: Name unknown: n
n = null

With it, you should see n equal to the correct value:
n = 4

Completed

Details

Assignee

Reporter

Approval

Ok

Priority

Affects versions

Fix versions

Created January 30, 2011 at 10:45 PM
Updated March 11, 2011 at 4:21 PM
Resolved March 11, 2011 at 4:21 PM