This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 226083 - Dereferencing possible null pointer false positive
Summary: Dereferencing possible null pointer false positive
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 7.4
Hardware: All All
: P1 normal with 2 votes (vote)
Assignee: Svata Dedic
URL:
Keywords:
: 244345 244424 (view as bug list)
Depends on:
Blocks: 256485
  Show dependency tree
 
Reported: 2013-02-13 18:30 UTC by mklaehn
Modified: 2015-11-10 14:26 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Another false positive (16.92 KB, image/png)
2013-11-22 20:56 UTC, markiewb
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mklaehn 2013-02-13 18:30:16 UTC
if there is a construct like the following


Rectangle r = new Rectangle(4, 3);
double area;
boolean should = null != r;
if (should) area = r.get|Height() * r.getWidth();
else area = 0d;

The mentioned hint is shown; Same if the condition in the if is somewhat more complex i.e. ((null != x) && should)
Comment 1 Jelloman 2013-03-18 19:08:29 UTC
I was going to report the following, but it looks like the same bug.

In the following code, the "Dereferencing possible null pointer" warning is given on the toString() call, when clearly it is not possible.

    void testMethod(Object in, final boolean flag) {
        Object x = flag ? in : null;
        if (flag) {
            String xStr = x.toString();
        }
    }

(If I replace the declaration of x with "Object x = in;" then the warning goes away.)
Comment 2 tkellerer 2013-09-24 21:20:10 UTC
I think this is the same situation:

int pos = table != null ? table.indexOf('@') : -1;

if (pos > 0)
{
   // the following line is marked as "Dereferencing possible null pointer"
   String part = table.substring(pos); 
   ....
}
Comment 3 markiewb 2013-11-22 20:56:52 UTC
Created attachment 142500 [details]
Another false positive
Comment 4 rptmaestro 2014-05-30 12:21:01 UTC
Here is another simplified example

public class Main {

    public static void main(String[] args) {
        Object obj = getObject();
        boolean isOkay = obj != null;
        if (true) {
            obj.toString();
        }
    }

    public static Object getObject() {
        return "something";
    }
}

All of the cases where this false positive is recorded share one fundamental thing in common. They all check whether the object is non-null *before* using that object in the body of an "if" statement. If this check is never done, the false positive disappears. If the check is performed in the clause of the "if" statement, it also disappears.

It seems very odd that this false positive should only appear *after* specifically checking whether the object is non-null.
Comment 5 Svata Dedic 2014-06-06 14:25:22 UTC
(In reply to rptmaestro from comment #4)
> It seems very odd that this false positive should only appear *after*
> specifically checking whether the object is non-null.

Because it's not known whether a method's parameter *is* actually intended to contain a null value (and reporting each dereference would produce a ton of false positives), reports are suppressed *unless* the variable is checked for null-ness. If the developer writes the check, it is a sign that the parameter might eventually contain null and so all possible NPEs should be reported.
Comment 6 Svata Dedic 2014-06-06 14:56:38 UTC
The example shown in comment #0 no longer produces a hint in dev build (most possibly fixed in the meantime).

Re. comment #1 and #3: the current analyzer implementation cannot correctly handle this situation. It would have to be changed not only to track possible-null flag for each value, but for each such null/not-null flag, a condition(s) would be present which are known to be true at the time of the value creation.

A very nice enhancement - but rather complex.

The example given in comment #2 is most probably a WONTFIX problem; it's similar but requires the analyzer to understand even non-reference values dependencies on (not)null condition; sorry.

Comment #4 requires a non-local analysis; each method would need to be analyzed if it possibly produces a null value and that possibility would be taken into account when analysing method call sites. It is very hard to tell the result if method's parameter (or obtained references) are not checked for null - every ref can be eventually null, so each method (except some specific ones, as used in the example) MAY return null.
I would rather not implement such thing.
Comment 7 Svata Dedic 2014-06-06 14:59:36 UTC
*** Bug 244424 has been marked as a duplicate of this bug. ***
Comment 8 Svata Dedic 2014-06-06 21:21:11 UTC
*** Bug 244345 has been marked as a duplicate of this bug. ***
Comment 9 Svata Dedic 2015-07-24 07:05:34 UTC
Situation in comment #1 and comment #3 is addressed by code being developed for #249320

*** This bug has been marked as a duplicate of bug 249320 ***
Comment 10 Svata Dedic 2015-11-10 12:33:33 UTC
The experimental implementation covers example in the report and comment #1 - I've used the examples in unit tests.

Reopening to track progress in dev version.

I filed an enhancement that covers example in comment #4 (issue #256485)
Comment 11 Svata Dedic 2015-11-10 14:26:39 UTC
Fixed in experimental impl, unit test provided. Monitor the umbrella issue for the actual commit.