First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 392
Product:
Component:
Status: ASSIGNED
Resolution:
Assigned To: Gerd Behrmann <behrmann@cs.aau.dk>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Jacob Illum <illum@cs.aau.dk>
Add CC:
CC:
URL:
Summary:

Attachment Type Creator Created Size Actions
The model text/xml Jacob Illum 2007-02-19 12:12 2.44 KB Details
The query application/octet-stream Jacob Illum 2007-02-19 12:13 153 bytes Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 392 depends on: Show dependency tree
Show dependency graph
Bug 392 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments:








View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2007-02-19 12:11
The two queries evaluate differently, but given the way the model is
constructed, the evaluation should be identical. 

- One query test on all instantiations will reach the 'complete' location.
- The other tests the boolean array done, which is only altered upon entering
the 'complete' location.

Thus, the two expressions should evaluate identically, but the former returns
false, whereas the latter returns true. Random simulation will even lead to
satisfaction of the former query.

------- Comment #1 From Jacob Illum 2007-02-19 12:12:49 -------
Created an attachment (id=143) [details]
The model

------- Comment #2 From Jacob Illum 2007-02-19 12:13:13 -------
Created an attachment (id=144) [details]
The query

------- Comment #3 From Gerd Behrmann 2007-02-19 15:09:43 -------
The problem is in the automatic instantiation of templates. 

If P(i) is a template, then P is internally treated as an array of processes
with i being an index. This assumes that all instances of P have the same
footprint. In the test case, this is not the case: The process argument is used
in the select expression. Since the select expression is being unfolded into a
number of edges, this means that the number of syntactic function calls varies
between instances of P. Since we generate an internal variable for the return
value for each syntactic function call, this has the consequence of differences
in footprint.

------- Comment #4 From Gerd Behrmann 2007-02-19 16:38:10 -------
There does not seem to be a small/simple fix for the problem. I am currently
considering to disallow models that trigger the bug and postpone the real fix
for 4.2.

------- Comment #5 From Gerd Behrmann 2007-02-19 18:42:04 -------
"Fixed" on the 4.0 branch from rev. 2971. I choose to disallow models
triggering the problem.

I will leave this bug open, since it needs to be fixed on the trunk.

First Last Prev Next    No search results available      Search page      Enter new bug