ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007607 | Part 01: TTCN-3 Core Language | Technical | public | 09-02-2017 14:00 | 30-12-2017 20:55

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.9.1 (published 2017-05) |
Target Version | v4.10.1 (published 2018-05) | Fixed in Version | v4.10.1 (published 2018-05) |
Clause Reference(s) | 21.1.1
Source (company - Author) | STF 521

Summary | 0007607: Additional restriction for the connect operation

Description

The current rules for the connect operation allow to establish a connection where no communication is possible without violating the current restrictions. Let's demonstrate it on an example:
type port P message { in integer; }
type component C { port P p; }
testcase TC() runs on C system C {
var C v_ptc := C.create;
connect(self:p, v_ptc:p);
}
The rule 21.1.1.c says the connect operation is allowed if outlist-PORT1 subsetof inlist-PORT2 and outlist-PORT2 subsetof inlist-PORT1, which is fulfilled as the empty outlists are valid subsets of inlists.
However, since no messages can be sent over such a connection from either side, it should not be allowed to create it. For that reason, I propose to extend the restriction c) by adding an additional condition: "where at least one of the outlists is not empty".

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007677 | closed | Gyorgy Rethy | Additional restriction for the disconnect operation

Attached Files |

Issue History
Date Modified | Username | Field | Change
09-02-2017 14:00 | Tomas Urban | New Issue |
09-02-2017 14:14 | Tomas Urban | Note Added: 0014525 |
10-02-2017 09:37 | Jacob Wieland - Spirent | Note Added: 0014526 |
20-04-2017 17:39 | szabados | Note Added: 0014594 |
21-04-2017 09:40 | Jacob Wieland - Spirent | Note Added: 0014595 |
21-04-2017 10:59 | Tomas Urban | Note Added: 0014596 |
21-04-2017 14:51 | Jacob Wieland - Spirent | Note Added: 0014597 |
21-04-2017 15:09 | Tomas Urban | Note Added: 0014598 |
21-04-2017 15:09 | Tomas Urban | Note Edited: 0014598 | bug_revision_view_page.php?bugnote_id=14598#r411
21-04-2017 16:01 | Jacob Wieland - Spirent | Note Added: 0014599 |
21-04-2017 16:02 | Jacob Wieland - Spirent | Note Edited: 0014599 | bug_revision_view_page.php?bugnote_id=14599#r413
03-05-2017 10:40 | Tomas Urban | Note Added: 0014612 |
03-05-2017 11:00 | Jacob Wieland - Spirent | Note Added: 0014613 |
06-06-2017 11:32 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
06-06-2017 11:32 | Jens Grabowski | Status | new => assigned
06-06-2017 11:33 | Jens Grabowski | Note Added: 0014621 |
08-06-2017 20:34 | KristÃ³f Szabados | Relationship added | related to 0007677
09-06-2017 08:15 | Tomas Urban | Note Added: 0014673 |
09-06-2017 08:15 | Tomas Urban | Status | assigned => resolved
09-06-2017 08:15 | Tomas Urban | Resolution | open => fixed
09-06-2017 08:15 | Tomas Urban | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
30-12-2017 20:55 | Gyorgy Rethy | Status | resolved => closed
30-12-2017 20:55 | Gyorgy Rethy | Product Version | => v4.9.1 (published 2017-05)
30-12-2017 20:55 | Gyorgy Rethy | Fixed in Version | => v4.10.1 (published 2018-05)
30-12-2017 20:55 | Gyorgy Rethy | Target Version | => v4.10.1 (published 2018-05)

Notes

(0014525)
Tomas Urban
09-02-2017 14:14

A similar problem affects the restriction d on the mapping operation. In this case, the additional rule should state that either outlist-PORT1 or inlist-PORT2 (or both of them) shall not be empty.

(0014526)
Jacob Wieland - Spirent
10-02-2017 09:37

This would be a valid but useless restriction. The actual resulting problem only occurs once you try to send something over the port at which point a (probably even static) error would occur. As long as you don't use the connection to send something, it doesn't pose an actual problem.

(0014594)
szabados
20-04-2017 17:39

I'm for extending the restriction. I just registered a request for Titan to report these situations. This is something that we can detect statically and save potentially hours of debugging for our users.

(0014595)
Jacob Wieland - Spirent
21-04-2017 09:40

How can this be a debugging problem? Does Titan not check whether a message over a port can be sent statically? Once you try to send a message over a port that is not allowed to be sent, the (probable) error in the port definition will become apparent and can be fixed. No debugging involved.

(0014596)
Tomas Urban
21-04-2017 10:59

I agree that it is not a problem for sending. However, in the case of receiving operations an unexperienced user might wonder why no messages are ever delivered to a legally mapped/connected port. If he/she gets a static error when compiling the connect operation, it will save a lot of time.
We had this case some time ago and it really took some time to find the cause of the problem which occurred after removing some messages from the port list (the test suite worked well before). Of course it was an error of the person who made this change and didn't thought it through, but with proper compiler support, it would have been discovered earlier.

(0014597)
Jacob Wieland - Spirent
21-04-2017 14:51

But what would this restriction help you in that case? Did the person remove ALL the types in the out list of the connected port or just some? In the latter case, the additional restriction would not help you at all.

(0014598)
Tomas Urban
21-04-2017 15:09

The person didn't remove all types from the port type, but unfortunately the removed types were the only ones which were present in the other port type in-list.
I admit it is not a usual issue, but I don't see any harm having an additional restriction here. Our compiler does detect the problem and issues a warning, but since the common approach of typical users to warnings is to ignore them, I would prefer an outright error during compilation of the connect (or map operation). It just doesn't seem reasonable to allow connections that are completely useless.

(0014599)
Jacob Wieland - Spirent
21-04-2017 16:01 (edited on: 21-04-2017 16:02)

But then this is already covered with the current restriction in place. The out-list of port A was X and the in-list of B was Y and Y was not a superset of X, then the restriction is violated and connect should be reported as erroneous. Or what am I missing?

(0014612)
Tomas Urban
03-05-2017 10:40

I am sorry, Jacob. I wrote the comment without checking the exact details. You are indeed correct that the described situation is covered by the current restrictions.
It turns out that the problem our testers had concerned mapped ports. They actually did delete (or rather commented out) the whole in-list of the system port. It happened by accident, it was not an intentional change. The mapped component port had no out-list, because it was used only for notifications. The adapter still kept enqueuing messages which led to a runtime error during a test session. It took them some time to figure out the reason.

(0014613)
Jacob Wieland - Spirent
03-05-2017 11:00

sorry, can you just give the problematic example in TTCN-3 form to better understand the issue. I am still confused.

(0014621)
Jens Grabowski
06-06-2017 11:33

STF dicussion: check, if a note is sufficient for this issue.

(0014673)
Tomas Urban
09-06-2017 08:15

Resolved as a part of the resolution o 0007677.