New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bidirectional feature group connection produces incorrect connection instance #2318
Comments
Updated the example to see what happens when the connections are declared in the other direction (that is, change the roles of the src and dest in the connection declarations):
The results are interesting in that the error doesn't exists in the other direction: |
This is true for regular bidirectional port connections as well. That is, this is not a feature group problem.
|
Simplified the broken port connection example:
|
EDIT: This went away after I restarted OSATE. Strange. Going to keep this comment for now in case it comes back. More weirdness. I replaced the bidirectional connection in the above example with two directional connections:
This semantic connection from inside to the outside (sub component to the border of the toplevel) is fine. But the semantic connection from the outside to the inside (from the edge of toplevel to the subcomponent) is missing links to the declared connections. However, if I comment out the declaration of |
Line 585 in cf05234
Wondering if this initialization is correct. I am not sure in which situation where one segment of the connection instance is towards the destination and other is towards the source. I believe the recursive call should follow the same direction therefore the |
The connection instantiation process starts from toplevel system instantiation for building connection instance fg_port -> sub.th.fg_port . After adding the conn2 to the connection instance, Line 592 in cf05234
The above line searches for a feature instance for the feature sub.fg_port in the component toplevel. This works when the goOpposite is false. Changing nextCi to (goOpposite ? ci : nextCi) fixes the issue. Bigger issue: osate2/core/org.osate.aadl2/src/org/osate/aadl2/instance/impl/ComponentInstanceImpl.java Line 891 in cf05234
findFeatureInstance should check if “this”(ComponentInstance) is an instance of the component containing the feature. |
recursive call connection segment direction should be same as the caller
I'm still evaluating this, and I'm not saying that this does or doesn't fix the problem, but I'm not sure this is correct diagnosis. I changed all the port names to be unique and the problem goes away.
Here we see on the left that the version where all the ports have the same name has a bad reverse connection instance. On the right we see that the version with unique names has a correct reverse connection instance. |
Yes that is what I mentioned in the "Bigger Issue" section. There are two problems:
Assume I have components A and B with feature named p1. Additionally, Ainst and Binst are the component instance built from component A and B. Now, if I call Fixing any one will fix this problem, but there will be other issues if both are not fixed. |
Been studying this most of the afternoon. I am almost certain that there is nothing wrong with line 592. It belongs to a block of code that expects failure and is trying to determine which way the connection is going. I think the real and only problem is with the name-based feature lookup. |
For sanity checking I created test cases that verify that the logic for computing Thus the sole problem here is that |
The problematic call to
I think this test is actually unnecessary, and we could just have a test based on the looking up the feature in the destination context as done inside the conditional branch. But after a discussion with @lwrage, we have decided the best thing to do is to fix |
Looked at the rest of the
So I need to fix
Add test for
|
Fixed
and added JUnit tests for them. Added a JUnit test for
|
Added unit tests for the original test case ( |
Summary
Osate produces connection instances with both source and destination being the same port.
Expected and Current Behavior
Osate instantiation of a system with bi-directional feature group connections between parent and sub components produces the backward connection instance incorrectly. It is supposed to make a connection instance from a leaf level component out port to the top level component's out port. However, Osate connects back to the leaf level components out port.
Steps to Reproduce
toplevel.i
system from the provided modelOther Observation
Even when the connection instance of two different ports are made, the connection reference with same source and destination exists
Bug exist with and without the feature group refinement
Environment
The text was updated successfully, but these errors were encountered: