Community
Participate
Working Groups
I20100907-0800 Steps to reproduce: Checkout the following projects. dev.eclipse.org:/cvsroot/rt:org.eclipse.equinox/framework/bundles/org.eclipse.osgi dev.eclipse.org:/cvsroot/rt:org.eclipse.equinox/framework/bundles/org.eclipse.osgi.tests In org.eclipse.osgi.internal.resolver.StateHelperImpl.getUnsatisfiedLeaves(State, BundleDescription[]) the compiler thinks there is deadcode which is not dead at all. if (satisfied == null) result.add(constraint); else if (!satisfied.getSupplier().isResolved() && !bundleList.contains(satisfied.getSupplier())) bundleList.add(satisfied.getSupplier()); The compiler thinks the variable satisfied will ALWAYS be null. But the code above the if check obviously has paths that will allow satisified to be non-null. The compiler seems to remove the if AND else and only leaves the body of the if. This results in the call to result.add(constraint); even when satisfied != null! This causes a failure in the testcase org.eclipse.osgi.tests.bundles.PlatformAdminBundleTests.testUnresolvedLeaves01()
seems like a consequence of the fix for bug 133125. I'll investigate.
If you enable the deadcode check to be an error you will see another questionable error about deadcode in org.eclipse.osgi.framework.internal.reliablefile.ReliableFile.getInputStream(int, int) I'm not sure if that will result in the complete if (textIS != null) return textIS; to be removed from the bytecode. In this case I don't see any conditional statements, but there is a case statement which may be treated similarly?
(In reply to comment #2) > if (textIS != null) > return textIS; > > to be removed from the bytecode. In this case I don't see any conditional > statements, but there is a case statement which may be treated similarly? I think this one is a duplicate of bug 292478.
Tom, I don't want to ask for a rebuild today as the problem is still under investigation. By tomorrow, we will decide if I ask for a rebuild with both patches reverted or if we can ask for a rebuild with a fix of the existing code. My current understanding is that both patches are only exposing an existing bug. So reverting them doesn't really solve the problem. This would only hide it. Do you want a rebuild today ?
(In reply to comment #4) > Do you want a rebuild today ? I think we should wait for a proper fix. I am going to revert to last weeks build in the meantime.
Smaller test case that seems to cause the same warning: public class X { void foo(Object[] tab, boolean b) { Object o = null; for (int k = 0; k < tab.length; k++) { o = b ? tab[k] : null; // if (b) { // o = tab2[k]; // } else { // o = null; // } } if (o == null) System.out.println("null"); else if ("".equals(o)) System.out.println("empty"); } } If you uncomment the if statement and comment the conditional expression, the problem is gone.
(In reply to comment #3) > (In reply to comment #2) > > if (textIS != null) > > return textIS; > > > > to be removed from the bytecode. In this case I don't see any conditional > > statements, but there is a case statement which may be treated similarly? > I think this one is a duplicate of bug 292478. This I can confirm. With the fix for bug 292478 I see nothing bogus in ReliableFile. Unfortunately, the problems in StateHelperImpl are of different nature. The first suspicious diagnostic I'm seeing is here: BaseDescription satisfied = null; if (constraint instanceof BundleSpecification || constraint instanceof HostSpecification) { BundleDescription[] suppliers = state.getBundles(constraint.getName()); for (int k = 0; k < suppliers.length && satisfied == null; k++) satisfied = constraint.isSatisfiedBy(suppliers[k]) ? suppliers[k] : null; } The occurrence of satisfied within the for-condition is flagged as can only be null. I'll investigate.
There is indeed a close relation to bug 292478 comment 13, which *almost* fixed this issue, too. Bug 292478 comment 15 has an update which fixes an isolated test case modeled after this bug. Still one combination fails in conditional expressions: unknown or null. I'll quickly check if changing the int from enum-semantics to bitset- semantics will help to fully resolve this. If a quick solution is required, reverting bug 133125 should be the fastest and cleanest solution.
Bug 292478 comment 16 contains my last patch for today. With this patch org.eclipse.osgi compiles with no complaints about dead code. I still see 16 issues re redundant null checks & assignments, but those I checked look correct to me. Sorry for any trouble caused by previous patches!
(In reply to comment #9) > Bug 292478 comment 16 contains my last patch for today. > With this patch org.eclipse.osgi compiles with no complaints about dead code. > > I still see 16 issues re redundant null checks & assignments, but those > I checked look correct to me. > > Sorry for any trouble caused by previous patches! Thanks Stephen. The final fix for bug 292478 addresses this bug. So closing.
I verified that this is fixed in the latest I-Build. Thanks! One thing to note, you must rebuild your workspace to ensure all the old .class files are thrown away and rebuilt using the fixed compiler.
