Community
Participate
Working Groups
There seems to be a weird problem in getProblemArgument when used by isApplicable in quick fixes. Reproduce: 1. Apply patch: attachment 174577 [details] from bug 309760 (ProblemBindingChecker) 2. Apply 3 first patches from bug 319196 (quick fixes) 3. Apply patch from the first attachment here (some console logging in getProblemArgument) 4. Run Eclipse CDT, create new project with a single C++ file with following code: int foo() { } 5. Inside the function body, type "someName" (without quotes) and wait 1 second; observe output console in Eclipse. The function getProblemArgument will print some info on each call, approx. 1 second after changing the name. "Problem argument requested: 1 of 2" indicates correct behaviour, the problem argument is retrieved "Problem argument requested: 1 of 0" indicates that no problem arguments can be retrieved from the problem marker, which is incorrect (and would lead to AIOBE being thrown right afterwards). You can replicate this several times by erasing and retyping the last letter of the name, waiting ~1 second every time for the message to appear in the console window. 6. Go to org.eclipse.cdt.codan.internal.core.model.CodanProblemMarker.getProblemArgument(IMarker, int) Uncomment the commented code at the beginning of this function (with Thread.sleep). Repeat step 5. The delay introduced there apparently causes the problem to cease to appear. My guess is that this would indicate a race condition somewhere.
Created attachment 174636 [details] Some stderr logging on CodanProblemMarker [not to be commited] This patch helps to illustrate the problem.
Returning an empty string from that method if problem arguments cannot be retrieved from marker would probably be a functioning workaround, but the problem would still lurk there.
When you typing it triggers checker which would delete and re-create markers. Are you doing something in parallel which accesses the marker it may be a problem.
