Bug 262509 - [plan] Debugger exception when breakpoint triggered at the beginning of a method with before advice
Summary: [plan] Debugger exception when breakpoint triggered at the beginning of a met...
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.6.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.6.4   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-27 02:04 EST by Vladimir Piskarev CLA
Modified: 2009-01-27 13:56 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Piskarev CLA 2009-01-27 02:04:31 EST 
Build ID: M20080911-1700

Steps To Reproduce:
Consider a class:

1 class Foo {
2    int i = 3;
3    void foo(Bar bar) {
4      i = 33;
5      ...

Let's apply some before advice to Foo#foo:

aspect FooAspect {
   before() : execution(* *(..)) {
   ...

Let's set a breakpoint at line 4. When the breakpoint is triggered, the call stack looks like:

<unknown receiving type>.foo(Bar) : line 4
....

and no variables are displayed, while the debugger raises com.sun.jdi.InternalException: Got error code in reply:35
occured retrieving 'this' from stack frame.

More information:
Go a Step Over and the call stack and the variables look correct.
Comment 1 Vladimir Piskarev CLA 2009-01-27 06:08:57 EST 
This bug was split out from bug 262146.
Comment 2 Andrew Clement CLA 2009-01-27 12:20:57 EST 
interesting.  This seems like a regression - I'm sure the debugger used to work fine for this simple case.
Comment 3 Andrew Clement CLA 2009-01-27 13:56:20 EST 
Ah well, it is fixed now.  The local variables representing 'this' and the parameters are adjusted to start from the beginning of the method when before advice is applied at method-execution.  I've rebuilt an AJDT privately and confirmed debugging is ok.  I have a slight concern whether there is a performance impact for this reworking of the local variables, but it certainly isn't anything obvious in the testing I've done.