Community
Participate
Working Groups
Hello, While using AspectJ I admitted that when I use around advice and some exception occurs in the inner code - the line numbers in the stack trace for the code which is in the around() are incorrect. Also I didn't find any bugs on you tracker for this, but I found this -> http://stackoverflow.com/questions/14762142/eclipse-debug-stepping-with-aspectj. I use LTW. <weaver options="-verbose -Xreweavable -showWeaveInfo"> Am I doing something wrong? Is it a bug? (Is it possible to fix it?)
For inlined around advice we should be properly implementing SMAPs but we are not, these are for situations where the byte code originates from multiple source files. The around advice copied into a target class should have SMAP entries that point to the aspect. If your around advice is *not* being inlined, it should behave better from a debugging point of view. Which is yours doing? You can force inlining off with -XnoInline in the options section. If you have a piece of code demonstrating your particular case that would be helpful, but if it needs SMAPs that has just been on the list a long time and I've not gotten to it.
I have added option -XnoInline and I see no difference in stacktraces. Lines which correspond to original method names are wrong ( it prints ClassName.methodName(ClassName.java:1). But lines with names like: ClassName.methodName_aroundBody0 show real line numbers. What do you mean under "byte code originated from multiple source files"? Is it inheritance? (only it?)
> "byte code originated from multiple source files"? public class A { public void m() {} } public aspect X { void around(): execution(* A.m(..)) { System.out.println(); proceed();} } If those are two source files, when you compile them with AspectJ the around advice code is inlined into the target class A.class. So you have A.class containing code from two source files. In that situation you need to create a Source Map for A.class that says "this bit comes from that source file and this other bit comes from that other source file". Without a source map attribute it will assume all code comes from A.java - so it'll be wrong for the println() byte code in A.class. > Lines which correspond to original method names are wrong ( it prints ClassName.methodName(ClassName.java:1). Yes, that does sound like a bug. If you did have a testcase that demonstrates your exact scenario, that'd be helpful.
Andy, sparked by https://stackoverflow.com/q/69019973/1082681, I easily reproduced this problem, both in cases when the target method of an around advice throws an exception and when the advice itself does. If I can present you with a reproducer or a series of automated tests, can you take time to add SMAPs? I am not sure if I could do that by myself, never having dealt with anything like that before. Feel free to contact me in Slack.
In my simple test case, compiling with '-XnoInline' helps, and the stack traces in both cases - around advice throwing exception and target method throwing it - look better, except for the strange line numbers of *_aroundBody methods.
I'm not sure the support for fiddling with SMAPs is complete in AspectJ, so there is a bunch of work here. Let's do some digging... Per my comment here in 2005: https://github.com/eclipse/org.aspectj/blob/eef058c4c5a70359a35da51b77e638a57126081f/weaver/src/main/java/org/aspectj/weaver/bcel/LazyClassGen.java#L555 I think the relevant attribute SourceDebugExtension was built with some old half baked format in those days that debuggers didn't like, so I turned it off. It needs to be constructed using the SMAP format as defined in the spec (there is an example in there): https://download.oracle.com/otndocs/jcp/7844-debugging-1.0-prd-spec-oth-JSpec/ Possibly the InlinedSourceFileInfo object in the LazyClassGen could be adjusted to be more correct and more agreeable to serialization as SMAPs. the addInlinedSourceFileInfo method in LazyClassGen is mentioned in this commented out code: https://github.com/eclipse/org.aspectj/blob/eef058c4c5a70359a35da51b77e638a57126081f/weaver/src/main/java/org/aspectj/weaver/bcel/BcelShadow.java#L2254 you can see the beginnings of what needs to happen here. From that call in BcelShadow made in the weaveAroundInline it is trying to add that knowledge that 'this stuff from this class file got inserted here so remember that so we can construct a debug attribute later'. So the skeleton of what needs to happen looks to be there, just commented out and outdated (although I'm sure the devil is in the detail). I won't have time to work on this in the near future.
