This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (3)
- # announcements (12)
- # beginners (80)
- # boot (3)
- # braveandtrue (16)
- # calva (3)
- # cider (82)
- # clojure (100)
- # clojure-art (3)
- # clojure-dev (79)
- # clojure-estonia (1)
- # clojure-europe (4)
- # clojure-finland (15)
- # clojure-indonesia (1)
- # clojure-italy (20)
- # clojure-nl (4)
- # clojure-spec (24)
- # clojure-sweden (2)
- # clojure-switzerland (1)
- # clojure-uk (99)
- # clojurescript (145)
- # cursive (8)
- # data-science (7)
- # datomic (26)
- # emacs (4)
- # figwheel-main (20)
- # fulcro (8)
- # graphql (3)
- # hoplon (2)
- # jobs (1)
- # kaocha (5)
- # leiningen (2)
- # liberator (19)
- # off-topic (16)
- # pathom (9)
- # perun (1)
- # portkey (2)
- # re-frame (17)
- # reitit (1)
- # shadow-cljs (26)
- # spacemacs (7)
- # vim (49)
Debugging under JDI seems to be broken because of a change in the behaviour of DynamicClassLoader.
I’ve been working with the debugger guy at JetBrains, and he said: > For some reason java.lang.Object is not reported as visible from the DynamicClassLoader used in evaluation, so jdi method args types checks fail. In 1.09 it does not happen. Definitely some changes in 1.10 trigger that.
I’ve asked him for some clarification on what exactly he means by “not visible”, but he’s inconveniently asleep.
Looking at the change history, there were only two changes to the DCL in 1.10, one making a change for CLJ-1550 and the other reverting it, so AFAICT it shouldn’t have changed. Could there be something with the bytecode changes that affect how it responds?
other than the update in min jdk / asm, can’t think of anything else that changed
@cfleming you can test that bytecode theory by testing before and after the change, which was.... beta4?
@ghadi Ok, I’ll try that, hopefully that doesn’t overlap the range where the DCL had actually changed.
@ghadi any possibility of the custom getCommonSuperClass() being related?
Ok, I can probably do a bisect on 1.10 versions actually, it’s relatively quick to test, but I’ll try alpha4/alpha5 first.
I don't know @alexmiller, but that call is only called during bytecode emission, not runtime
yeah, I can’t construct a theory of how it would be in play, just thinking of the edge stuff
That might affect this - when evaluating expressions, I construct an
fn, compile it and invoke it.
The problem is that Egor reproduced the problem, but I don’t have any more information from him than just that message from earlier.
@ghadi First bad commit is 38705b49fd3dbae11e94c576ef49ff3eb1c47395, which is the getCommonSuperClass change.
Looking at it, that also seems to be the commit when opcodes were changed from 1.5 to 1.8, so it’s possible that change affected something else, i.e. that causes JDI to work differently with the newer bytecode version.
@ghadi Was that the main commit which changed the bytecode version, or was the version also changed in other places in other commits?
and asm bump happened in two separate commits due to a bug in the first version of the asm library
1650f9c2546a6fc71c8d74b29e18547d6696fc54 "CLJ-2367 Incorporate ASM merge request 189 and add case tests" right before the alpha6 release
yeah, alpha 5 broke something for us, as I recall and that was my patch to apply the fix from the ASM project to the ASM code in Clojure... so we went from alpha 4 to alpha 6...
I just brought it up because it changes the asm library which emits bytecode. but it happened after alpha5 which you say is already broken for debugging. so it appears to be after the root cause anyways
Yeah - I can’t see where that commit changes the asm lib, but it’s definitely after the root cause anyway.
it adjusted one of the asm files itself:
CLJ-2367 Incorporate ASM merge request 189 and add case tests Signed-off-by: Stuart Halloway <[email protected]> 2 files changed, 9 insertions(+), 2 deletions(-) src/jvm/clojure/asm/commons/GeneratorAdapter.java | 8 ++++++--
Ok, I’ll ask Egor about those two changes, and I’ll get some detail from him to repro the problem myself.
I’m not sure I have the knowledge of the gory bits of JDI to understand it, but I’ll see what he says.
dpsutton you're muddling the issue... the asm bump had a minor emission bug the first time around
I think the thing to look at is how the compiled bytecode differs before/after
That getCommon... is used for computing stack maps so maybe there is something weird with those. the before doesn’t have stack maps as those were added after the old bytecode version
I did actually do a fair amount of bytecode diffing before/after trying to catch anything obvious
@ghadi has a script to revendor asm - could just revendor to latest and see if it works
The issue is that JDI doesn’t load the Object class - I got that far, basically the debugger loops endlessly on expression evaluation since it receives a ClassNotLoadedException. JDI normally takes care of that, so I guess JDI doesn’t like the class for some reason. I don’t understand how the DCL interaction happens though.