titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2022-09-21T13:23:43Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/481Faulty subtype checking2022-09-21T13:23:43ZEclipse WebmasterFaulty subtype checking## Submitted by Gabor Szalai
**[Link to original bug (#562085)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562085)**
## Description
The following subtyping is a valid according to the standard but not accepted by the TI...## Submitted by Gabor Szalai
**[Link to original bug (#562085)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562085)**
## Description
The following subtyping is a valid according to the standard but not accepted by the TITAN:
type set r1 {
charstring f1,
charstring f3 optional
}
type r1 r1s ({f3:=omit})
proba.ttcn:10.14-24: error: Field `f1' is missing from set value
6.2.13.2:
When constraining record and set types, templates of the expanded list defined using the value list notation shall be valid (i.e. complete) templates, while templates of the expanded list defined using the field assignment notation may be partial (i.e. incomplete). In the latter case, the fields that are not explicitly present shall be considered as containing AnyValue for mandatory fields and AnyValueOrNone for optional fields.
Version: 6.6.1Adam KnappAdam Knapp2022-05-04https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/506Float string representation precision problems2021-11-10T08:29:07ZEclipse WebmasterFloat string representation precision problems## Submitted by G??bor Szalai
**[Link to original bug (#566118)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=566118)**
## Description
The string representation of the TTCN-3 floats are not precise enough. Less significan...## Submitted by G??bor Szalai
**[Link to original bug (#566118)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=566118)**
## Description
The string representation of the TTCN-3 floats are not precise enough. Less significant digits are used than required.
Examples:
Code generation problems:
TTCN code
var float fl:= 1.0000000000000002 // smallest value greater than 1 representable by 64bit double
Generated C++ code:
fl = 1;
Other problematic example: 3.2511111111111113e123
The same precision problem exists in:
string2ttcn
JSON encoder
float2str
The number of the needed significant digits are depends on the used floating point type. In the case of the double at least 17 digits are needed.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/544Decoding broken in Titan 7.2.22021-11-10T08:29:51ZEclipse WebmasterDecoding broken in Titan 7.2.2## Submitted by Anton Vikstrom
**[Link to original bug (#572603)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572603)**
## Description
Created attachment 286037
Minimal example showing the problem
When we upgraded to Ti...## Submitted by Anton Vikstrom
**[Link to original bug (#572603)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572603)**
## Description
Created attachment 286037
Minimal example showing the problem
When we upgraded to Titan 7.2.2 from Titan 7.1, most of our testcases started failing. It turns out decoding is broken.
I have attached a minimal testcase using PFCP_v16.4.0_4_CNL113875 R1H to decode a PDU. I there match the result of the decoding with the result of the decoding when using Titan 7.1. Of course, with Titan 7.1, this testcase passed. With Titan 7.2.2, this testcase FAILS.
The decode result in Titan 7.2.2 has many unbound fields, even mandatory ones like "spare := `<unbound>`" in SDF_Filter. You can also find instances of FAR_ID with elementIdentifier 109, even though it should always be 108.
This issue is urgent.
**Attachment 286037**, "Minimal example showing the problem":
[tc_decode.ttcn](/uploads/48147aa0e6fc07fe2b545c72c8d64f89/tc_decode.ttcn)
Version: 7.2.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/545XML namespace issue2022-11-15T10:25:56ZEclipse WebmasterXML namespace issue## Submitted by G??bor Szalai
**[Link to original bug (#572830)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572830)**
## Description
The xml encoder uses wrong namespaces for imported type
module A defines T1 with name...## Submitted by G??bor Szalai
**[Link to original bug (#572830)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572830)**
## Description
The xml encoder uses wrong namespaces for imported type
module A defines T1 with namespace nsA
module B defines T2, which has a field type T1, but the B module uses namespace nsB
The T1 typed field is encoded with namespace nsB instead of nsA
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/546Logging objects in Titan/TTCN-32021-06-02T05:47:56ZAdam KnappLogging objects in Titan/TTCN-3Sziasztok,
Belefutottam egy problemaba (lasd cim), amely a mellekelt archivumot, illetve a `Queue.tcQueueLog`-ot futtatva valik lathatova:
(bocs, h nem gyomlaltam ki a nem szigoruan idetartozo reszeket)
~~~
testcase tcQueueLog() runs ...Sziasztok,
Belefutottam egy problemaba (lasd cim), amely a mellekelt archivumot, illetve a `Queue.tcQueueLog`-ot futtatva valik lathatova:
(bocs, h nem gyomlaltam ki a nem szigoruan idetartozo reszeket)
~~~
testcase tcQueueLog() runs on GeneralComp {
var UniversalCharstring uc0, uc1, uc2;
var object v_obj;
log("Create empty queue");
var TitanQueue q := TitanQueue.create();
log(q)
log(q.toString());
uc0 :=UniversalCharstring.create("FirstElement")
q.add(uc0);
uc1 :=UniversalCharstring.create("SecondElement")
q.add(uc1);
uc2 :=UniversalCharstring.create("ThirdElement")
q.add(uc2);
var QueueForwardIterator iterator := q.iterator() => QueueForwardIterator;
while(iterator.hasNext() ){
v_obj := iterator.next() => object;
log ("------>",v_obj)
//log(iterator); //!!!!!!
}
log(q.toString());
log(q); // !!!!!!!
}
~~~
A konstruktor meghivasa utan letrehozott `queue` tipusu objektumot a Titan igy logolja ki `/* log(q) */`
`08:43:36.504041 Queue.ttcn:229 TitanQueue: { Queue: { Collection: { Storable: { } } }, head := null, tail := null }`
Nehany elem hozzaadasa utan viszont a `log(q)` lefagyasztja a Titan-t.
Hasonlokeppen az iterator logolasa is fagyast eredmenyez.
Az objektumon beluli pointer tipusu mezok kozvetlenul nem erhetok el, mivel nem lehetnek publikusak (gondolok itt a head-re es tail-re:
~~~
type class TitanQueue extends Queue {
private var Node head;
private var Node tail;
create() {
head := null;
tail := null;
}
:
:
)
~~~
De barmikor lehet olyan publikus method-ot irni, amivel kiolvashatok,
Pl.
~~~
module TTCN3Queue {
import from TTCN3_standard_collections all;
import from StorableModule all;
import from OODataStructuresCommon all;
type class QueueForwardIterator extends Iterator {
//from head to tail
var Node nextNode;
create(in Node listHead) {
nextNode := listHead;
}
//public function @abstract hasNext() return boolean;
public function hasNext() return boolean {
return nextNode != null;
}
//public function @abstract next() return object;
public function next() return object {
var object toReturn := nextNode.getData();
nextNode := nextNode.getNext();
return toReturn;
}
public function nextN() return Node {
var Node toReturn := nextNode;
nextNode := nextNode.getNext();
return toReturn;
}
}
~~~
Es akkor a kiiratas szinten fagyassal vegzodik:
`Queue.ttcn`
~~~
while(iterator.hasNext() ){
v_obj := iterator.next() => object;
log ("------>",v_obj);
v_node := iterator.nextN() => Node;
log ("+++++++>",v_node);
}
~~~
Ket gondot latok alapvetoen:
- A Titannak semmilyen korulmenyek kozott nem szabad lefagynia
- Masreszt a szabvany semmilyen tampontot nem ad arra nezvest , h hogyan kell es lehet objektumokat logolni
Mint ahogy pl. Pythonban egy print ezt eredmenyezi:
`_main_.Valami object at 0x7ff6a218d2210`
Vagy Java-ban ezt:
`Objektum@512ddf17`
(bar az is hasznos lehetne, ha igyekeznenk az objektum valos tartalmat megjeleniteni).
Mindenesetre a masodik az egy szabvanyositasi kerdes; udvos lenne , ha a tool-ok egysegesen jelenitenek meg az objetumokat.
Gyuri, Kristof, mit gondoltok errol?
UdvBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/555RAW decoding error, hexstring, HEXORDER (high), FIELDORDER(msb)2021-11-10T08:22:18ZGábor SzalaiRAW decoding error, hexstring, HEXORDER (high), FIELDORDER(msb)## Summary
The RAW encoder fails to correctly decode the last digit of hexstring if
- the hexstring is odd number length and length > 2
- and variant "HEXORDER (high)"
- nad variant "FIELDORDER(msb)"
## Steps and/or TTCN-3 code to rep...## Summary
The RAW encoder fails to correctly decode the last digit of hexstring if
- the hexstring is odd number length and length > 2
- and variant "HEXORDER (high)"
- nad variant "FIELDORDER(msb)"
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type record MyRec{
MCC mcc,
bitstring bs length(4)
} with {
variant "FIELDORDER(msb)"
}
type hexstring MCC
with {
variant "FIELDLENGTH (3)";
variant "FIELDORDER(msb)"
variant "HEXORDER (high)";
}
type component CT{}
template MyRec t_hex:={
mcc:='042'H,
bs:='0000'B
}
testcase TChex() runs on CT {
var bitstring bdata:='0000010000100000'B
var MyRec res
var integer i:=decvalue(bdata,res)
log(i)
if(i!=0){
setverdict(fail, "decvalue failed")
} else {
log(res)
if(match(res,t_hex)){
setverdict(pass)
} else {
setverdict(fail, "unmatched value")
}
}
}
control {
execute(TChex())
}
} with { encode "RAW" }
```
## What is the current bug behavior?
`{ mcc := '040'H, bs := '0000'B }`
## What is the expected correct behavior?
`{ mcc := '042'H, bs := '0000'B }`
## Titan version
up to 8.0.0Gábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/556make clean can cause “Argument list too long” error2021-11-10T08:22:21ZAdam Knappmake clean can cause “Argument list too long” error## Summary
In the generated Makefile all files are cleaned in one command
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS) $(GENERATED_HEADERS) \
$(GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES) ...## Summary
In the generated Makefile all files are cleaned in one command
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS) $(GENERATED_HEADERS) \
$(GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES) compile $(DEPFILES) \
tags *.log
```
With a lot of files `Argument list too long` error is got.
## Possible fixes
Separate the clean command, e.g.
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS)
-$(RM) $(GENERATED_HEADERS)
-$(RM) $ (GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES)
-$(RM) compile $(DEPFILES) tags *.log
```
## Titan version
8.0.0.
/cc @aknappqwtAdam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/557RAW enc/dec error, hexstring, FILEDORDER(msb), HEXORDER(high), field starts o...2021-11-10T08:22:23ZGábor SzalaiRAW enc/dec error, hexstring, FILEDORDER(msb), HEXORDER(high), field starts on half octet## Summary
The encoding of the hexstring is faulty if:
- FILEDORDER(msb)
- HEXORDER(high)
- The field starts on the half octet
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type record R4{
bitstring f1 length(4),
h...## Summary
The encoding of the hexstring is faulty if:
- FILEDORDER(msb)
- HEXORDER(high)
- The field starts on the half octet
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type record R4{
bitstring f1 length(4),
hexstring f2
} with {
variant (f2) "HEXORDER(high)"
variant "FIELDORDER(msb)"
}
type component CT{}
template bitstring t_expected_encoded:=oct2bit('F123456789'O)
template R4 t_expected_decoded:={'1111'B, '123456789'H }
testcase TC2() runs on CT {
var R4 vl_pdu4:={'1111'B, '123456789'H }
var bitstring vl_encoded:=encvalue(vl_pdu4)
log(vl_pdu4, " encoded as ",bit2oct(vl_encoded), " expected as ", bit2oct(valueof(t_expected_encoded)))
if(match(vl_encoded,t_expected_encoded)){
setverdict(pass)
} else {
setverdict(fail, "wrong encoded value")
}
vl_encoded:=valueof(t_expected_encoded)
var integer vl_res:=decvalue(vl_encoded,vl_pdu4)
log("decode result: ", vl_res)
if(vl_res == 0) {
setverdict(pass)
log(bit2oct(valueof(t_expected_encoded)), " decoded as ",vl_pdu4, " expected as ", t_expected_decoded)
if(match(vl_pdu4,t_expected_decoded)){
setverdict(pass)
} else {
setverdict(fail, "wrong decoded value")
}
} else {
setverdict(fail, "Decoding failed")
}
}
control {
execute(TC2())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
```
15:05:12.936648 proba.ttcn:69 Component type proba.CT was initialized.
15:05:12.937090 proba.ttcn:73 { f1 := '1111'B, f2 := '123456789'H }encoded as 'F315274968'O expected as 'F123456789'O
15:05:12.937457 proba.ttcn:77 setverdict(fail): none -> fail reason: "wrong encoded value", new component reason: "wrong encoded value"
15:05:12.937788 proba.ttcn:83 decode result: 0
15:05:12.938259 proba.ttcn:87 'F123456789'Odecoded as { f1 := '1111'B, f2 := '241638597'H } expected as { f1 := '1111'B, f2 := '123456789'H }
15:05:12.938626 proba.ttcn:91 setverdict(fail): fail -> fail reason: "wrong decoded value", component reason not changed
```
## What is the expected correct behavior?
```
15:08:15.666778 proba.ttcn:73 { f1 := '1111'B, f2 := '123456789'H } encoded as 'F123456789'O expected as 'F123456789'O
15:08:15.667254 proba.ttcn:75 setverdict(pass): none -> pass
15:08:15.667984 proba.ttcn:83 decode result: 0
15:08:15.668373 proba.ttcn:86 setverdict(pass): pass -> pass, component reason not changed
15:08:15.668687 proba.ttcn:87 'F123456789'O decoded as { f1 := '1111'B, f2 := '123456789'H } expected as { f1 := '1111'B, f2 := '123456789'H }
15:08:15.669039 proba.ttcn:89 setverdict(pass): pass -> pass, component reason not changed
```
## Titan version
Up to 8.0.0Gábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/558RAW encdec: overindexing of the buffer2021-11-10T08:22:25ZGábor SzalaiRAW encdec: overindexing of the buffer## Summary
The buffer can be overindexed in the RAW decoder during the decoding of the last field.
## Steps and/or TTCN-3 code to reproduce
Use the test case of the Issue #557
C++ Run the test with valgrind
Java Just run the test cas...## Summary
The buffer can be overindexed in the RAW decoder during the decoding of the last field.
## Steps and/or TTCN-3 code to reproduce
Use the test case of the Issue #557
C++ Run the test with valgrind
Java Just run the test case
## What is the current bug behavior?
C++, Valgrind
```
==13478== Invalid read of size 1
==13478== at 0x17EFE2: TTCN_Buffer::get_byte_align(unsigned long, raw_order_t, raw_order_t, unsigned long) (in /home/ethgasz/proba/a/proba)
==13478== by 0x17F6FD: TTCN_Buffer::get_b(unsigned long, unsigned char*, RAW_coding_par const&, raw_order_t) (in /home/ethgasz/proba/a/proba)
==13478== by 0x1881C2: HEXSTRING::RAW_decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, raw_order_t, bool, int, bool, RAW_Force_Omit const*) (in /home/ethgasz/proba/a/proba)
==13478== by 0x13F2E4: proba::R4::RAW_decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, raw_order_t, bool, int, bool, RAW_Force_Omit const*) (in /home/ethgasz/proba/a/proba)
==13478== by 0x13E9E9: proba::R4::decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, ...) (in /home/ethgasz/proba/a/proba)
==13478== by 0x1531C5: proba::R4_decoder(OCTETSTRING&, proba::R4&, UNIVERSAL_CHARSTRING const&) (in /home/ethgasz/proba/a/proba)
```
Java:
Index overflowGábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/560CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code2021-11-10T08:22:29ZLenard NagyCROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ codeOriginal Bugzilla bug written by Pau Espin Pedrol:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574469
## Summary
CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code
## Steps and/or TTCN-3 code to reproduce
Following T...Original Bugzilla bug written by Pau Espin Pedrol:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574469
## Summary
CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code
## Steps and/or TTCN-3 code to reproduce
Following TTCN3 code compiles fine, but generates incorrect C++ code:
~~~
type union PCUIF_ContainerMsgUnion {
octetstring other
} with { variant "" };
type record PCUIF_container {
uint8_t msg_type,
uint8_t spare,
uint16_t len,
PCUIF_ContainerMsgUnion u
} with {
variant (len) "LENGTHTO(u)"
variant (u) "CROSSTAG(
other, OTHERWISE)"
};
~~~
Then when C++ code is compiled:
~~~
g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -I/usr/ttcn3/include -fPIC -o RSL_Emulation.o RSL_Emulation.cc
PCUIF_Types.cc: In member function ‘int PCUIF__Types::PCUIF__container::RAW_decode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int, raw_order_t, boolean, int, boolean, const RAW_Force_Omit*)’:
PCUIF_Types.cc:31342:3: error: ‘else’ without a previous ‘if’
31342 | else selected_field = 0;
| ^~~~
~~~
So it seems the TTCN3->C++ compiler is missing checking specific cases where the union (or the CROSSTAG) has only 1 OTHERWISE option.
Rationale for TTCN3 code shown above:
I wrote that TTCN3 code since I'm implementing the container layer without having yet any specific message in top of it specified, which will come later. Hence I wanted to have some octetstring on top to send random data to test only up to the container layer, while leaving the TTCN3 records prepared to add new container payload data in the future.
## Titan version
6.6.1
/cc @aknappqwtAdam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/562xsd2ttcn segfault on Cygwin2021-08-09T11:25:12ZAdam Knappxsd2ttcn segfault on Cygwin## Summary
Running our reg tests on Cygwin, the following test cases in `/titan.core/regression_test/XML/XmlWorkflow/src/xmlTest_Testcases.ttcn` resulted in segmentation fault:
```
tc_decimal_withMinMaxInclusive
tc_decimal_withMinMaxExc...## Summary
Running our reg tests on Cygwin, the following test cases in `/titan.core/regression_test/XML/XmlWorkflow/src/xmlTest_Testcases.ttcn` resulted in segmentation fault:
```
tc_decimal_withMinMaxInclusive
tc_decimal_withMinMaxExclusive
tc_decimal_fractiondigits
tc_ranges_float
```
## Steps and/or TTCN-3 code to reproduce
E.g.:
```bash
$ ~/ttcn3-8.0.0-cygwin3.1.7-gcc10.2.0/bin/xsd2ttcn.exe -p -t XmlTest_decimal_withMinMaxInclusive.xsd
Notify: Checking documents...
Notify: Parsing XML schema document `XmlTest_decimal_withMinMaxInclusive.xsd'...
Notify: Generating TTCN-3 modules...
Segmentation fault (core dumped)
```
## What is the expected correct behavior?
E.g.:
```bash
$ ../../../../Install/bin/xsd2ttcn -p -t XmlTest_decimal_withMinMaxInclusive.xsd
Notify: Checking documents...
Notify: Parsing XML schema document `XmlTest_decimal_withMinMaxInclusive.xsd'...
Notify: Generating TTCN-3 modules...
Notify: File 'www_XmlTest_org_decimal_withMinMaxInclusive.ttcn' was generated.
```
## Titan version
8.0.0
## Platform details (OS type and version)
**Only** Windows10 + Cygwin
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/570Update CONTRIBUTING.md2021-08-17T07:28:41ZLenard NagyUpdate CONTRIBUTING.md## Summary
The CONTRIBUTING.md file contains outdated information
## What is the expected correct behavior?
- Github and git.eclipse.org workflow to be deleted
- Gitlab workflow to be introduced
- Direct link to ECA (https://www.eclip...## Summary
The CONTRIBUTING.md file contains outdated information
## What is the expected correct behavior?
- Github and git.eclipse.org workflow to be deleted
- Gitlab workflow to be introduced
- Direct link to ECA (https://www.eclipse.org/legal/ECA.php) is requested by Eclipse Foundation
## Relevant logs and/or screenshots
https://gitlab.eclipse.org/eclipse/titan/titan.core/-/blob/master/CONTRIBUTING.md
## Titan version
8.0.0
## Platform details (OS type and version)
All
/cc @aknappqwtLenard NagyLenard Nagyhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/572Titan can not handle timers set to more than 25 days2021-11-10T08:22:42ZLenard NagyTitan can not handle timers set to more than 25 days## Summary
Titan can not handle timers set to more than 25 days
## Steps and/or TTCN-3 code to reproduce
Set any timer to more than 2147483 seconds
## What is the current bug behavior?
The too long timer will be set to 2147483 secon...## Summary
Titan can not handle timers set to more than 25 days
## Steps and/or TTCN-3 code to reproduce
Set any timer to more than 2147483 seconds
## What is the current bug behavior?
The too long timer will be set to 2147483 seconds and a Warning is displayed
## What is the expected correct behavior?
The TTCN-3 standard does not specify maximum timeout limit, so any positive float value should be accepted and handled
## Relevant logs and/or screenshots
Warning: The time needed for the first timer expiry is 2.14748e+07 seconds. The operating system does not support such long waiting at once. The maximum time of blocking was set to 2147483 seconds (ca. 24 days).
## Possible fixes
In `void TTCN_Snapshot::take_new(boolean block_execution)`
~~~c
} else {
// issue a warning: the user probably does not want such
// long waiting
TTCN_warning("The time needed for the first timer "
"expiry is %g seconds. The operating system does "
"not support such long waiting at once. The "
"maximum time of blocking was set to %d seconds "
"(ca. %d days).", block_time, MAX_BLOCK_TIME,
MAX_BLOCK_TIME / 86400);
// also modify the the timeout value to get out
// immediately from the while() loop below
timeout = current_time + (double)MAX_BLOCK_TIME;
pollTimeout = MAX_BLOCK_TIME * 1000;
handleTimer = TRUE;
}
~~~
## Titan version
8.0.0
## Platform details (OS type and version)
All
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/573Infinite recursion caused by multiple ASN.1 parameterized type instances2021-12-02T07:16:43ZBotond BaranyiInfinite recursion caused by multiple ASN.1 parameterized type instances## Summary
Multiple instances of the same ASN.1 parameterized type in a type hierarchy cause an infinite recursion during semantic analysis.
## ASN.1 code to reproduce
A
DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
Uint8 ::= INTEGER (0.....## Summary
Multiple instances of the same ASN.1 parameterized type in a type hierarchy cause an infinite recursion during semantic analysis.
## ASN.1 code to reproduce
A
DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
Uint8 ::= INTEGER (0..255)
ScmsPdu ::= SEQUENCE {
version Uint8 (2),
content CHOICE {
aca-ra AcaRaInterfacePdu,
int INTEGER,
...
}
}
ScmsPdu-Scoped {Pdu} ::= ScmsPdu (WITH COMPONENTS {
...,
content (CONSTRAINED BY {
Pdu
})
})
AcaRaInterfacePdu ::= CHOICE {
a Again,
...
}
Again ::= ScmsPdu-Scoped {
INTEGER
}
END
## What is the current bug behavior?
The compiler crashes due to an infinite recursion.
## What is the expected correct behavior?
Successful semantic analysis.
## Relevant logs and/or screenshots
-
## Possible fixes
-
## Titan version
8.0.0
## Platform details (OS type and version)
Any.Botond BaranyiBotond Baranyi2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/574RAW decoder error: DTE during handling of out of range enum values2021-11-10T08:22:37ZGábor SzalaiRAW decoder error: DTE during handling of out of range enum values## Summary
The RAW decoder of enumerated type can't handle large out of range values. If the decoded value is not fit to int, the decoder throws DTE instead of correct failure code
## Steps and/or TTCN-3 code to reproduce
```
module p...## Summary
The RAW decoder of enumerated type can't handle large out of range values. If the decoded value is not fit to int, the decoder throws DTE instead of correct failure code
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type enumerated my_enum{ a(0), b(1)} with {variant "FIELDLENGTH(32)"}
type union my_union{
my_enum f1,
octetstring f2
}
template my_union t_expected:={f2:='FFFFFFFF'O}
testcase t_1() runs on CT{
var bitstring vl_encoded:='11111111111111111111111111111111'B
var my_union vl_pdu
var integer vl_res:=decvalue(vl_encoded,vl_pdu)
log(vl_res)
log(vl_pdu)
if(vl_res == 0 and match(vl_pdu,t_expected)){
setverdict(pass)
} else {
setverdict(fail)
}
}
control{
execute(t_1())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
Dynamic test case error: Invalid conversion of a large integer value
## What is the expected correct behavior?
pass
## Titan version
Up to 8.0.0
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/575RAW encoder: wrong value if FIELDORDER msb with PADDING2021-11-10T08:22:39ZGábor SzalaiRAW encoder: wrong value if FIELDORDER msb with PADDING## Summary
The RAW encoder produces wrong encoded value if the FIELDORDER is msb and padding is used.
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type record my_rec{
bitstring f1 length(6)
} w...## Summary
The RAW encoder produces wrong encoded value if the FIELDORDER is msb and padding is used.
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type record my_rec{
bitstring f1 length(6)
} with {
variant "FIELDORDER(msb)"
variant "PADDING(dword32)"
}
template my_rec t_expected:={f1:='111111'B}
testcase t_1() runs on CT{
var bitstring vl_encoded
var my_rec vl_pdu:={f1:='111111'B}
var integer vl_res
vl_encoded:=encvalue(vl_pdu)
log(vl_encoded)
}
control{
execute(t_1())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
'11000000000000000000000000000000'B
## What is the expected correct behavior?
'11111100000000000000000000000000'B
## Titan version
Up to 8.0.0
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/576Debian packet creation fails2022-05-04T05:36:28ZLenard NagyDebian packet creation fails## Summary
Debian packet creation fails with following log:
```
--- /dev/null
+++ eclipse-titan-8.1.0/common/git_version.c
@@ -0,0 +1,4 @@
+// this file was generated by make
+#include "version_internal.h"
+
+char const *const GIT_COMM...## Summary
Debian packet creation fails with following log:
```
--- /dev/null
+++ eclipse-titan-8.1.0/common/git_version.c
@@ -0,0 +1,4 @@
+// this file was generated by make
+#include "version_internal.h"
+
+char const *const GIT_COMMIT_ID = "";
\ No newline at end of file
```
## Steps and/or TTCN-3 code to reproduce
-
## What is the current bug behavior?
-
## What is the expected correct behavior?
Packet creation succeeds
## Relevant logs and/or screenshots
```
--- /dev/null
+++ eclipse-titan-8.1.0/common/git_version.c
@@ -0,0 +1,4 @@
+// this file was generated by make
+#include "version_internal.h"
+
+char const *const GIT_COMMIT_ID = "";
\ No newline at end of file
```
## Possible fixes
One new line character must be the last character of all C/C++ source files, in this case common/git_version.c
## Titan version
8.0.0
## Platform details (OS type and version)
Debian (latest)
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/578Enumerated type subtype check2022-05-04T05:41:09ZAdam KnappEnumerated type subtype check## Summary
According to the standard (6.2.13.2, https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.13.01_60/es_20187301v041301p.pdf#page=80): "In case of enumerated types, the template list subtyping shall contain only value...## Summary
According to the standard (6.2.13.2, https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.13.01_60/es_20187301v041301p.pdf#page=80): "In case of enumerated types, the template list subtyping shall contain only values of the parent type."
## Steps and/or TTCN-3 code to reproduce
```
type enumerated MyEnum { e_first, e_second, e_third, e_fourth, e_fifth };
type MyEnum EnumSub4 ( EnumSub1, e_fourth);
// causes an error as type references are not allowed in the template list
// of enumerated types
```
## What is the current bug behavior?
It is allowed/not checked by the compiler.
## What is the expected correct behavior?
The compiler should provide an error message about this.
## Titan version
6.6.1
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/580gcc warning: control reaches end of non-void function2022-05-04T05:39:53ZGábor Szalaigcc warning: control reaches end of non-void function## Summary
The GCC compiler generates a warning:
warning: control reaches end of non-void function [-Wreturn-type]
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type enumerated t_e {I,O}
function f1(in t_e a) return...## Summary
The GCC compiler generates a warning:
warning: control reaches end of non-void function [-Wreturn-type]
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type enumerated t_e {I,O}
function f1(in t_e a) return integer {
select(a){
case (I) {
return 1
}
case else {
return 2
}
}
}
}
```
## What is the current bug behavior?
```
g++ -c -DLINUX -I/home/ethgasz/TTCNv3/include -Wall -o proba.o proba.cc
proba.cc: In function ‘INTEGER proba::f1(const proba::t__e&)’:
proba.cc:665:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
```
## What is the expected correct behavior?
No warning
## Possible fixes
Do not generate the unnecessary goto and label statements
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/582mctr fails to accept all HC connections2022-05-04T05:36:51ZGábor Szalaimctr fails to accept all HC connections## Summary
If a large number of HC try to connect to the mctr, some of them are rejected.
## Steps and/or TTCN-3 code to reproduce
Try to start ~ 30 HCs at the same time.
## What is the current bug behavior?
Some HCs can't connect, ...## Summary
If a large number of HC try to connect to the mctr, some of them are rejected.
## Steps and/or TTCN-3 code to reproduce
Try to start ~ 30 HCs at the same time.
## What is the current bug behavior?
Some HCs can't connect, because the TCP connection is refused
## What is the expected correct behavior?
All HC connects
## Possible fixes
When the mctr opens the listening port, it sets the backlog to 10. When a new connection is accepted, a possible time consuming reverse DNS query is executed. If the number of the waiting connection exceeds 10, the new attempts are rejected by the kernel.
simply increase the backlog. The current value remained unchanged since the beginning.
"If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently capped to that value. Since Linux 5.4, the default in this file is 4096; in earlier kernels, the default value is 128."
So it is safe to increase it to 4096
## Titan version
all
## Platform details (OS type and version)
all
/cc @aknappqwtAdam KnappAdam Knapp