Community
Participate
Working Groups
Build ID: 3.5 Steps To Reproduce: I'm not sure why I didn't see this earlier, but if you register a tracing class via the DebugOptions#newDebugTrace(String, Class) API then the logic in the org.eclipse.osgi.framework.debug.FrameworkDebugTraceEntry class to dynamically find the caller of the tracing class will fail (the class and method will be 'null' while the line number will be 0). I will attach a patch that will correct this problem. More information: Please consider this patch for the 3.5.1 release of Eclipse.
Created attachment 143149 [details] possible solution
(In reply to comment #0) > I'm not sure why I didn't see this earlier I'm sure this is because of a lack of tests. We need to add more tests to /org.eclipse.osgi.tests/src/org/eclipse/osgi/tests/debugoptions/DebugOptionsTestCase.java Troy, could you provide a testcase that reproduces this issue?
(In reply to comment #2) > (In reply to comment #0) > > I'm not sure why I didn't see this earlier > > I'm sure this is because of a lack of tests. We need to add more tests to > /org.eclipse.osgi.tests/src/org/eclipse/osgi/tests/debugoptions/DebugOptionsTestCase.java > > Troy, could you provide a testcase that reproduces this issue? > Yep, I agree... which is disappointing for me as I do remember running manual tests on it. Obviously I missed this scenario. I created two additional tests to make sure this doesn't happen in the future and will attach it. The 'testTracingEntry01' test will make sure that the correct class and method are determined by mimicking the trace API by assuming that org.eclipse.osgi.tests.debugoptions.DebugOptionsTestCase#testTracingEntry01() is the caller to the trace API. The 'testTracingEntry02' test will make sure that the correct class and method are determined by mimicking the trace API by assuming that org.eclipse.osgi.tests.debugoptions.DebugOptionsTestCase is the trace class and that sun.reflect.NativeMethodAccessorImpl#invoke0() is the caller to the trace API. I could not think of better testcases considering that I'm not able to access the StackTraceElements that are created from the Exception in FrameworkDebugTraceEntry to verify that the right information is returned via FrameworkDebugTraceEntry#getClassName() and FrameworkDebugTraceEntry#getMethodName() (unless another Exception is created and we look at its results and compare?)
Created attachment 143168 [details] test patch
Created attachment 143182 [details] updated tests Your tests assume a Sun VM I think. Here is an updated test that inserts more classes on the stack so we can test against them instead of sun.* classes.
I released the fix and tests to HEAD for 3.6. John, could you review for 3.5.1?
Looks good to me. I stepped through the test cases and verified that the fix does the right thing.
Patch (fix and test) released to 3.5.1.
*** Bug 290229 has been marked as a duplicate of this bug. ***
