cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lujie (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-10356) Fix Some Potential NPE
Date Sun, 15 Apr 2018 05:57:00 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

lujie updated CLOUDSTACK-10356:
-------------------------------
    Description: 
We have developed a static analysis tool [NPEDetector|https://github.com/lujiefsi/NPEDetector] to
find some potential NPE. Our analysis shows that some callees may return null in corner case(e.g.
node crash , IO exception), some of their callers have  _!=null_ check but some do not have.
In this issue we post a patch which can add  !=null  based on existed !=null  check. For
example:

Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:
{code:java}
protected GslbServiceProvider lookupGslbServiceProvider() {
    return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may return null;
}
{code}
Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have _!=null_:
{code:java}
private boolean checkGslbServiceEnabledInZone(long zoneId, long physicalNetworkId) {

   GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
   if (gslbProvider == null) {
      throw new CloudRuntimeException("No GSLB provider is available");
   }

   return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
}
{code}
but another GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does not
have !=null check:
{code:java}
GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,physicalNetworkId));
.........{code}
So we will add below code in non-(!=null) caller GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig
{code:java}
if (gslbProvider == null) {
    throw new CloudRuntimeException("No GSLB provider is available");
}
{code}
But due to we are not very  familiar with CLOUDSTACK, hope some expert can review it.

Thanks!!!!

  was:
We have developed a static analysis tool [NPEDetector|https://github.com/lujiefsi/NPEDetector] to
find some potential NPE. Our analysis shows that some callees may return null in corner case(e.g.
node crash , IO exception), some of their callers have  _\!=null_ check but some do not
have. In this issue we post a patch which can add  !=null  based on existed \!=null  check.
For example:

Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:

 
{code:java}
protected GslbServiceProvider lookupGslbServiceProvider() {
    return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may return null;
}
{code}
Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have _!=null_:

 
{code:java}
private boolean checkGslbServiceEnabledInZone(long zoneId, long physicalNetworkId) {

   GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
   if (gslbProvider == null) {
      throw new CloudRuntimeException("No GSLB provider is available");
   }

   return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
}
{code}
but another GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does not
have !=null check:

 

 
{code:java}
GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,    
physicalNetworkId));
.........{code}
So we will add below code in non-(!=null) caller GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig 

 

 
{code:java}
if (gslbProvider == null) {
    throw new CloudRuntimeException("No GSLB provider is available");
}
{code}
But due to we are not very  familiar with CLOUDSTACK, hope some expert can review it.

Thanks!!!!

 

 


> Fix Some Potential NPE 
> -----------------------
>
>                 Key: CLOUDSTACK-10356
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10356
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.12.0.0
>            Reporter: lujie
>            Priority: Major
>
> We have developed a static analysis tool [NPEDetector|https://github.com/lujiefsi/NPEDetector] to
find some potential NPE. Our analysis shows that some callees may return null in corner case(e.g.
node crash , IO exception), some of their callers have  _!=null_ check but some do not have.
In this issue we post a patch which can add  !=null  based on existed !=null  check. For
example:
> Callee GlobalLoadBalancingRulesServiceImpl#lookupGslbServiceProvider:
> {code:java}
> protected GslbServiceProvider lookupGslbServiceProvider() {
>     return _gslbProviders.size() == 0 ? null : _gslbProviders.get(0);// may return null;
> }
> {code}
> Caller GlobalLoadBalancingRulesServiceImpl#checkGslbServiceEnabledInZone have _!=null_:
> {code:java}
> private boolean checkGslbServiceEnabledInZone(long zoneId, long physicalNetworkId) {
>    GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
>    if (gslbProvider == null) {
>       throw new CloudRuntimeException("No GSLB provider is available");
>    }
>    return gslbProvider.isServiceEnabledInZone(zoneId, physicalNetworkId);
> }
> {code}
> but another GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig does
not have !=null check:
> {code:java}
> GslbServiceProvider gslbProvider = lookupGslbServiceProvider();
> siteLb.setGslbProviderPublicIp(gslbProvider.getZoneGslbProviderPublicIp(dataCenterId,physicalNetworkId));
> .........{code}
> So we will add below code in non-(!=null) caller GlobalLoadBalancingRulesServiceImpl#applyGlobalLoadBalancerRuleConfig
> {code:java}
> if (gslbProvider == null) {
>     throw new CloudRuntimeException("No GSLB provider is available");
> }
> {code}
> But due to we are not very  familiar with CLOUDSTACK, hope some expert can review
it.
> Thanks!!!!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message