Bug 536647 - Nullpointer exception is thrown by NavigationHelper.getInverseReferences
Summary: Nullpointer exception is thrown by NavigationHelper.getInverseReferences
Status: RESOLVED FIXED
Alias: None
Product: Viatra
Classification: Modeling
Component: Query (show other bugs)
Version: 2.0.0   Edit
Hardware: PC Windows 10
: P3 major
Target Milestone: 2.0.1   Edit
Assignee: Zoltan Ujhelyi CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-03 09:56 EDT by Markus Gilg CLA
Modified: 2018-07-04 08:45 EDT (History)
4 users (show)

See Also:


Attachments
Ecore model used as test data (1.18 KB, application/octet-stream)
2018-07-03 09:56 EDT, Markus Gilg CLA
no flags Details
Test project (133.76 KB, application/x-zip-compressed)
2018-07-03 12:52 EDT, Markus Gilg CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Gilg CLA 2018-07-03 09:56:26 EDT
Created attachment 274774 [details]
Ecore model used as test data

I have noticed a NullPointerException when NavigationHelper.getInverseReferences is called:

java.lang.NullPointerException
	at org.eclipse.viatra.query.runtime.base.core.EMFBaseIndexInstanceStore.getFeatureKeysPointingTo(EMFBaseIndexInstanceStore.java:303)
	at org.eclipse.viatra.query.runtime.base.core.NavigationHelperImpl.getSettingsForTarget(NavigationHelperImpl.java:403)
	at org.eclipse.viatra.query.runtime.base.core.NavigationHelperImpl.getInverseReferences(NavigationHelperImpl.java:398)

I am calling this method to compute all objects referencing the given object.
The bug appears calling the method on an object which is not referenced by another object. If called with an object which is referenced, the method works fine.

Test setup consists of two resources containing one object each where one references the other (see attached cmcore.ecore for dummy test model). Configuration is plain default (Retebackend, no special flags set at all) but shouldn't influence the bug.

After taking a look at the code, i assume the bug is in the following method in class org.eclipse.viatra.query.runtime.base.core.EMFBaseIndexInstanceStore#getFeatureKeysPointingTo.
Patching the method
public Set<Object> getFeatureKeysPointingTo(Object target) {
        return getValueToFeatureMap().get(target).distinctValues();
}
with
public Set< Object > getFeatureKeysPointingTo(final Object target) {
        final IMultiset< Object > multiset = getValueToFeatureMap().get(target);
        if (multiset == null) {
            return Collections.emptySet();
        }
        else {
            return multiset.distinctValues();
        }
    }
seems to fix the problem. Also this kind of null check seems to have been added in similar methods like org.eclipse.viatra.query.runtime.base.core.EMFBaseIndexInstanceStore#getFeatureKeysPointingTo.FeatureData#getDistinctHoldersOfValue.

I assume the bug has been introduced in Viatra 1.7 with the switch to EclipseCollections, since the code is working with Viatra 1.6 and the collections used there return empty collection instead of null per default.

I flagged the bug as major, because this forces me to switch back to EcoreUtils#CrossReferencer or not use Viatra 2.0 (and therefor Eclipse Photon) but Eclipse Oxygen with Viatra 1.6.
Comment 1 Zoltan Ujhelyi CLA 2018-07-03 10:44:45 EDT
Thanks for the report, and sorry for the inconvenience caused by the update.

I tried to reproduce the issue, but when I tried to open the given Ecore model, I received the following two error messages: 
 * `Resource '/de.tesis.dynaware.common.model/model/Base.ecore' does not exist.`
 * `java.net.MalformedURLException: Unsupported "platform:" protocol variation "de.tesis.dynaware.common.model".`

Furthermore (assuming these errors can be safely ignored), I tried to find out what to do with the model, but the report was a bit unclear to me. It is possible that every required information is present and I have simply missed it, but I did not understand entirely what I have to do with the given example to reproduce the NullPointerException. Could you provide some more details, specifically:

 * How to open the test data correctly?
 * Exactly what operations are done on the model?
 * Exactly which model element should be queried/how?

It would help a lot to understand what happens here if some executable version could be shared, or at least you could provide a code snippet showing precisely the code you are trying to execute here. Thanks in advance.
Comment 2 Gabor Bergmann CLA 2018-07-03 11:44:10 EDT
Regardless of the reproducability, I can confirm that there really is a missing null check there, and the solution would be similar to what Markus is suggesting.
Comment 3 Markus Gilg CLA 2018-07-03 12:52:32 EDT
Created attachment 274779 [details]
Test project

I have added a test project for Eclipse Photon. The test NavigationHelperTest should reproduce the bug in a standalone setup, just run it as Junit test.
My environment was a standard Eclipse Photon vs. Running Platform but since the initial project was copied from the Viatra repository there shouldn't be any non-Viatra dependencies.

The model is taken from the Viatra examples, master branch, plugin org.eclipse.viatra.examples.cps.model. It was changed in that way, that the EOpposite entry from EReference applications has been removed (otherwise it works fine).
The test fails for me in line 68 where i request the references for the object hostInstance.
Comment 4 Eclipse Genie CLA 2018-07-04 06:08:48 EDT
New Gerrit change created: https://git.eclipse.org/r/125496
Comment 5 Zoltan Ujhelyi CLA 2018-07-04 07:14:36 EDT
@Markus: Thanks for the project, I have managed to reproduce the original issue this way and used that a motivation for a test case as well for this case. As Gábor said, your proposed fix also seems to be going into the right direction, and I have verified that the same map is used correctly in the file. The Gerrit change mentioned in the previous commit contains this fix, and it will be backported to a bugfix release for 2.0. We don't have any concrete plans when willthis bugfix version (2.0.1) available, but my guess is we wil  do it a week or two.

@Gábor: I have opened bug 536680 to solve this kind of issue in a more general way instead of providing this kind of code in many different places.
Comment 6 Markus Gilg CLA 2018-07-04 07:23:44 EDT
Perfect, thanks a lot for the fix.
Comment 8 Eclipse Genie CLA 2018-07-04 07:47:07 EDT
New Gerrit change created: https://git.eclipse.org/r/125522
Comment 10 Zoltan Ujhelyi CLA 2018-07-04 08:45:30 EDT
Fixed in master and backported to 2.0-maintenance branch.