Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320284

Summary: race condition on getProblemArgument
Product: [Tools] CDT Reporter: Tomasz Wesolowski <kosashi>
Component: cdt-codanAssignee: CDT Codan Inbox <cdt-codan-inbox>
Status: NEW --- QA Contact: Elena Laskavaia <elaskavaia.cdt>
Severity: normal    
Priority: P3 CC: cdtdoug, eclipse.sprigogin
Version: 7.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Some stderr logging on CodanProblemMarker [not to be commited] none

Description Tomasz Wesolowski CLA 2010-07-19 11:34:05 EDT 
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.
Comment 1 Tomasz Wesolowski CLA 2010-07-19 11:35:14 EDT 
Created attachment 174636 [details]
Some stderr logging on CodanProblemMarker [not to be commited]

This patch helps to illustrate the problem.
Comment 2 Tomasz Wesolowski CLA 2010-07-19 12:14:09 EDT 
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.
Comment 3 Elena Laskavaia CLA 2010-07-19 13:34:56 EDT 
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.