StoEx Parser seems to be broken: Summands are dropped in addition?


When simulating the LinkingResourceTest model (see below) with the "simulate throughput" option enables in the "Feature Settings" tab, the network demand is not properly calculated.

It seems that the internally used expression "stream.BYTESIZE + param.BYTESIZE + param.NUMBER_OF_ELEMENTS * param.INNER.BYTESIZE + aString.BYTESIZE" is wrongly evaluated.

The values on the stackframe are:
stream.BYTESIZE = 20
param.BYTESIZE = 1000
param.INNER.BYTESIZE is undefined, so should be evaluated as 0
aString.BYTESIZE = 333

So the result should be 1353.

However, the result is 1020. When stepping through the evaluation, I see that only the first two summands seems to be taken into account: An expression ADD(CharacterizedVar,CharacterizedVar) is parsed from the above String specification, so it seems that only "stream.BYTESIZE + param.BYTESIZE" is considered and the rest is somehow dropped. But maybe I am mistaken here.

Using the debugger, I could trace the problem to de.uka.ipd.sdq.simucomframework.variables.StackContext, line 132, where StoExCache.singleton().getEntry(stoex) is called. In the constructor StoExCacheEntry(String spec) the PCMStoExParser is called, which seems to return the incomplete parsed expression with only one ADD instead of three and a product.

As I am not familiar with the parser, it would be great if you could have a look.

Let me know if there are questions.

LinkingResourceTest model can be found at:




Anne Koziolek
August 2, 2012, 2:09 PM

I just know that models with 1+2+3 could be simulated correctly (as these expressions were generated by Steffen's completions and gave the expected results in the network simulation test model). I am not sure what the reasons are

Jörg Henß
August 2, 2012, 11:06 AM

The parsing of 1+2+3 was never allowed by "original" the grammar as far as I know...
I think we once had a grammar accepting it, but it was not reflected in the meta model, thus had no effect...
A simple workaround could be to write a snippet that detects this case and inserts brackets automatically...

Anne Koziolek
August 2, 2012, 10:52 AM

The Media Store Example also required additional parentheses in


probably because more BYTESIZE characterizations were used here in one call.

I added them at revision 15882.

Probably more testing is required to see whether other examples work. Or we go back to the old parsing rules that allow 1+2+3.

Anne Koziolek
July 25, 2012, 8:41 AM

Thanks Jörg, it works! I tested this with the old StoEx expression without parenthesis and it shows an error and also reports which StoEx is the problematic one.

I added an entry to the SDQ FAQ with hints how to resolve that exception.

Jörg Henß
July 24, 2012, 5:17 PM

I changed the StoExCachEntry to use MyPCMStoExParser that supports proper error reporting (no println).
Anne could you please test whether now a proper exception is thrown?
Perhaps we should also use the "My" version also for the lexer?!
The ExpressionHelper and some other places might as well have the same problem with the error handling...



Anne Koziolek


Anne Koziolek