Community
Participate
Working Groups
Created attachment 123720 [details] The .java file, the Instrumentation file and the compiled and decompiled version of the generated class Hello, I encountered a strange bug when I used AspectJ in my project: I have a class, called Test3---which I attached---and an aspect for synchronized blocks---Instrumentation.aj. After compiling with ajc, my advices are correctly placed, but there is a problem with the exception handlers. This happens for the second "after" advice---corresponding to the second synchronized object---, which, in case of an exception being thrown, it is handled by the exception handler corresponding to the first synchronized object, which can lead to deadlocks as the second "synchronized" object does not get released. If one looks at the Test.out, which is obtained using "javap -c -private Test3", and start examining the code at instruction 37, one can see that the instructions from 70 to 80, when both of the monitor objects are acquired have their exception handler the one that starts at line 137 which only deals with the first monitor object. Best regards, silviu
thanks for the detailed bug report. You didn't say you were using -Xjoinpoints:synchronization. The woven code is a bit too complicated to look through. It would be easier with less advice. Did you try with fewer advice and the problem would not happen? I presume it also happens with empty advice, so I don't need DImmunix to recreate the situation myself.
Hello, sorry about letting out the -Xjoinpoints:synchronization part. The bug manifests itself even with an empty advice. I used the following aspect to check. class Example{ public void handleAfter(Object who){ System.out.println("Handle before monitorenter("+who+")"); } } public aspect Instrumentation { Example example = new Example(); after(Object l): lock() && args(l) && !within(dImmunix.*) { // example.handleAfter(l); } } The example.handleAfter call is commented out, so it is an empty advice. Best regards, Silviu
I also made it just after() throwing advice to reduce the weaving further. The woven code is unfortunately still too complex - i doubt i'll get to this for 1.6.4.
I kind of imagine a similar problem could be created with just try/finally blocks and standard pointcuts (not lock()/unlock())
beginnings of some testcode committed for this in bugs164 - but doesn't recreate the issue yet
unsetting the target field which is currently set for something already released
