Bugzilla – Full Text Bug Listing
| Summary: | Data race on org.eclipse.jdt.internal.compiler.impl.CompilerOptions.tolerateIllegalAmbiguousVarargsInvocation | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Yilong Li <yilong.li> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana, stephan.herrmann |
| Version: | 4.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
(In reply to Yilong Li from comment #0) > The race is probably harmless since both threads will write the same value > to this field (right?). But isn't it better to initialize this field inside > a static block? I agree. Jay, this initializer was introduced for bug 383780. Any objections to changing it to static? Do we have tests that dynamically change the system property (asking because that's the only thing I could imagine getting broken by the proposed change)? (In reply to Stephan Herrmann from comment #1) > Jay, this initializer was introduced for bug 383780. Any objections to > changing it to static? Do we have tests that dynamically change the system > property (asking because that's the only thing I could imagine getting > broken by the proposed change)? No objections. I only know the history through the discussion in that bug, but as per bug 383780, comment #43, the initializer was supposed to be static. But looks like that suggestion didn't make it to the repo. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
A dynamic race detector outputs a race report on the static field CompilerOptions.tolerateIllegalAmbiguousVarargsInvocation when testing against I-Build I20150811-1400: Data race on field org.eclipse.jdt.internal.compiler.impl.CompilerOptions.tolerateIllegalAmbiguousVarargsInvocation: {{{ Concurrent write in thread T58 (locks held: {}) ----> at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.<init>(CompilerOptions.java:455) at org.eclipse.jdt.core.dom.CompilationUnitResolver.getCompilerOptions(CompilationUnitResolver.java:303) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:678) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1190) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:812) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:551) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:543) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:486) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:476) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:157) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(OverrideIndicatorLabelDecorator.java:132) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.decorate(OverrideIndicatorLabelDecorator.java:260) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:260) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:83) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:367) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:349) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:367) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:327) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) T58 is created by T29 at org.eclipse.core.internal.jobs.WorkerPool.jobQueued(WorkerPool.java:148) Concurrent write in thread T36 (locks held: {Monitor@6bfb4e3}) ----> at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.<init>(CompilerOptions.java:455) at org.eclipse.jdt.core.dom.CompilationUnitResolver.getCompilerOptions(CompilationUnitResolver.java:303) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:678) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1190) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:812) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:551) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:543) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:486) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:172) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:157) - locked Monitor@6bfb4e3 at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:156) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) T36 is created by T29 at org.eclipse.core.internal.jobs.WorkerPool.jobQueued(WorkerPool.java:148) }}} The race is probably harmless since both threads will write the same value to this field (right?). But isn't it better to initialize this field inside a static block?